forked from lijiext/lammps
1000 lines
46 KiB
HTML
1000 lines
46 KiB
HTML
<HTML>
|
|
<CENTER><A HREF = "Section_intro.html">Previous Section</A> - <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> - <A HREF = "Section_commands.html">Next Section</A>
|
|
</CENTER>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<HR>
|
|
|
|
<H3>2. Getting Started
|
|
</H3>
|
|
<P>This section describes how to build and run LAMMPS, for both new and
|
|
experienced users.
|
|
</P>
|
|
2.1 <A HREF = "#2_1">What's in the LAMMPS distribution</A><BR>
|
|
2.2 <A HREF = "#2_2">Making LAMMPS</A><BR>
|
|
2.3 <A HREF = "#2_3">Making LAMMPS with optional packages</A><BR>
|
|
2.4 <A HREF = "#2_4">Building LAMMPS as a library</A><BR>
|
|
2.5 <A HREF = "#2_5">Running LAMMPS</A><BR>
|
|
2.6 <A HREF = "#2_6">Command-line options</A><BR>
|
|
2.7 <A HREF = "#2_7">Screen output</A><BR>
|
|
2.8 <A HREF = "#2_8">Running on GPUs</A><BR>
|
|
2.9 <A HREF = "#2_9">Tips for users of previous versions</A> <BR>
|
|
|
|
<HR>
|
|
|
|
<H4><A NAME = "2_1"></A>2.1 What's in the LAMMPS distribution
|
|
</H4>
|
|
<P>When you download LAMMPS you will need to unzip and untar the
|
|
downloaded file with the following commands, after placing the file in
|
|
an appropriate directory.
|
|
</P>
|
|
<PRE>gunzip lammps*.tar.gz
|
|
tar xvf lammps*.tar
|
|
</PRE>
|
|
<P>This will create a LAMMPS directory containing two files and several
|
|
sub-directories:
|
|
</P>
|
|
<DIV ALIGN=center><TABLE BORDER=1 >
|
|
<TR><TD >README</TD><TD > text file</TD></TR>
|
|
<TR><TD >LICENSE</TD><TD > the GNU General Public License (GPL)</TD></TR>
|
|
<TR><TD >bench</TD><TD > benchmark problems</TD></TR>
|
|
<TR><TD >couple</TD><TD > code coupling examples, using LAMMPS as a library</TD></TR>
|
|
<TR><TD >doc</TD><TD > documentation</TD></TR>
|
|
<TR><TD >examples</TD><TD > simple test problems</TD></TR>
|
|
<TR><TD >potentials</TD><TD > embedded atom method (EAM) potential files</TD></TR>
|
|
<TR><TD >src</TD><TD > source files</TD></TR>
|
|
<TR><TD >tools</TD><TD > pre- and post-processing tools
|
|
</TD></TR></TABLE></DIV>
|
|
|
|
<P>If you download the Windows executable from the download page,
|
|
then you just get a single file:
|
|
</P>
|
|
<PRE>lmp_windows.exe
|
|
</PRE>
|
|
<P>Skip to the <A HREF = "#2_5">Running LAMMPS</A> section, to learn how to launch this
|
|
executable on a Windows box.
|
|
</P>
|
|
<P>The Windows executable also only includes certain packages and
|
|
bug-fixes/upgrades listed on <A HREF = "http://lammps.sandia.gov/bug.html">this
|
|
page</A> up to a certain date, as
|
|
stated on the download page. If you want something with more packages
|
|
or that is more current, you'll have to download the source tarball
|
|
and build it yourself, as described in the next section.
|
|
</P>
|
|
<HR>
|
|
|
|
<H4><A NAME = "2_2"></A>2.2 Making LAMMPS
|
|
</H4>
|
|
<P>This section has the following sub-sections:
|
|
</P>
|
|
<UL><LI><A HREF = "#2_2_1">Read this first</A>
|
|
<LI><A HREF = "#2_2_2">Building a LAMMPS executable</A>
|
|
<LI><A HREF = "#2_2_3">Common errors that can occur when making LAMMPS</A>
|
|
<LI><A HREF = "#2_2_4">Editing a new low-level Makefile</A>
|
|
<LI><A HREF = "#2_2_5">Additional build tips</A>
|
|
</UL>
|
|
<HR>
|
|
|
|
<A NAME = "2_2_1"></A><B><I>Read this first:</I></B>
|
|
|
|
<P>Building LAMMPS can be non-trivial. You will likely need to edit a
|
|
makefile, there are compiler options, additional libraries can be used
|
|
(MPI, FFT), etc. Please read this section carefully. If you are not
|
|
comfortable with makefiles, or building codes on a Unix platform, or
|
|
running an MPI job on your machine, please find a local expert to help
|
|
you. Many compiling, linking, and run problems that users are not
|
|
really LAMMPS issues - they are peculiar to the user's system,
|
|
compilers, libraries, etc. Such questions are better answered by a
|
|
local expert.
|
|
</P>
|
|
<P>If you have a build problem that you are convinced is a LAMMPS issue
|
|
(e.g. the compiler complains about a line of LAMMPS source code), then
|
|
please send an email to the
|
|
<A HREF = "http://lammps.sandia.gov/authors.html">developers</A>.
|
|
</P>
|
|
<P>If you succeed in building LAMMPS on a new kind of machine, for which
|
|
there isn't a similar Makefile for in the src/MAKE directory, send it
|
|
to the developers and we'll include it in future LAMMPS releases.
|
|
</P>
|
|
<HR>
|
|
|
|
<A NAME = "2_2_2"></A><B><I>Building a LAMMPS executable:</I></B>
|
|
|
|
<P>The src directory contains the C++ source and header files for LAMMPS.
|
|
It also contains a top-level Makefile and a MAKE sub-directory with
|
|
low-level Makefile.* files for several machines. From within the src
|
|
directory, type "make" or "gmake". You should see a list of available
|
|
choices. If one of those is the machine and options you want, you can
|
|
type a command like:
|
|
</P>
|
|
<PRE>make linux
|
|
gmake mac
|
|
</PRE>
|
|
<P>Note that on a multi-processor or multi-core platform you can launch a
|
|
parallel make, by using the "-j" switch with the make command, which
|
|
will build LAMMPS more quickly.
|
|
</P>
|
|
<P>If you get no errors and an executable like lmp_linux or lmp_mac is
|
|
produced, you're done; it's your lucky day.
|
|
</P>
|
|
<HR>
|
|
|
|
<A NAME = "2_2_3"></A><B><I>Common errors that can occur when making LAMMPS:</I></B>
|
|
|
|
<P>(1) If the make command breaks immediately with errors that indicate
|
|
it can't find files with a "*" in their names, this can be because
|
|
your machine's make doesn't support wildcard expansion in a makefile.
|
|
Try gmake instead of make. If that doesn't work, try using a -f
|
|
switch with your make command to use Makefile.list which explicitly
|
|
lists all the needed files, e.g.
|
|
</P>
|
|
<PRE>make makelist
|
|
make -f Makefile.list linux
|
|
gmake -f Makefile.list mac
|
|
</PRE>
|
|
<P>The first "make" command will create a current Makefile.list with all
|
|
the file names in your src dir. The 2nd "make" command (make or
|
|
gmake) will use it to build LAMMPS.
|
|
</P>
|
|
<P>(2) Other errors typically occur because the low-level Makefile isn't
|
|
setup correctly for your machine. If your platform is named "foo",
|
|
you will need to create a Makefile.foo in the MAKE sub-directory. Use
|
|
whatever existing file is closest to your platform as a starting
|
|
point. See the next section for more instructions.
|
|
</P>
|
|
<P>(3) If you get a link-time error about missing libraries or missing
|
|
dependencies, then it can be because:
|
|
</P>
|
|
<UL><LI>you are including a package that needs an extra library, but have not pre-built the necessary <A HREF = "#2_3_3">package library</A>
|
|
<LI>you are linking to a library that doesn't exist on your system
|
|
<LI>you are not linking to the necessary system library
|
|
</UL>
|
|
<P>The first issue is discussed below. The other two issue mean you need
|
|
to edit your low-level Makefile.foo, as discussed in the next
|
|
sub-section.
|
|
</P>
|
|
<HR>
|
|
|
|
<A NAME = "2_2_4"></A><B><I>Editing a new low-level Makefile.foo:</I></B>
|
|
|
|
<P>These are the issues you need to address when editing a low-level
|
|
Makefile for your machine. The portions of the file you typically
|
|
need to edit are the first line, the "compiler/linker settings"
|
|
section, and the "system-specific settings" section.
|
|
</P>
|
|
<P>(1) Change the first line of Makefile.foo to list the word "foo" after
|
|
the "#", and whatever other options you set. This is the line you
|
|
will see if you just type "make".
|
|
</P>
|
|
<P>(3) The "compiler/linker settings" section lists compiler and linker
|
|
settings for your C++ compiler, including optimization flags. You can
|
|
use g++, the open-source GNU compiler, which is available on all Unix
|
|
systems. You can also use mpicc which will typically be available if
|
|
MPI is installed on your system, though you should check which actual
|
|
compiler it wraps. Vendor compilers often produce faster code. On
|
|
boxes with Intel CPUs, we suggest using the free Intel icc compiler,
|
|
which you can download from <A HREF = "http://www.intel.com/software/products/noncom">Intel's compiler site</A>.
|
|
</P>
|
|
|
|
|
|
<P>If building a C++ code on your machine requires additional libraries,
|
|
then you should list them as part of the LIB variable.
|
|
</P>
|
|
<P>The DEPFLAGS setting is what triggers the C++ compiler to create a
|
|
dependency list for a source file. This speeds re-compilation when
|
|
source (*.cpp) or header (*.h) files are edited. Some compilers do
|
|
not support dependency file creation, or may use a different switch
|
|
than -D. GNU g++ works with -D. If your compiler can't create
|
|
dependency files (a long list of errors involving *.d files), then
|
|
you'll need to create a Makefile.foo patterned after Makefile.storm,
|
|
which uses different rules that do not involve dependency files.
|
|
</P>
|
|
<P>(3) The "system-specific settings" section has 4 parts.
|
|
</P>
|
|
<P>(3.a) The LMP_INC variable is used to include options that turn on
|
|
system-dependent ifdefs within the LAMMPS code.
|
|
</P>
|
|
<P>The read_data and dump commands will read/write gzipped files if you
|
|
compile with -DLAMMPS_GZIP. It requires that your Unix support the
|
|
"popen" command. Using one of the -DPACK_ARRAY, -DPACK_POINTER, and
|
|
-DPACK_MEMCPY options can make for faster parallel FFTs (in the PPPM
|
|
solver) on some platforms. The -DPACK_ARRAY setting is the default.
|
|
If you use -DLAMMPS_XDR, the build will include XDR compatibility
|
|
files for doing particle dumps in XTC format. This is only necessary
|
|
if your platform does have its own XDR files available. See the
|
|
Restrictions section of the <A HREF = "dump.html">dump</A> command for details.
|
|
</P>
|
|
<P>(3.b) The 3 MPI variables are used to specify an MPI library to build
|
|
LAMMPS with.
|
|
</P>
|
|
<P>If you want LAMMPS to run in parallel, you must have an MPI library
|
|
installed on your platform. If you use an MPI-wrapped compiler, such
|
|
as "mpicc" to build LAMMPS, you can probably leave these 3 variables
|
|
blank. If you do not use "mpicc" as your compiler/linker, then you
|
|
need to specify where the mpi.h file (MPI_INC) and the MPI library
|
|
(MPI_PATH) is found and its name (MPI_LIB).
|
|
</P>
|
|
<P>If you are installing MPI yourself, we recommend Argonne's MPICH 1.2
|
|
or 2.0 which can be downloaded from the <A HREF = "http://www-unix.mcs.anl.gov/mpi">Argonne MPI
|
|
site</A>. LAM MPI should also work. If
|
|
you are running on a big parallel platform, your system people or the
|
|
vendor should have already installed a version of MPI, which will be
|
|
faster than MPICH or LAM, so find out how to build and link with it.
|
|
If you use MPICH or LAM, you will have to configure and build it for
|
|
your platform. The MPI configure script should have compiler options
|
|
to enable you to use the same compiler you are using for the LAMMPS
|
|
build, which can avoid problems that can arise when linking LAMMPS to
|
|
the MPI library.
|
|
</P>
|
|
<P>If you just want LAMMPS to run on a single processor, you can use the
|
|
STUBS library in place of MPI, since you don't need an MPI library
|
|
installed on your system. See the Makefile.serial file for how to
|
|
specify the 3 MPI variables. You will also need to build the STUBS
|
|
library for your platform before making LAMMPS itself. From the STUBS
|
|
dir, type "make" and it will hopefully create a libmpi.a suitable for
|
|
linking to LAMMPS. If this build fails, you will need to edit the
|
|
STUBS/Makefile for your platform.
|
|
</P>
|
|
<P>The file STUBS/mpi.cpp has a CPU timer function 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.
|
|
</P>
|
|
<P>(3.c) The 3 FFT variables are used to specify an FFT library which
|
|
LAMMPS uses when using the particle-particle particle-mesh (PPPM)
|
|
option in LAMMPS for long-range Coulombics via the
|
|
<A HREF = "kspace_style.html">kspace_style</A> command.
|
|
</P>
|
|
<P>To use this option, you must have a 1d FFT library installed on your
|
|
platform. This is specified by a switch of the form -DFFT_XXX where
|
|
XXX = INTEL, DEC, SGI, SCSL, or FFTW. All but the last one are native
|
|
vendor-provided libraries. FFTW is a fast, portable library that
|
|
should work on any platform. You can download it from
|
|
<A HREF = "http://www.fftw.org">www.fftw.org</A>. Use version 2.1.X, not the newer
|
|
3.0.X. Building FFTW for your box should be as simple as ./configure;
|
|
make. Whichever FFT library you have on your platform, you'll need to
|
|
set the appropriate FFT_INC, FFT_PATH, and FFT_LIB variables in
|
|
Makefile.foo.
|
|
</P>
|
|
<P>If you examine src/fft3d.c and src.fft3d.h you'll see it's possible to
|
|
add other vendor FFT libraries via #ifdef statements in the
|
|
appropriate places. If you successfully add a new FFT option, like
|
|
-DFFT_IBM, please send the LAMMPS developers an email; we'd like to
|
|
add it to LAMMPS.
|
|
</P>
|
|
<P>If you don't plan to use PPPM, you don't need an FFT library. In this
|
|
case you can set FFT_INC to -DFFT_NONE and leave the other 2 FFT
|
|
variables blank. Or you can exclude the KSPACE package when you build
|
|
LAMMPS (see below).
|
|
</P>
|
|
<P>(3.d) The several SYSLIB and SYSPATH variables can be ignored unless
|
|
you are building LAMMPS with one or more of the LAMMPS packages that
|
|
require these extra system libraries. The names of these packages are
|
|
the prefixes on the SYSLIB and SYSPATH variables. See the <A HREF = "#2_3_4">section
|
|
below</A> for more details. The SYSLIB variables list the system
|
|
libraries. The SYSPATH variables are where they are located on your
|
|
machine, which is typically only needed if they are in some
|
|
non-standard place, that is not in your library search path.
|
|
</P>
|
|
<P>That's it. Once you have a correct Makefile.foo and you have
|
|
pre-built any other libraries it will use (e.g. MPI, FFT, package
|
|
libraries), all you need to do from the src directory is type one of
|
|
these 2 commands:
|
|
</P>
|
|
<PRE>make foo
|
|
gmake foo
|
|
</PRE>
|
|
<P>You should get the executable lmp_foo when the build is complete.
|
|
</P>
|
|
<HR>
|
|
|
|
<A NAME = "2_2_5"></A><B><I>Additional build tips:</I></B>
|
|
|
|
<P>(1) Building LAMMPS for multiple platforms.
|
|
</P>
|
|
<P>You can make LAMMPS for multiple platforms from the same src
|
|
directory. Each target creates its own object sub-directory called
|
|
Obj_name where it stores the system-specific *.o files.
|
|
</P>
|
|
<P>(2) Cleaning up.
|
|
</P>
|
|
<P>Typing "make clean-all" or "make clean-foo" will delete *.o object
|
|
files created when LAMMPS is built, for either all builds or for a
|
|
particular machine.
|
|
</P>
|
|
<P>(3) Building for a Mac.
|
|
</P>
|
|
<P>OS X is BSD Unix, so it should just work. See the Makefile.mac file.
|
|
</P>
|
|
<P>(4) Building for MicroSoft Windows.
|
|
</P>
|
|
<P>The LAMMPS download page has an option to download a pre-built Windows
|
|
exeutable. See below for instructions for running this executable on
|
|
a Windows box.
|
|
</P>
|
|
<P>If the pre-built executable doesn't have the options you want, then
|
|
you should be able to build LAMMPS from source files on a Windows box.
|
|
I've never done this, but LAMMPS is just standard C++ with MPI and FFT
|
|
calls. You can use cygwin to build LAMMPS with a Unix make; see
|
|
Makefile.cygwin. Or you should be able to pull all the source files
|
|
into Visual C++ (ugh) or some similar development environment and
|
|
build it. In the src/MAKE/Windows directory are some notes from users
|
|
on how they built LAMMPS under Windows, so you can look at their
|
|
instructions for tips. Good luck - we can't help you on this one.
|
|
</P>
|
|
<HR>
|
|
|
|
<H4><A NAME = "2_3"></A>2.3 Making LAMMPS with optional packages
|
|
</H4>
|
|
<P>This section has the following sub-sections:
|
|
</P>
|
|
<UL><LI><A HREF = "#2_3_1">Package basics</A>
|
|
<LI><A HREF = "#2_3_2">Including/excluding packages</A>
|
|
<LI><A HREF = "#2_3_3">Packages that require extra LAMMPS libraries</A>
|
|
<LI><A HREF = "#2_3_4">Additional Makefile settings for extra libraries</A>
|
|
</UL>
|
|
<HR>
|
|
|
|
<A NAME = "2_3_1"></A><B><I>Package basics:</I></B>
|
|
|
|
<P>The source code for LAMMPS is structured as a large set of core files
|
|
which are always included, plus optional packages. Packages are
|
|
groups of files that enable a specific set of features. For example,
|
|
force fields for molecular systems or granular systems are in
|
|
packages. You can see the list of all packages by typing "make
|
|
package".
|
|
</P>
|
|
<P>The current list of standard packages is as follows:
|
|
</P>
|
|
<DIV ALIGN=center><TABLE BORDER=1 >
|
|
<TR><TD >asphere </TD><TD > aspherical particles and force fields</TD></TR>
|
|
<TR><TD >class2 </TD><TD > class 2 force fields</TD></TR>
|
|
<TR><TD >colloid </TD><TD > colloidal particle force fields</TD></TR>
|
|
<TR><TD >dipole </TD><TD > point dipole particles and force fields</TD></TR>
|
|
<TR><TD >dsmc </TD><TD > Direct Simulation Monte Carlo (DMSC) pair style</TD></TR>
|
|
<TR><TD >gpu </TD><TD > GPU-enabled force field styles</TD></TR>
|
|
<TR><TD >granular </TD><TD > force fields and boundary conditions for granular systems</TD></TR>
|
|
<TR><TD >kspace </TD><TD > long-range Ewald and particle-mesh (PPPM) solvers</TD></TR>
|
|
<TR><TD >manybody </TD><TD > metal, 3-body, bond-order potentials</TD></TR>
|
|
<TR><TD >meam </TD><TD > modified embedded atom method (MEAM) potential</TD></TR>
|
|
<TR><TD >molecule </TD><TD > force fields for molecular systems</TD></TR>
|
|
<TR><TD >opt </TD><TD > optimized versions of a few pair potentials</TD></TR>
|
|
<TR><TD >peri </TD><TD > Peridynamics model and potential</TD></TR>
|
|
<TR><TD >poems </TD><TD > coupled rigid body motion</TD></TR>
|
|
<TR><TD >reax </TD><TD > ReaxFF potential</TD></TR>
|
|
<TR><TD >replica </TD><TD > multi-replica methods</TD></TR>
|
|
<TR><TD >shock </TD><TD > methods for MD simulations of shock loading</TD></TR>
|
|
<TR><TD >srd </TD><TD > stochastic rotation dynamics (SRD)</TD></TR>
|
|
<TR><TD >xtc </TD><TD > dump atom snapshots in XTC format
|
|
</TD></TR></TABLE></DIV>
|
|
|
|
<P>There are also user-contributed packages which may be as simple as a
|
|
single additional file or many files grouped together which add a
|
|
specific functionality to the code.
|
|
</P>
|
|
<P>The difference between a <I>standard</I> package versus a <I>user</I> package is
|
|
as follows.
|
|
</P>
|
|
<P>Standard packages are supported by the LAMMPS developers and are
|
|
written in a syntax and style consistent with the rest of LAMMPS.
|
|
This means we will answer questions about them, debug and fix them if
|
|
necessary, and keep them compatible with future changes to LAMMPS.
|
|
</P>
|
|
<P>User packages don't necessarily meet these requirements. If you have
|
|
problems using a feature provided in a user package, you will likely
|
|
need to contact the contributor directly to get help. Information on
|
|
how to submit additions you make to LAMMPS as a user-contributed
|
|
package is given in <A HREF = "Section_modify.html#package">this section</A> of the
|
|
documentation.
|
|
</P>
|
|
<HR>
|
|
|
|
<A NAME = "2_3_2"></A><B><I>Including/excluding packages:</I></B>
|
|
|
|
<P>Any or all packages can be included or excluded independently BEFORE
|
|
LAMMPS is built.
|
|
</P>
|
|
<P>The two exceptions to this are the "gpu" and "opt" packages. Some of
|
|
the files in these packages require other packages to also be
|
|
included. If this is not the case, then those subsidiary files in
|
|
"gpu" and "opt" will not be installed either. To install all the
|
|
files in package "gpu", the "asphere" package must also be installed.
|
|
To install all the files in package "opt", the "kspace" and "manybody"
|
|
packages must also be installed.
|
|
</P>
|
|
<P>You may wish to exclude certain packages if you will never run certain
|
|
kinds of simulations. This will keep you from having to build
|
|
auxiliary libraries (see below) and will produce a smaller executable
|
|
which may run a bit faster.
|
|
</P>
|
|
<P>By default, LAMMPS includes only the "kspace", "manybody", and
|
|
"molecule" packages.
|
|
</P>
|
|
<P>Packages are included or excluded by typing "make yes-name" or "make
|
|
no-name", where "name" is the name of the package. You can also type
|
|
"make yes-standard", "make no-standard", "make yes-user", "make
|
|
no-user", "make yes-all" or "make no-all" to include/exclude various
|
|
sets of packages. Type "make package" to see the various options.
|
|
</P>
|
|
<P>IMPORTANT NOTE: These make commands work by simply moving files back
|
|
and forth between the main src directory and sub-directories with the
|
|
package name, so that the files are seen or not seen when LAMMPS is
|
|
built. After you have included or excluded a package, you must
|
|
re-build LAMMPS.
|
|
</P>
|
|
<P>Additional make options exist to help manage LAMMPS files that exist
|
|
in both the src directory and in package sub-directories. You do not
|
|
normally need to use these commands unless you are editing LAMMPS
|
|
files or have downloaded a patch from the LAMMPS WWW site.
|
|
</P>
|
|
<P>Typing "make package-update" will overwrite src files with files from
|
|
the package directories if the package has been included. It should
|
|
be used after a patch is installed, since patches only update the
|
|
master package version of a file. Typing "make package-overwrite"
|
|
will overwrite files in the package directories with src files.
|
|
Typing "make package-check" will list differences between src and
|
|
package versions of the same files. Again, type "make package" to see
|
|
the various options.
|
|
</P>
|
|
<HR>
|
|
|
|
<A NAME = "2_3_3"></A><B><I>Packages that require extra LAMMPS libraries:</I></B>
|
|
|
|
<P>A few packages (standard or user) require that additional libraries be
|
|
compiled first, which LAMMPS will link to when it builds. The source
|
|
code for these libraries are included in the LAMMPS distribution under
|
|
the "lib" directory. Look at the README files in the lib directories
|
|
(e.g. lib/reax/README) for instructions on how to build each library.
|
|
</P>
|
|
<P>IMPORTANT NOTE: If you are including a package in your LAMMPS build
|
|
that uses one of these libraries, then you must build the library
|
|
BEFORE building LAMMPS itself, since the LAMMPS build will attempt to
|
|
link with the library file.
|
|
</P>
|
|
<P>Here is a bit of information about each library:
|
|
</P>
|
|
<P>The "atc" library in lib/atc is used by the user-atc package. It
|
|
provides continuum field estimation and molecular dynamics-finite
|
|
element coupling methods. It was written primarily by Reese Jones,
|
|
Jeremy Templeton and Jonathan Zimmerman at Sandia.
|
|
</P>
|
|
<P>The "gpu" library in lib/gpu is used by the gpu package. It
|
|
contains code to enable portions of LAMMPS to run on a GPU chip
|
|
associated with your CPU. Currently, only NVIDIA GPUs are supported.
|
|
Building this library requires NVIDIA Cuda tools to be installed on
|
|
your system. See the <A HREF = "#2_8">Running on GPUs</A> section below for more
|
|
info about installing and using Cuda.
|
|
</P>
|
|
<P>The "meam" library in lib/meam is used by the meam package.
|
|
computes the modified embedded atom method potential, which is a
|
|
generalization of EAM potentials that can be used to model a wider
|
|
variety of materials. This MEAM implementation was written by Greg
|
|
Wagner at Sandia. It requires a F90 compiler to build. The C++ to
|
|
FORTRAN function calls in pair_meam.cpp assumes that FORTRAN object
|
|
names are converted to C object names by appending an underscore
|
|
character. This is generally the case, but on machines that do not
|
|
conform to this convention, you will need to modify either the C++
|
|
code or your compiler settings.
|
|
</P>
|
|
<P>The "poems" library in lib/poems is used by the poems package.
|
|
computes the constrained rigid-body motion of articulated (jointed)
|
|
multibody systems. POEMS was written and is distributed by Prof Kurt
|
|
Anderson's group at Rensselaer Polytechnic Institute (RPI).
|
|
</P>
|
|
<P>The "reax" library in lib/reax is used by the reax package. It
|
|
computes the Reactive Force Field (ReaxFF) potential, developed by
|
|
Adri van Duin in Bill Goddard's group at CalTech. This implementation
|
|
in LAMMPS uses many of Adri's files and was developed by Aidan
|
|
Thompson at Sandia and Hansohl Cho at MIT. It requires a F77 or F90
|
|
compiler to build. The C++ to FORTRAN function calls in pair_reax.cpp
|
|
assume that FORTRAN object names are converted to C object names by
|
|
appending an underscore character. This is generally the case, but on
|
|
machines that do not conform to this convention, you will need to
|
|
modify either the C++ code or your compiler settings. The name
|
|
conversion is handled by the preprocessor macro called FORTRAN in
|
|
pair_reax_fortran.h. Different definitions of this macro can be
|
|
obtained by adding a machine-specific macro definition to the CCFLAGS
|
|
variable in your Makefile e.g. -D_IBM. See pair_reax_fortran.h for
|
|
more info.
|
|
</P>
|
|
<P>As described in its README file, each library is built by typing
|
|
something like
|
|
</P>
|
|
<PRE>make -f Makefile.g++
|
|
</PRE>
|
|
<P>in the appropriate directory, e.g. in lib/reax.
|
|
</P>
|
|
<P>You must use a Makefile that is a match for your system. If one of
|
|
the provided Makefiles is not appropriate for your system you will
|
|
need to edit or add one. For example, in the case of Fotran-based
|
|
libraries, your system must have a Fortran compiler, the settings for
|
|
which will be in the Makefile.
|
|
</P>
|
|
<HR>
|
|
|
|
<A NAME = "2_3_4"></A><B><I>Additional Makefile settings for extra libraries:</I></B>
|
|
|
|
<P>After the desired library or libraries are built, and the package has
|
|
been included, you can build LAMMPS itself. For example, from the
|
|
lammps/src directory you would type this, to build LAMMPS with ReaxFF.
|
|
Note that as discussed in the preceding section, the package library
|
|
itself, namely lib/reax/libreax.a, must already have been built, for
|
|
the LAMMPS build to be successful.
|
|
</P>
|
|
<PRE>make yes-reax
|
|
make g++
|
|
</PRE>
|
|
<P>Also note that simply building the library is not sufficient to use it
|
|
from LAMMPS. As in this example, you must also include the package
|
|
that uses and wraps the library before you build LAMMPS itself.
|
|
</P>
|
|
<P>As discussed in point (2.4) of <A HREF = "#2_2_4">this section</A> above, there are
|
|
settings in the low-level Makefile that specify additional system
|
|
libraries needed by individual LAMMPS add-on libraries. These are the
|
|
settings you must specify correctly in your low-level Makefile in
|
|
lammps/src/MAKE, such as Makefile.foo:
|
|
</P>
|
|
<P>To use the gpu package and library, the settings for gpu_SYSLIB and
|
|
gpu_SYSPATH must be correct. These are specific to the NVIDIA CUDA
|
|
software which must be installed on your system.
|
|
</P>
|
|
<P>To use the meam or reax packages and their libraries which are Fortran
|
|
based, the settings for meam_SYSLIB, reax_SYSLIB, meam_SYSPATH, and
|
|
reax_SYSPATH must be correct. This is so that the C++ compiler can
|
|
perform a cross-language link using the appropriate system Fortran
|
|
libraries.
|
|
</P>
|
|
<P>To use the user-atc package and library, the settings for
|
|
user-atc_SYSLIB and user-atc_SYSPATH must be correct. This is so that
|
|
the appropriate BLAS and LAPACK libs, used by the user-atc library,
|
|
can be found.
|
|
</P>
|
|
<HR>
|
|
|
|
<H4><A NAME = "2_4"></A>2.4 Building LAMMPS as a library
|
|
</H4>
|
|
<P>LAMMPS can be built as a library, which can then be called from
|
|
another application or a scripting language. See <A HREF = "Section_howto.html#4_10">this
|
|
section</A> for more info on coupling LAMMPS to
|
|
other codes. Building LAMMPS as a library is done by typing
|
|
</P>
|
|
<PRE>make makelib
|
|
make -f Makefile.lib foo
|
|
</PRE>
|
|
<P>where foo is the machine name. The first "make" command will create a
|
|
current Makefile.lib with all the file names in your src dir. The 2nd
|
|
"make" command will use it to build LAMMPS as a library. This
|
|
requires that Makefile.foo have a library target (lib) and
|
|
system-specific settings for ARCHIVE and ARFLAGS. See Makefile.linux
|
|
for an example. The build will create the file liblmp_foo.a which
|
|
another application can link to.
|
|
</P>
|
|
<P>When used from a C++ program, the library allows one or more LAMMPS
|
|
objects to be instantiated. All of LAMMPS is wrapped in a LAMMPS_NS
|
|
namespace; you can safely use any of its classes and methods from
|
|
within your application code, as needed.
|
|
</P>
|
|
<P>When used from a C or Fortran program or a scripting language, the
|
|
library has a simple function-style interface, provided in
|
|
src/library.cpp and src/library.h.
|
|
</P>
|
|
<P>See the sample codes couple/simple/simple.cpp and simple.c as examples
|
|
of C++ and C codes that invoke LAMMPS thru its library interface.
|
|
There are other examples as well in the couple directory which are
|
|
discussed in <A HREF = "Section_howto.html#4_10">this section</A> of the manual.
|
|
See <A HREF = "Section_python.html">this section</A> of the manual for a description
|
|
of the Python wrapper provided with LAMMPS that operates through the
|
|
LAMMPS library interface.
|
|
</P>
|
|
<P>The files src/library.cpp and library.h contain the C-style interface
|
|
to LAMMPS. See <A HREF = "Section_howto.html#4_19">this section</A> of the manual
|
|
for a description of the interface and how to extend it for your
|
|
needs.
|
|
</P>
|
|
<HR>
|
|
|
|
<H4><A NAME = "2_5"></A>2.5 Running LAMMPS
|
|
</H4>
|
|
<P>By default, LAMMPS runs by reading commands from stdin; e.g. lmp_linux
|
|
< in.file. This means you first create an input script (e.g. in.file)
|
|
containing the desired commands. <A HREF = "Section_commands.html">This section</A>
|
|
describes how input scripts are structured and what commands they
|
|
contain.
|
|
</P>
|
|
<P>You can test LAMMPS on any of the sample inputs provided in the
|
|
examples directory. Input scripts are named in.* and sample outputs
|
|
are named log.*.name.P where name is a machine and P is the number of
|
|
processors it was run on.
|
|
</P>
|
|
<P>Here is how you might run one of the Lennard-Jones tests on a Linux
|
|
box, using mpirun to launch a parallel job:
|
|
</P>
|
|
<PRE>cd src
|
|
make linux
|
|
cp lmp_linux ../examples/lj
|
|
cd ../examples/lj
|
|
mpirun -np 4 lmp_linux < in.lj.nve
|
|
</PRE>
|
|
<HR>
|
|
|
|
<P>On a Windows machine, you can skip making LAMMPS and simply download
|
|
an executable. But note that not all packages are available.
|
|
The following packages are available: asphere, class2, colloid, dipole,
|
|
dsmc, granular, kspace, manybody, molecule, peri, poems, replica, shock,
|
|
user-ackland, user-cd-eam, user-cg-cmm, user-ewaldn, user-smd. But these
|
|
packages are not available: gpu, meam, opt, reax, xtc, user-atc, user-imd.
|
|
</P>
|
|
<P>To run the LAMMPS executable on a Windows machine, first decide whether
|
|
you want to download the non-MPI (serial) or the MPI (parallel) version
|
|
of the executable. Download and save the version you have chosen.
|
|
</P>
|
|
<P>For the non-MPI version, follow these steps:
|
|
</P>
|
|
<UL><LI>Get a command prompt by going to Start->Run... ,
|
|
then typing "cmd".
|
|
|
|
<LI>Move to the directory where you have saved lmp_win_no-mpi.exe
|
|
(e.g. by typing: cd "Documents").
|
|
|
|
<LI>At the command prompt, type "lmp_win_no-mpi -in in.lj", replacing in.lj
|
|
with the name of your LAMMPS input script.
|
|
</UL>
|
|
<P>For the MPI version, which allows you to run LAMMPS under Windows on
|
|
multiple processors, follow these steps:
|
|
</P>
|
|
<UL><LI>Download and install
|
|
<A HREF = "http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downloads">MPICH2</A>
|
|
for Windows.
|
|
|
|
<LI>You'll need to use the mpiexec.exe and smpd.exe files from the MPICH2 package. Put them in
|
|
same directory (or path) as the LAMMPS Windows executable.
|
|
|
|
<LI>Get a command prompt by going to Start->Run... ,
|
|
then typing "cmd".
|
|
|
|
<LI>Move to the directory where you have saved lmp_win_mpi.exe
|
|
(e.g. by typing: cd "Documents").
|
|
|
|
<LI>Then type something like this: "mpiexec -np 4 -localonly lmp_win_mpi -in in.lj",
|
|
replacing in.lj with the name of your LAMMPS input script.
|
|
|
|
<LI>Note that you may need to provide smpd with a passphrase --- it doesn't matter what you
|
|
type.
|
|
|
|
<LI>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.
|
|
|
|
<LI>Alternatively, you can still use this executable to run on a single processor by
|
|
typing something like: "lmp_win_mpi -in in.lj".
|
|
</UL>
|
|
<HR>
|
|
|
|
<P>The screen output from LAMMPS is described in the next section. As it
|
|
runs, LAMMPS also writes a log.lammps file with the same information.
|
|
</P>
|
|
<P>Note that this sequence of commands copies the LAMMPS executable
|
|
(lmp_linux) to the directory with the input files. This may not be
|
|
necessary, but some versions of MPI reset the working directory to
|
|
where the executable is, rather than leave it as the directory where
|
|
you launch mpirun from (if you launch lmp_linux on its own and not
|
|
under mpirun). If that happens, LAMMPS will look for additional input
|
|
files and write its output files to the executable directory, rather
|
|
than your working directory, which is probably not what you want.
|
|
</P>
|
|
<P>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 <A HREF = "Section_errors.html">this section</A> 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.
|
|
</P>
|
|
<P>LAMMPS can run a 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.
|
|
</P>
|
|
<P>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 setup a smaller problem.
|
|
</P>
|
|
<HR>
|
|
|
|
<H4><A NAME = "2_6"></A>2.6 Command-line options
|
|
</H4>
|
|
<P>At run time, LAMMPS recognizes several optional command-line switches
|
|
which may be used in any order. For example, lmp_ibm might be
|
|
launched as follows:
|
|
</P>
|
|
<PRE>mpirun -np 16 lmp_ibm -var f tmp.out -log my.log -screen none < in.alloy
|
|
</PRE>
|
|
<P>These are the command-line options:
|
|
</P>
|
|
<PRE>-echo style
|
|
</PRE>
|
|
<P>Set the style of command echoing. The style can be <I>none</I> or <I>screen</I>
|
|
or <I>log</I> or <I>both</I>. 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 <I>log</I>. The echo style can also be
|
|
set by using the <A HREF = "echo.html">echo</A> command in the input script itself.
|
|
</P>
|
|
<PRE>-partition 8x2 4 5 ...
|
|
</PRE>
|
|
<P>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.
|
|
</P>
|
|
<P>Note that with MPI installed on a machine (e.g. your desktop), you can
|
|
run on more (virtual) processors than you have physical processors.
|
|
This can be useful for running <A HREF = "Section_howto.html#4_5">multi-replica
|
|
simulations</A>, on one or a few processors.
|
|
</P>
|
|
<P>The input script specifies what simulation is run on which partition;
|
|
see the <A HREF = "variable.html">variable</A> and <A HREF = "next.html">next</A> commands. This
|
|
<A HREF = "Section_howto.html#4_4">howto section</A> gives examples of how to use
|
|
these commands in this way. Simulations running on different
|
|
partitions can also communicate with each other; see the
|
|
<A HREF = "temper.html">temper</A> command.
|
|
</P>
|
|
<PRE>-in file
|
|
</PRE>
|
|
<P>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 input script from stdin - e.g. lmp_linux < in.run.
|
|
This is a required switch when running LAMMPS in multi-partition mode,
|
|
since multiple processors cannot all read from stdin.
|
|
</P>
|
|
<PRE>-log file
|
|
</PRE>
|
|
<P>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
|
|
<A HREF = "log.html">log</A> command in the input script will override this setting.
|
|
</P>
|
|
<PRE>-screen file
|
|
</PRE>
|
|
<P>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.
|
|
</P>
|
|
<PRE>-var name value
|
|
</PRE>
|
|
<P>Specify a variable that will be defined for substitution purposes when
|
|
the input script is read. "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}). The value can be any string. Using
|
|
this command-line option is equivalent to putting the line "variable
|
|
name index value" 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 <A HREF = "variable.html">variable</A> command for
|
|
more info on defining index and other kinds of variables and <A HREF = "Section_commands.html#3_2">this
|
|
section</A> for more info on using variables in
|
|
input scripts.
|
|
</P>
|
|
<HR>
|
|
|
|
<H4><A NAME = "2_7"></A>2.7 LAMMPS screen output
|
|
</H4>
|
|
<P>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 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 then
|
|
appends statistics about the CPU time and storage requirements for the
|
|
simulation. An example set of statistics is shown here:
|
|
</P>
|
|
<PRE>Loop time of 49.002 on 2 procs for 2004 atoms
|
|
</PRE>
|
|
<PRE>Pair time (%) = 35.0495 (71.5267)
|
|
Bond time (%) = 0.092046 (0.187841)
|
|
Kspce time (%) = 6.42073 (13.103)
|
|
Neigh time (%) = 2.73485 (5.5811)
|
|
Comm time (%) = 1.50291 (3.06703)
|
|
Outpt time (%) = 0.013799 (0.0281601)
|
|
Other time (%) = 2.13669 (4.36041)
|
|
</PRE>
|
|
<PRE>Nlocal: 1002 ave, 1015 max, 989 min
|
|
Histogram: 1 0 0 0 0 0 0 0 0 1
|
|
Nghost: 8720 ave, 8724 max, 8716 min
|
|
Histogram: 1 0 0 0 0 0 0 0 0 1
|
|
Neighs: 354141 ave, 361422 max, 346860 min
|
|
Histogram: 1 0 0 0 0 0 0 0 0 1
|
|
</PRE>
|
|
<PRE>Total # of neighbors = 708282
|
|
Ave neighs/atom = 353.434
|
|
Ave special neighs/atom = 2.34032
|
|
Number of reneighborings = 42
|
|
Dangerous reneighborings = 2
|
|
</PRE>
|
|
<P>The first section gives the breakdown of the CPU run time (in seconds)
|
|
into major categories. The second section 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.
|
|
</P>
|
|
<P>The last section gives aggregate statistics for pair-wise neighbors
|
|
and special neighbors that LAMMPS keeps track of (see the
|
|
<A HREF = "special_bonds.html">special_bonds</A> command). The number of times
|
|
neighbor lists were rebuilt during the run is given as well as the
|
|
number of potentially "dangerous" rebuilds. If atom movement
|
|
triggered neighbor list rebuilding (see the
|
|
<A HREF = "neigh_modify.html">neigh_modify</A> 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.
|
|
</P>
|
|
<P>If an energy minimization was performed via the
|
|
<A HREF = "minimize.html">minimize</A> command, additional information is printed,
|
|
e.g.
|
|
</P>
|
|
<PRE>Minimization stats:
|
|
E initial, next-to-last, final = -0.895962 -2.94193 -2.94342
|
|
Gradient 2-norm init/final= 1920.78 20.9992
|
|
Gradient inf-norm init/final= 304.283 9.61216
|
|
Iterations = 36
|
|
Force evaluations = 177
|
|
</PRE>
|
|
<P>The first 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 force vector; the inf-norm is the largest component.
|
|
The last 2 lines are 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.
|
|
</P>
|
|
<P>If a <A HREF = "kspace_style.html">kspace_style</A> long-range Coulombics solve was
|
|
performed during the run (PPPM, Ewald), then additional information is
|
|
printed, e.g.
|
|
</P>
|
|
<PRE>FFT time (% of Kspce) = 0.200313 (8.34477)
|
|
FFT Gflps 3d 1d-only = 2.31074 9.19989
|
|
</PRE>
|
|
<P>The first line gives the time spent doing 3d FFTs (4 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.
|
|
</P>
|
|
<HR>
|
|
|
|
<H4><A NAME = "2_8"></A>2.8 Running on GPUs
|
|
</H4>
|
|
<P>A few LAMMPS <A HREF = "pair_style.html">pair styles</A> can be run on graphical
|
|
processing units (GPUs). We plan to add more over time. Currently,
|
|
they only support NVIDIA GPU cards. To use them you need to install
|
|
certain NVIDIA CUDA software on your system:
|
|
</P>
|
|
<UL><LI>Check if you have an NVIDIA card: cat /proc/driver/nvidia/cards/0
|
|
<LI>Go to http://www.nvidia.com/object/cuda_get.html
|
|
<LI>Install a driver and toolkit appopriate for your system (SDK is not necessary)
|
|
<LI>Run make in lammps/lib/gpu, editing a Makefile if necessary
|
|
<LI>Run lammps/lib/gpu/nvc_get_devices to list supported devices and properties
|
|
</UL>
|
|
<H4>GPU hardware
|
|
</H4>
|
|
<P>When using GPUs, you are restricted to one physical GPU per LAMMPS
|
|
process. This can be multiple GPUs on a single node or across
|
|
multiple nodes. For each GPU pair style, the first two arguments (GPU
|
|
mode followed by GPU ID) control how GPUs are selected. If you are
|
|
running on a single node, the mode is "one/node" and the parameter is
|
|
the ID of the first GPU to select:
|
|
</P>
|
|
<PRE>pair_style lj/cut/gpu one/node 0 2.5
|
|
</PRE>
|
|
<P>The ID is the GPU ID reported by the driver for CUDA enabled graphics
|
|
cards. For multiple GPU cards on a node, an MPI process should be run
|
|
for each graphics card. In this case, each process will grab the GPU
|
|
with ID equal to the process rank plus the GPU parameter.
|
|
</P>
|
|
<P>For multiple nodes with one GPU per node, the mode is "one/gpu" and
|
|
the parameter is the ID of the GPU used on every node:
|
|
</P>
|
|
<PRE>pair_style lj/cut/gpu one/gpu 1 2.5
|
|
</PRE>
|
|
<P>In this case, MPI should be run with exactly one process per node.
|
|
</P>
|
|
<P>For multiple nodes with multiple GPUs, the mode is "multi/gpu" and the
|
|
parameter is the number of GPUs per node:
|
|
</P>
|
|
<PRE>pair_style lj/cut/gpu multi/gpu 3 2.5
|
|
</PRE>
|
|
<P>In this case, LAMMPS will attempt to grab 3 GPUs per node and this
|
|
requires that the number of processes per node be 3. The first GPU
|
|
selected must have ID zero for this mode (in the example, GPUs 0, 1,
|
|
and 2 will be selected on every node). An additional constraint is
|
|
that the MPI processes must be filled by slot on each node such that
|
|
the process ranks on each node are always sequential. This is a option
|
|
for the MPI launcher (mpirun/mpiexec) and will be the default on many
|
|
clusters.
|
|
</P>
|
|
<H4>GPU single vs double precision
|
|
</H4>
|
|
<P>See the lammps/lib/gpu/README file for instructions on how to build
|
|
the LAMMPS gpu library for single vs double precision. The latter
|
|
requires that your GPU card supports double precision. The lj/cut/gpu
|
|
pair style does not support double precision.
|
|
</P>
|
|
<HR>
|
|
|
|
<H4><A NAME = "2_9"></A>2.9 Tips for users of previous LAMMPS versions
|
|
</H4>
|
|
<P>The current C++ began with a complete rewrite of LAMMPS 2001, which
|
|
was written in F90. Features of earlier versions of LAMMPS are listed
|
|
in <A HREF = "Section_history.html">this section</A>. The F90 and F77 versions
|
|
(2001 and 99) are also freely distributed as open-source codes; check
|
|
the <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> for distribution information if you prefer
|
|
those versions. The 99 and 2001 versions are no longer under active
|
|
development; they do not have all the features of C++ LAMMPS.
|
|
</P>
|
|
<P>If you are a previous user of LAMMPS 2001, these are the most
|
|
significant changes you will notice in C++ LAMMPS:
|
|
</P>
|
|
<P>(1) The names and arguments of many input script commands have
|
|
changed. All commands are now a single word (e.g. read_data instead
|
|
of read data).
|
|
</P>
|
|
<P>(2) All the functionality of LAMMPS 2001 is included in C++ LAMMPS,
|
|
but you may need to specify the relevant commands in different ways.
|
|
</P>
|
|
<P>(3) The format of the data file can be streamlined for some problems.
|
|
See the <A HREF = "read_data.html">read_data</A> command for details. The data file
|
|
section "Nonbond Coeff" has been renamed to "Pair Coeff" in C++ LAMMPS.
|
|
</P>
|
|
<P>(4) Binary restart files written by LAMMPS 2001 cannot be read by C++
|
|
LAMMPS with a <A HREF = "read_restart.html">read_restart</A> command. This is
|
|
because they were output by F90 which writes in a different binary
|
|
format than C or C++ writes or reads. Use the <I>restart2data</I> tool
|
|
provided with LAMMPS 2001 to convert the 2001 restart file to a text
|
|
data file. Then edit the data file as necessary before using the C++
|
|
LAMMPS <A HREF = "read_data.html">read_data</A> command to read it in.
|
|
</P>
|
|
<P>(5) There are numerous small numerical changes in C++ LAMMPS that mean
|
|
you will not get identical answers when comparing to a 2001 run.
|
|
However, your initial thermodynamic energy and MD trajectory should be
|
|
close if you have setup the problem for both codes the same.
|
|
</P>
|
|
</HTML>
|