2006-09-22 00:22:34 +08:00
|
|
|
<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>
|
2009-09-25 01:42:17 +08:00
|
|
|
<P>This section describes how to build and run LAMMPS, for both new and
|
|
|
|
|
experienced users.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-08-26 00:46:23 +08:00
|
|
|
2.1 <A HREF = "#start_1">What's in the LAMMPS distribution</A><BR>
|
|
|
|
|
2.2 <A HREF = "#start_2">Making LAMMPS</A><BR>
|
|
|
|
|
2.3 <A HREF = "#start_3">Making LAMMPS with optional packages</A><BR>
|
2012-01-28 07:39:14 +08:00
|
|
|
2.4 <A HREF = "#start_4">Building LAMMPS via the Make.py script</A><BR>
|
|
|
|
|
2.5 <A HREF = "#start_5">Building LAMMPS as a library</A><BR>
|
|
|
|
|
2.6 <A HREF = "#start_6">Running LAMMPS</A><BR>
|
|
|
|
|
2.7 <A HREF = "#start_7">Command-line options</A><BR>
|
|
|
|
|
2.8 <A HREF = "#start_8">Screen output</A><BR>
|
|
|
|
|
2.9 <A HREF = "#start_9">Tips for users of previous versions</A> <BR>
|
2006-09-22 00:22:34 +08:00
|
|
|
|
|
|
|
|
<HR>
|
|
|
|
|
|
2011-12-09 08:44:47 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<H4><A NAME = "start_1"></A>2.1 What's in the LAMMPS distribution
|
2006-09-22 00:22:34 +08:00
|
|
|
</H4>
|
2007-06-04 23:32:50 +08:00
|
|
|
<P>When you download LAMMPS you will need to unzip and untar the
|
2006-09-22 00:22:34 +08:00
|
|
|
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>
|
2012-02-01 23:47:19 +08:00
|
|
|
<DIV ALIGN=center><TABLE BORDER=1 >
|
2006-09-22 00:22:34 +08:00
|
|
|
<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 >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>
|
|
|
|
|
|
2011-06-14 08:14:59 +08:00
|
|
|
<P>If you download one of the Windows executables from the download page,
|
2014-05-22 22:20:18 +08:00
|
|
|
then you get a single file:
|
2009-10-27 07:21:50 +08:00
|
|
|
</P>
|
|
|
|
|
<PRE>lmp_windows.exe
|
|
|
|
|
</PRE>
|
2012-01-28 07:39:14 +08:00
|
|
|
<P>Skip to the <A HREF = "#start_6">Running LAMMPS</A> sections for info on how to
|
2011-08-26 00:46:23 +08:00
|
|
|
launch these executables on a Windows box.
|
2009-10-27 07:21:50 +08:00
|
|
|
</P>
|
2011-06-14 08:14:59 +08:00
|
|
|
<P>The Windows executables for serial or parallel only include certain
|
|
|
|
|
packages and bug-fixes/upgrades listed on <A HREF = "http://lammps.sandia.gov/bug.html">this
|
2009-10-27 07:21:50 +08:00
|
|
|
page</A> up to a certain date, as
|
|
|
|
|
stated on the download page. If you want something with more packages
|
2009-10-30 01:54:40 +08:00
|
|
|
or that is more current, you'll have to download the source tarball
|
2011-06-14 08:14:59 +08:00
|
|
|
and build it yourself from source code using Microsoft Visual Studio,
|
|
|
|
|
as described in the next section.
|
2009-10-27 07:21:50 +08:00
|
|
|
</P>
|
2006-09-22 00:22:34 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<H4><A NAME = "start_2"></A>2.2 Making LAMMPS
|
2006-09-22 00:22:34 +08:00
|
|
|
</H4>
|
2009-09-25 01:42:17 +08:00
|
|
|
<P>This section has the following sub-sections:
|
|
|
|
|
</P>
|
2011-08-26 00:46:23 +08:00
|
|
|
<UL><LI><A HREF = "#start_2_1">Read this first</A>
|
|
|
|
|
<LI><A HREF = "#start_2_2">Steps to build a LAMMPS executable</A>
|
|
|
|
|
<LI><A HREF = "#start_2_3">Common errors that can occur when making LAMMPS</A>
|
|
|
|
|
<LI><A HREF = "#start_2_4">Additional build tips</A>
|
|
|
|
|
<LI><A HREF = "#start_2_5">Building for a Mac</A>
|
|
|
|
|
<LI><A HREF = "#start_2_6">Building for Windows</A>
|
2009-09-25 01:42:17 +08:00
|
|
|
</UL>
|
|
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<A NAME = "start_2_1"></A><B><I>Read this first:</I></B>
|
2009-09-25 01:42:17 +08:00
|
|
|
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>Building LAMMPS can be non-trivial. You may need to edit a makefile,
|
|
|
|
|
there are compiler options to consider, additional libraries can be
|
2013-10-30 23:10:46 +08:00
|
|
|
used (MPI, FFT, JPEG, PNG), LAMMPS packages may be included or
|
|
|
|
|
excluded, some of these packages use auxiliary libraries which need to
|
|
|
|
|
be pre-built, etc.
|
2011-08-19 01:31:58 +08:00
|
|
|
</P>
|
|
|
|
|
<P>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
|
2012-01-28 07:39:14 +08:00
|
|
|
compiling, linking, and run problems that users have are often not
|
2011-08-19 01:31:58 +08:00
|
|
|
LAMMPS issues - they are peculiar to the user's system, compilers,
|
|
|
|
|
libraries, etc. Such questions are better answered by a local expert.
|
2006-09-22 00:22:34 +08:00
|
|
|
</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
|
2012-01-28 07:39:14 +08:00
|
|
|
please post a question to the <A HREF = "http://lammps.sandia.gov/mail.html">LAMMPS mail
|
|
|
|
|
list</A>.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2009-10-30 01:54:40 +08:00
|
|
|
<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
|
2012-01-28 07:39:14 +08:00
|
|
|
to the developers and we can include it in the LAMMPS distribution.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2009-09-25 01:42:17 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<A NAME = "start_2_2"></A><B><I>Steps to build a LAMMPS executable:</I></B>
|
2009-09-25 01:42:17 +08:00
|
|
|
|
2011-08-19 01:31:58 +08:00
|
|
|
<P><B>Step 0</B>
|
|
|
|
|
</P>
|
2006-09-22 00:22:34 +08:00
|
|
|
<P>The src directory contains the C++ source and header files for LAMMPS.
|
2007-05-01 08:14:45 +08:00
|
|
|
It also contains a top-level Makefile and a MAKE sub-directory with
|
2011-08-19 01:31:58 +08:00
|
|
|
low-level Makefile.* files for many machines. From within the src
|
2006-09-22 00:22:34 +08:00
|
|
|
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
|
2011-08-19 01:31:58 +08:00
|
|
|
or
|
2006-09-22 00:22:34 +08:00
|
|
|
gmake mac
|
|
|
|
|
</PRE>
|
2008-05-27 22:06:53 +08:00
|
|
|
<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
|
2009-10-30 01:54:40 +08:00
|
|
|
will build LAMMPS more quickly.
|
2008-05-27 22:06:53 +08:00
|
|
|
</P>
|
2006-09-22 00:22:34 +08:00
|
|
|
<P>If you get no errors and an executable like lmp_linux or lmp_mac is
|
2007-02-10 05:37:30 +08:00
|
|
|
produced, you're done; it's your lucky day.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2012-03-01 23:12:16 +08:00
|
|
|
<P>Note that by default only a few of LAMMPS optional packages are
|
2011-08-26 00:46:23 +08:00
|
|
|
installed. To build LAMMPS with optional packages, see <A HREF = "#start_3">this
|
2011-08-19 01:31:58 +08:00
|
|
|
section</A> below.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P><B>Step 1</B>
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>If Step 0 did not work, you will need to create a low-level Makefile
|
|
|
|
|
for your machine, like Makefile.foo. You should make a copy of an
|
|
|
|
|
existing src/MAKE/Makefile.* as a starting point. The only portions
|
|
|
|
|
of the file you need to edit are the first line, the "compiler/linker
|
|
|
|
|
settings" section, and the "LAMMPS-specific settings" section.
|
2011-08-01 22:07:27 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P><B>Step 2</B>
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>Change the first line of src/MAKE/Makefile.foo to list the word "foo"
|
|
|
|
|
after the "#", and whatever other options it will set. This is the
|
|
|
|
|
line you will see if you just type "make".
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P><B>Step 3</B>
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>The "compiler/linker settings" section lists compiler and linker
|
2009-10-30 05:37:40 +08:00
|
|
|
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
|
2011-08-17 00:37:29 +08:00
|
|
|
boxes with Intel CPUs, we suggest using the commercial Intel icc
|
|
|
|
|
compiler, which can be downloaded from <A HREF = "http://www.intel.com/software/products/noncom">Intel's compiler site</A>.
|
2009-10-30 05:37:40 +08:00
|
|
|
</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
|
2011-08-01 22:07:27 +08:00
|
|
|
dependency files, then you'll need to create a Makefile.foo patterned
|
|
|
|
|
after Makefile.storm, which uses different rules that do not involve
|
|
|
|
|
dependency files. Note that when you build LAMMPS for the first time
|
|
|
|
|
on a new platform, 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.
|
2009-10-30 05:37:40 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P><B>Step 4</B>
|
|
|
|
|
</P>
|
|
|
|
|
<P>The "system-specific settings" section has several parts. Note that
|
|
|
|
|
if you change any -D setting in this section, you should do a full
|
|
|
|
|
re-compile, after typing "make clean" (which will describe different
|
|
|
|
|
clean options).
|
2009-09-29 00:20:03 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>The LMP_INC variable is used to include options that turn on ifdefs
|
|
|
|
|
within the LAMMPS code. The options that are currently recogized are:
|
2011-04-12 03:49:41 +08:00
|
|
|
</P>
|
|
|
|
|
<UL><LI>-DLAMMPS_GZIP
|
2011-08-19 04:48:51 +08:00
|
|
|
<LI>-DLAMMPS_JPEG
|
2013-10-30 23:10:46 +08:00
|
|
|
<LI>-DLAMMPS_PNG
|
2013-11-05 00:59:03 +08:00
|
|
|
<LI>-DLAMMPS_FFMPEG
|
2011-12-01 23:35:32 +08:00
|
|
|
<LI>-DLAMMPS_MEMALIGN
|
2011-08-19 04:48:51 +08:00
|
|
|
<LI>-DLAMMPS_XDR
|
|
|
|
|
<LI>-DLAMMPS_SMALLBIG
|
|
|
|
|
<LI>-DLAMMPS_BIGBIG
|
|
|
|
|
<LI>-DLAMMPS_SMALLSMALL
|
|
|
|
|
<LI>-DLAMMPS_LONGLONG_TO_LONG
|
2011-04-12 03:49:41 +08:00
|
|
|
<LI>-DPACK_ARRAY
|
|
|
|
|
<LI>-DPACK_POINTER
|
2011-08-19 04:48:51 +08:00
|
|
|
<LI>-DPACK_MEMCPY
|
2011-04-12 03:49:41 +08:00
|
|
|
</UL>
|
2009-10-30 01:54:40 +08:00
|
|
|
<P>The read_data and dump commands will read/write gzipped files if you
|
2013-11-05 00:59:03 +08:00
|
|
|
compile with -DLAMMPS_GZIP. It 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.
|
2011-04-12 03:49:41 +08:00
|
|
|
</P>
|
2013-11-05 00:59:03 +08:00
|
|
|
<P>If you use -DLAMMPS_JPEG, the <A HREF = "dump_image.html">dump image</A> command
|
|
|
|
|
will be able to write out JPEG image files. For JPEG files, you must
|
|
|
|
|
also link LAMMPS with a JPEG library, as described below. If you use
|
2013-10-30 23:10:46 +08:00
|
|
|
-DLAMMPS_PNG, the <A HREF = "dump.html">dump image</A> command will be able to write
|
|
|
|
|
out PNG image files. For PNG files, you must also link LAMMPS with a
|
|
|
|
|
PNG library, as described below. If neither of those two defines are
|
2013-11-05 00:59:03 +08:00
|
|
|
used, LAMMPS will only be able to write out uncompressed PPM image
|
2013-10-30 23:10:46 +08:00
|
|
|
files.
|
2011-04-12 03:49:41 +08:00
|
|
|
</P>
|
2013-11-05 00:59:03 +08:00
|
|
|
<P>If you use -DLAMMPS_FFMPEG, the <A HREF = "dump_image.html">dump movie</A> command
|
|
|
|
|
will be available to support on-the-fly generation of rendered movies
|
|
|
|
|
the need to store intermediate image files. It requires that your
|
|
|
|
|
machines supports the "popen" function in the standard runtime library
|
|
|
|
|
and that an FFmpeg executable can be found by LAMMPS during the run.
|
|
|
|
|
</P>
|
2011-12-01 23:35:32 +08:00
|
|
|
<P>Using -DLAMMPS_MEMALIGN=<bytes> enables the use of the
|
|
|
|
|
posix_memalign() call instead of malloc() when large chunks or memory
|
|
|
|
|
are allocated by LAMMPS. This can help to make more efficient use of
|
|
|
|
|
vector instructions of modern CPUS, since dynamically allocated memory
|
|
|
|
|
has to be aligned on larger than default byte boundaries (e.g. 16
|
|
|
|
|
bytes instead of 8 bytes on x86 type platforms) for optimal
|
|
|
|
|
performance.
|
|
|
|
|
</P>
|
2011-04-12 03:49:41 +08:00
|
|
|
<P>If you use -DLAMMPS_XDR, the build will include XDR compatibility
|
2009-10-30 01:54:40 +08:00
|
|
|
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>
|
2014-01-18 03:02:13 +08:00
|
|
|
<P>Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG, -D-
|
|
|
|
|
DLAMMPS_SMALLSMALL settings. The default is -DLAMMPS_SMALLBIG. These
|
|
|
|
|
settings refer to use of 4-byte (small) vs 8-byte (big) integers
|
2012-06-26 06:22:46 +08:00
|
|
|
within LAMMPS, as specified in src/lmptype.h. The only reason to use
|
|
|
|
|
the BIGBIG setting is to enable simulation of huge molecular systems
|
2014-01-18 03:02:13 +08:00
|
|
|
(which store bond topology info) with more than 2 billion atoms, or to
|
|
|
|
|
track the image flags of moving atoms that wrap around a periodic box
|
|
|
|
|
more than 512 times. The only reason to use the SMALLSMALL setting is
|
|
|
|
|
if your machine does not support 64-bit integers. See the <A HREF = "#start_2_4">Additional
|
|
|
|
|
build tips</A> section below for more details.
|
2011-08-19 04:48:51 +08:00
|
|
|
</P>
|
|
|
|
|
<P>The -DLAMMPS_LONGLONG_TO_LONG setting may be needed if your system or
|
|
|
|
|
MPI version does not recognize "long long" data types. In this case a
|
|
|
|
|
"long" data type is likely already 64-bits, in which case this setting
|
|
|
|
|
will convert to that data type.
|
|
|
|
|
</P>
|
|
|
|
|
<P>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. See the
|
|
|
|
|
<A HREF = "kspace_style.html">kspace_style</A> command for info about PPPM. See
|
|
|
|
|
Step 6 below for info about building LAMMPS with an FFT library.
|
2011-04-12 03:49:41 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P><B>Step 5</B>
|
|
|
|
|
</P>
|
|
|
|
|
<P>The 3 MPI variables are used to specify an MPI library to build LAMMPS
|
|
|
|
|
with.
|
2009-10-30 01:54:40 +08:00
|
|
|
</P>
|
|
|
|
|
<P>If you want LAMMPS to run in parallel, you must have an MPI library
|
2009-10-30 05:37:40 +08:00
|
|
|
installed on your platform. If you use an MPI-wrapped compiler, such
|
2011-08-19 01:31:58 +08:00
|
|
|
as "mpicc" to build LAMMPS, you should be able to leave these 3
|
|
|
|
|
variables blank; the MPI wrapper knows where to find the needed files.
|
|
|
|
|
If not, and MPI is installed on your system in the usual place (under
|
|
|
|
|
/usr/local), you also may not need to specify these 3 variables. On
|
|
|
|
|
some large parallel machines which use "modules" for their
|
|
|
|
|
compile/link environements, you may simply need to include the correct
|
|
|
|
|
module in your build environment. Or the parallel machine may have a
|
|
|
|
|
vendor-provided MPI which the compiler has no trouble finding.
|
|
|
|
|
</P>
|
|
|
|
|
<P>Failing this, with these 3 variables you can specify where the mpi.h
|
|
|
|
|
file (MPI_INC) and the MPI library file (MPI_PATH) are found and the
|
|
|
|
|
name of the library file (MPI_LIB).
|
2009-10-30 05:37:40 +08:00
|
|
|
</P>
|
2011-10-01 00:56:12 +08:00
|
|
|
<P>If you are installing MPI yourself, we recommend Argonne's MPICH2
|
|
|
|
|
or OpenMPI. MPICH can be downloaded from the <A HREF = "http://www.mcs.anl.gov/research/projects/mpich2/">Argonne MPI
|
|
|
|
|
site</A>. OpenMPI can
|
|
|
|
|
be downloaded from the <A HREF = "http://www.open-mpi.org">OpenMPI site</A>.
|
|
|
|
|
Other MPI packages 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 is likely to be faster
|
|
|
|
|
than a self-installed MPICH or OpenMPI, so find out how to build
|
|
|
|
|
and link with it. If you use MPICH or OpenMPI, you will have to
|
2011-04-12 03:49:41 +08:00
|
|
|
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.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>If you just want to run LAMMPS on a single processor, you can use the
|
|
|
|
|
dummy MPI library provided in src/STUBS, since you don't need a true
|
|
|
|
|
MPI library installed on your system. See the
|
|
|
|
|
src/MAKE/Makefile.serial file for how to specify the 3 MPI variables
|
|
|
|
|
in this case. You will also need to build the STUBS library for your
|
2012-08-15 00:13:24 +08:00
|
|
|
platform before making LAMMPS itself. To build from the src
|
|
|
|
|
directory, type "make stubs", or from the STUBS dir, type "make".
|
|
|
|
|
This should create a libmpi_stubs.a file suitable for linking to
|
|
|
|
|
LAMMPS. If the build fails, you will need to edit the STUBS/Makefile
|
|
|
|
|
for your platform.
|
2011-08-19 01:31:58 +08:00
|
|
|
</P>
|
2013-03-07 00:46:43 +08:00
|
|
|
<P>The file STUBS/mpi.c provides a CPU timer function called
|
2011-08-19 01:31:58 +08:00
|
|
|
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><B>Step 6</B>
|
|
|
|
|
</P>
|
|
|
|
|
<P>The 3 FFT variables allow you to specify an FFT library which LAMMPS
|
|
|
|
|
uses (for performing 1d FFTs) when running the particle-particle
|
|
|
|
|
particle-mesh (PPPM) option for long-range Coulombics via the
|
2009-10-30 01:54:40 +08:00
|
|
|
<A HREF = "kspace_style.html">kspace_style</A> command.
|
|
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>LAMMPS supports various open-source or vendor-supplied FFT libraries
|
|
|
|
|
for this purpose. If you leave these 3 variables blank, LAMMPS will
|
|
|
|
|
use the open-source <A HREF = "http://kissfft.sf.net">KISS FFT library</A>, which is
|
|
|
|
|
included in the LAMMPS distribution. This library is portable to all
|
|
|
|
|
platforms and for typical LAMMPS simulations is almost as fast as FFTW
|
|
|
|
|
or vendor optimized libraries. If you are not including the KSPACE
|
|
|
|
|
package in your build, you can also leave the 3 variables blank.
|
|
|
|
|
</P>
|
|
|
|
|
<P>Otherwise, select which kinds of FFTs to use as part of the FFT_INC
|
|
|
|
|
setting by a switch of the form -DFFT_XXX. Recommended values for XXX
|
|
|
|
|
are: MKL, SCSL, FFTW2, and FFTW3. Legacy options are: INTEL, SGI,
|
|
|
|
|
ACML, and T3E. For backward compatability, using -DFFT_FFTW will use
|
|
|
|
|
the FFTW2 library. Using -DFFT_NONE will use the KISS library
|
|
|
|
|
described above.
|
|
|
|
|
</P>
|
|
|
|
|
<P>You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
|
|
|
|
|
so the compiler and linker can find the needed FFT header and library
|
|
|
|
|
files. Note that on some large parallel machines which use "modules"
|
|
|
|
|
for their compile/link environements, you may simply need to include
|
|
|
|
|
the correct module in your build environment. Or the parallel machine
|
|
|
|
|
may have a vendor-provided FFT library which the compiler has no
|
|
|
|
|
trouble finding.
|
2011-08-09 01:51:46 +08:00
|
|
|
</P>
|
|
|
|
|
<P>FFTW is a fast, portable library that should also work on any
|
|
|
|
|
platform. You can download it from
|
2011-08-19 01:31:58 +08:00
|
|
|
<A HREF = "http://www.fftw.org">www.fftw.org</A>. Both the legacy version 2.1.X and
|
|
|
|
|
the newer 3.X versions are supported as -DFFT_FFTW2 or -DFFT_FFTW3.
|
|
|
|
|
Building FFTW for your box should be as simple as ./configure; make.
|
|
|
|
|
Note that on some platforms FFTW2 has been pre-installed, and uses
|
|
|
|
|
renamed files indicating the precision it was compiled with,
|
|
|
|
|
e.g. sfftw.h, or dfftw.h instead of fftw.h. In this case, you can
|
2012-01-11 06:39:38 +08:00
|
|
|
specify an additional define variable for FFT_INC called -DFFTW_SIZE,
|
2011-08-19 01:31:58 +08:00
|
|
|
which will select the correct include file. In this case, for FFT_LIB
|
|
|
|
|
you must also manually specify the correct library, namely -lsfftw or
|
|
|
|
|
-ldfftw.
|
|
|
|
|
</P>
|
|
|
|
|
<P>The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
|
|
|
|
|
use single-precision FFTs with PPPM, which can speed-up long-range
|
|
|
|
|
calulations, particularly in parallel or on GPUs. Fourier transform
|
|
|
|
|
and related PPPM operations are somewhat insensitive to floating point
|
|
|
|
|
truncation errors and thus do not always need to be performed in
|
|
|
|
|
double precision. Using the -DFFT_SINGLE setting trades off a little
|
|
|
|
|
accuracy for reduced memory use and parallel communication costs for
|
|
|
|
|
transposing 3d FFT data. Note that single precision FFTs have only
|
2011-08-26 02:01:18 +08:00
|
|
|
been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.
|
2011-08-19 01:31:58 +08:00
|
|
|
</P>
|
|
|
|
|
<P><B>Step 7</B>
|
|
|
|
|
</P>
|
2013-10-30 23:10:46 +08:00
|
|
|
<P>The 3 JPG variables allow you to specify a JPEG and/or PNG library
|
|
|
|
|
which LAMMPS uses when writing out JPEG or PNG files via the <A HREF = "dump_image.html">dump
|
|
|
|
|
image</A> command. These can be left blank if you do not
|
|
|
|
|
use the -DLAMMPS_JPEG or -DLAMMPS_PNG switches discussed above in Step
|
|
|
|
|
4, since in that case JPEG/PNG output will be disabled.
|
2011-04-12 03:49:41 +08:00
|
|
|
</P>
|
2013-10-30 23:10:46 +08:00
|
|
|
<P>A standard JPEG library usually goes by the name libjpeg.a or
|
|
|
|
|
libjpeg.so and has an associated header file jpeglib.h. Whichever
|
|
|
|
|
JPEG library you have on your platform, you'll need to set the
|
|
|
|
|
appropriate JPG_INC, JPG_PATH, and JPG_LIB variables, so that the
|
|
|
|
|
compiler and linker can find it.
|
|
|
|
|
</P>
|
|
|
|
|
<P>A standard PNG library usually goes by the name libpng.a or libpng.so
|
|
|
|
|
and has an associated header file png.h. Whichever PNG library you
|
|
|
|
|
have on your platform, you'll need to set the appropriate JPG_INC,
|
|
|
|
|
JPG_PATH, and JPG_LIB variables, so that the compiler and linker can
|
|
|
|
|
find it.
|
2011-08-19 01:31:58 +08:00
|
|
|
</P>
|
|
|
|
|
<P>As before, if these header and library files are in the usual place on
|
|
|
|
|
your machine, you may not need to set these variables.
|
|
|
|
|
</P>
|
|
|
|
|
<P><B>Step 8</B>
|
|
|
|
|
</P>
|
2012-03-01 23:12:16 +08:00
|
|
|
<P>Note that by default only a few of LAMMPS optional packages are
|
2011-08-26 00:46:23 +08:00
|
|
|
installed. To build LAMMPS with optional packages, see <A HREF = "#start_3">this
|
2011-08-19 01:31:58 +08:00
|
|
|
section</A> below, before proceeding to Step 9.
|
|
|
|
|
</P>
|
|
|
|
|
<P><B>Step 9</B>
|
|
|
|
|
</P>
|
|
|
|
|
<P>That's it. Once you have a correct Makefile.foo, you have installed
|
|
|
|
|
the optional LAMMPS packages you want to include in your build, and
|
|
|
|
|
you have pre-built any other needed libraries (e.g. MPI, FFT, package
|
|
|
|
|
libraries), all you need to do from the src directory is type
|
|
|
|
|
something like this:
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
|
|
|
|
<PRE>make foo
|
2011-08-19 01:31:58 +08:00
|
|
|
or
|
2006-09-22 00:22:34 +08:00
|
|
|
gmake foo
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>You should get the executable lmp_foo when the build is complete.
|
|
|
|
|
</P>
|
2009-09-25 01:42:17 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<A NAME = "start_2_3"></A><B><I>Errors that can occur when making LAMMPS:</I></B>
|
2011-08-19 01:31:58 +08:00
|
|
|
|
|
|
|
|
<P>IMPORTANT NOTE: If an error occurs when building LAMMPS, the compiler
|
|
|
|
|
or linker will state very explicitly what the problem is. The error
|
|
|
|
|
message should give you a hint as to which of the steps above has
|
|
|
|
|
failed, and what you need to do in order to fix it. Building a code
|
|
|
|
|
with a Makefile is a very logical process. The compiler and linker
|
|
|
|
|
need to find the appropriate files and those files need to be
|
|
|
|
|
compatible with LAMMPS source files. When a make fails, there is
|
|
|
|
|
usually a very simple reason, which you or a local expert will need to
|
|
|
|
|
fix.
|
|
|
|
|
</P>
|
|
|
|
|
<P>Here are two non-obvious errors that can occur:
|
|
|
|
|
</P>
|
|
|
|
|
<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 native 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 a pre-generated
|
|
|
|
|
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. Note that you should
|
|
|
|
|
include/exclude any desired optional packages before using the "make
|
|
|
|
|
makelist" command.
|
|
|
|
|
</P>
|
|
|
|
|
<P>(2) If you get an error that says something like 'identifier "atoll"
|
|
|
|
|
is undefined', then your machine does not support "long long"
|
2011-08-19 04:48:51 +08:00
|
|
|
integers. Try using the -DLAMMPS_LONGLONG_TO_LONG setting described
|
|
|
|
|
above in Step 4.
|
2011-08-19 01:31:58 +08:00
|
|
|
</P>
|
|
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<A NAME = "start_2_4"></A><B><I>Additional build tips:</I></B>
|
2009-09-25 01:42:17 +08:00
|
|
|
|
2007-02-10 05:37:30 +08:00
|
|
|
<P>(1) Building LAMMPS for multiple platforms.
|
|
|
|
|
</P>
|
|
|
|
|
<P>You can make LAMMPS for multiple platforms from the same src
|
2008-03-19 05:09:15 +08:00
|
|
|
directory. Each target creates its own object sub-directory called
|
2012-01-28 07:39:14 +08:00
|
|
|
Obj_target where it stores the system-specific *.o files.
|
2007-02-10 05:37:30 +08:00
|
|
|
</P>
|
|
|
|
|
<P>(2) Cleaning up.
|
|
|
|
|
</P>
|
2013-05-31 05:03:27 +08:00
|
|
|
<P>Typing "make clean-all" or "make clean-machine" will delete *.o object
|
2009-10-30 01:54:40 +08:00
|
|
|
files created when LAMMPS is built, for either all builds or for a
|
|
|
|
|
particular machine.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2012-06-26 06:22:46 +08:00
|
|
|
<P>(3) Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
|
2014-01-18 05:51:23 +08:00
|
|
|
-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
|
2012-06-26 06:22:46 +08:00
|
|
|
</P>
|
|
|
|
|
<P>As explained above, any of these 3 settings can be specified on the
|
|
|
|
|
LMP_INC line in your low-level src/MAKE/Makefile.foo.
|
|
|
|
|
</P>
|
|
|
|
|
<P>The default is -DLAMMPS_SMALLBIG which allows for systems with up to
|
2014-01-18 03:02:13 +08:00
|
|
|
2^63 atoms and 2^63 timesteps (about 9e18). The atom limit is for
|
|
|
|
|
atomic systems which do not store bond topology info and thus do not
|
|
|
|
|
require atom IDs. If you use atom IDs for atomic systems (which is
|
|
|
|
|
the default) or if you use a molecular model, which stores bond
|
|
|
|
|
topology info and thus requires atom IDs, the limit is 2^31 atoms
|
|
|
|
|
(about 2 billion). This is because the IDs are stored in 32-bit
|
|
|
|
|
integers.
|
|
|
|
|
</P>
|
|
|
|
|
<P>Likewise, with this setting, the 3 image flags for each atom (see the
|
|
|
|
|
<A HREF = "dump.html">dump</A> doc page for a discussion) are stored in a 32-bit
|
|
|
|
|
integer, which means the atoms can only wrap around a periodic box (in
|
|
|
|
|
each dimension) at most 512 times. If atoms move through the periodic
|
|
|
|
|
box more than this many times, the image flags will "roll over",
|
|
|
|
|
e.g. from 511 to -512, which can cause diagnostics like the
|
|
|
|
|
mean-squared displacement, as calculated by the <A HREF = "compute_msd.html">compute
|
|
|
|
|
msd</A> command, to be faulty.
|
|
|
|
|
</P>
|
|
|
|
|
<P>To allow for larger atomic systems with atom IDs or larger molecular
|
|
|
|
|
systems or larger image flags, compile with -DLAMMPS_BIGBIG. This
|
|
|
|
|
stores atom IDs and image flags in 64-bit integers. This enables
|
|
|
|
|
atomic or molecular systems with atom IDS of up to 2^63 atoms (about
|
|
|
|
|
9e18). And image flags will not "roll over" until they reach 2^20 =
|
|
|
|
|
1048576.
|
2012-06-26 06:22:46 +08:00
|
|
|
</P>
|
|
|
|
|
<P>If your system does not support 8-byte integers, you will need to
|
2014-01-18 03:02:13 +08:00
|
|
|
compile with the -DLAMMPS_SMALLSMALL setting. This will restrict the
|
|
|
|
|
total number of atoms (for atomic or molecular systems) and timesteps
|
2012-06-26 06:22:46 +08:00
|
|
|
to 2^31 (about 2 billion). Image flags will roll over at 2^9 = 512.
|
2011-07-18 23:22:14 +08:00
|
|
|
</P>
|
2014-01-18 03:02:13 +08:00
|
|
|
<P>Note that in src/lmptype.h there are definitions of all these data
|
|
|
|
|
types as well as the MPI data types associated with them. The MPI
|
|
|
|
|
types need to be consistent with the associated C data types, or else
|
|
|
|
|
LAMMPS will generate a run-time error. As far as we know, the
|
|
|
|
|
settings defined in src/lmptype.h are portable and work on every
|
|
|
|
|
current system.
|
|
|
|
|
</P>
|
|
|
|
|
<P>In all cases, the size of problem that can be run on a per-processor
|
|
|
|
|
basis is limited by 4-byte integer storage to 2^31 atoms per processor
|
|
|
|
|
(about 2 billion). This should not normally be a limitation since such
|
|
|
|
|
a problem would have a huge per-processor memory footprint due to
|
|
|
|
|
neighbor lists and would run very slowly in terms of CPU secs/timestep.
|
2011-07-18 23:22:14 +08:00
|
|
|
</P>
|
2011-06-14 08:27:21 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<A NAME = "start_2_5"></A><B><I>Building for a Mac:</I></B>
|
2011-06-14 08:27:21 +08:00
|
|
|
|
2012-01-28 07:39:14 +08:00
|
|
|
<P>OS X is BSD Unix, so it should just work. See the
|
|
|
|
|
src/MAKE/Makefile.mac file.
|
2007-02-10 05:37:30 +08:00
|
|
|
</P>
|
2011-06-14 08:27:21 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<A NAME = "start_2_6"></A><B><I>Building for Windows:</I></B>
|
2011-06-14 08:27:21 +08:00
|
|
|
|
2011-06-14 08:14:59 +08:00
|
|
|
<P>The LAMMPS download page has an option to download both a serial and
|
2014-05-22 22:20:18 +08:00
|
|
|
parallel pre-built Windows executable. See the <A HREF = "#start_6">Running
|
|
|
|
|
LAMMPS</A> section for instructions on running these executables
|
|
|
|
|
on a Windows box.
|
|
|
|
|
</P>
|
|
|
|
|
<P>The pre-built executables hosted on the <A HREF = "http://lammps.sandia.gov/download.html">LAMMPS download
|
|
|
|
|
page</A> are built with a subset
|
|
|
|
|
of the available packages; see the download page for the list. These
|
|
|
|
|
are single executable files. No examples or documentation in
|
|
|
|
|
included. You will need to download the full source code package to
|
|
|
|
|
obtain those.
|
|
|
|
|
</P>
|
|
|
|
|
<P>As an alternative, you can download "daily builds" (and some older
|
|
|
|
|
versions) of the installer packages from
|
|
|
|
|
<A HREF = "http://rpm.lammps.org/windows.html">rpm.lammps.org/windows.html</A>.
|
|
|
|
|
These executables are built with most optional packages and the
|
|
|
|
|
download includes documentation, some tools and most examples.
|
|
|
|
|
</P>
|
|
|
|
|
<P>If you want a Windows version with specific packages included and
|
|
|
|
|
excluded, you can build it yourself.
|
2012-05-31 22:16:01 +08:00
|
|
|
</P>
|
|
|
|
|
<P>One way to do this is install and use cygwin to build LAMMPS with a
|
2014-05-22 22:20:18 +08:00
|
|
|
standard unix style make program, just as you would on a Linux box;
|
|
|
|
|
see src/MAKE/Makefile.cygwin.
|
2011-06-14 08:14:59 +08:00
|
|
|
</P>
|
2012-05-31 22:16:01 +08:00
|
|
|
<P>The other way to do this is using Visual Studio and project files.
|
|
|
|
|
See the src/WINDOWS directory and its README.txt file for instructions
|
|
|
|
|
on both a basic build and a customized build with pacakges you select.
|
2007-02-10 05:37:30 +08:00
|
|
|
</P>
|
2007-10-03 05:55:02 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<H4><A NAME = "start_3"></A>2.3 Making LAMMPS with optional packages
|
2007-02-10 05:37:30 +08:00
|
|
|
</H4>
|
2009-09-25 01:42:17 +08:00
|
|
|
<P>This section has the following sub-sections:
|
|
|
|
|
</P>
|
2011-08-26 00:46:23 +08:00
|
|
|
<UL><LI><A HREF = "#start_3_1">Package basics</A>
|
|
|
|
|
<LI><A HREF = "#start_3_2">Including/excluding packages</A>
|
2011-08-26 02:01:18 +08:00
|
|
|
<LI><A HREF = "#start_3_3">Packages that require extra libraries</A>
|
2014-05-30 06:52:23 +08:00
|
|
|
<LI><A HREF = "#start_3_4">Packages that use make variable settings</A>
|
2009-09-25 01:42:17 +08:00
|
|
|
</UL>
|
|
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<A NAME = "start_3_1"></A><B><I>Package basics:</I></B>
|
2009-09-25 01:42:17 +08:00
|
|
|
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>The source code for LAMMPS is structured as a 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
|
2011-08-26 02:01:43 +08:00
|
|
|
can see the list of all packages by typing "make package" from within
|
|
|
|
|
the src directory of the LAMMPS distribution.
|
2007-10-03 05:55:02 +08:00
|
|
|
</P>
|
2011-08-26 02:01:18 +08:00
|
|
|
<P>If you use a command in a LAMMPS input script that is specific to a
|
|
|
|
|
particular package, you must have built LAMMPS with that package, else
|
|
|
|
|
you will get an error that the style is invalid or the command is
|
|
|
|
|
unknown. Every command's doc page specfies if it is part of a
|
|
|
|
|
package. You can also type
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-08-26 02:01:18 +08:00
|
|
|
<PRE>lmp_machine -h
|
|
|
|
|
</PRE>
|
2012-01-28 07:39:14 +08:00
|
|
|
<P>to run your executable with the optional <A HREF = "#start_7">-h command-line
|
2011-08-26 02:01:18 +08:00
|
|
|
switch</A> for "help", which will list the styles and commands
|
|
|
|
|
known to your executable.
|
2009-09-25 01:42:17 +08:00
|
|
|
</P>
|
2011-08-26 02:01:18 +08:00
|
|
|
<P>There are two kinds of packages in LAMMPS, standard and user packages.
|
|
|
|
|
More information about the contents of standard and user packages is
|
2011-12-14 04:35:35 +08:00
|
|
|
given in <A HREF = "Section_packages.html">Section_packages</A> of the manual. The
|
2011-08-26 02:01:18 +08:00
|
|
|
difference between standard and user packages is as follows:
|
2007-10-03 05:55:02 +08:00
|
|
|
</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>
|
2011-08-26 02:01:18 +08:00
|
|
|
<P>User packages have been contributed by users, and always begin with
|
|
|
|
|
the user prefix. If they are a single command (single file), they are
|
|
|
|
|
typically in the user-misc package. Otherwise, they are a a set of
|
|
|
|
|
files grouped together which add a specific functionality to the code.
|
|
|
|
|
</P>
|
|
|
|
|
<P>User packages don't necessarily meet the requirements of the standard
|
|
|
|
|
packages. If you have problems using a feature provided in a user
|
|
|
|
|
package, you will likely need to contact the contributor directly to
|
|
|
|
|
get help. Information on how to submit additions you make to LAMMPS
|
2013-02-01 02:27:42 +08:00
|
|
|
as a user-contributed package is given in <A HREF = "Section_modify.html#mod_15">this
|
2011-08-26 02:01:18 +08:00
|
|
|
section</A> of the documentation.
|
2007-10-03 05:55:02 +08:00
|
|
|
</P>
|
2013-05-31 05:03:27 +08:00
|
|
|
<P>Some packages (both standard and user) require additional libraries.
|
|
|
|
|
See more details below.
|
|
|
|
|
</P>
|
2007-10-03 05:55:02 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 00:46:23 +08:00
|
|
|
<A NAME = "start_3_2"></A><B><I>Including/excluding packages:</I></B>
|
2009-09-25 01:42:17 +08:00
|
|
|
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>To use or not use a package you must include or exclude it before
|
|
|
|
|
building LAMMPS. From the src directory, this is typically as simple
|
|
|
|
|
as:
|
2009-08-13 00:45:55 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<PRE>make yes-colloid
|
|
|
|
|
make g++
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>or
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>make no-manybody
|
|
|
|
|
make g++
|
|
|
|
|
</PRE>
|
2013-09-10 00:12:56 +08:00
|
|
|
<P>IMPORTANT NOTE: You should NOT include/exclude packages and build
|
|
|
|
|
LAMMPS in a single make command by using multiple targets, e.g. make
|
|
|
|
|
yes-colloid g++. 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 during the same command.
|
|
|
|
|
</P>
|
2011-05-27 07:45:23 +08:00
|
|
|
<P>Some packages have individual files that depend on other packages
|
2011-08-19 01:31:58 +08:00
|
|
|
being included. LAMMPS checks for this and does the right thing.
|
2011-05-27 07:45:23 +08:00
|
|
|
I.e. individual files are only included if their dependencies are
|
|
|
|
|
already included. Likewise, if a package is excluded, other files
|
|
|
|
|
dependent on that package are also excluded.
|
2009-08-13 00:45:55 +08:00
|
|
|
</P>
|
2011-05-27 07:45:23 +08:00
|
|
|
<P>The reason to exclude packages is if you will never run certain kinds
|
2011-08-19 01:31:58 +08:00
|
|
|
of simulations. For some packages, this will keep you from having to
|
|
|
|
|
build auxiliary libraries (see below), and will also produce a smaller
|
|
|
|
|
executable which may run a bit faster.
|
2007-02-10 05:37:30 +08:00
|
|
|
</P>
|
2011-08-27 02:53:00 +08:00
|
|
|
<P>When you download a LAMMPS tarball, these packages are pre-installed
|
|
|
|
|
in the src directory: KSPACE, MANYBODY,MOLECULE. When you download
|
|
|
|
|
LAMMPS source files from the SVN or Git repositories, no packages are
|
|
|
|
|
pre-installed.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
|
|
|
|
<P>Packages are included or excluded by typing "make yes-name" or "make
|
2011-08-27 02:53:00 +08:00
|
|
|
no-name", where "name" is the name of the package in lower-case, e.g.
|
|
|
|
|
name = kspace for the KSPACE package or name = user-atc for the
|
|
|
|
|
USER-ATC package. You can also type "make yes-standard", "make
|
|
|
|
|
no-standard", "make yes-user", "make no-user", "make yes-all" or "make
|
|
|
|
|
no-all" to include/exclude various sets of packages. Type "make
|
|
|
|
|
package" to see the all of the package-related make options.
|
2009-08-07 23:22:13 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>IMPORTANT NOTE: Inclusion/exclusion of a package works by simply
|
|
|
|
|
moving files back and forth between the main src directory and
|
|
|
|
|
sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
|
|
|
|
|
so that the files are seen or not seen when LAMMPS is built. After
|
|
|
|
|
you have included or excluded a package, you must re-build LAMMPS.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>Additional package-related make options exist to help manage LAMMPS
|
|
|
|
|
files that exist in both the src directory and in package
|
|
|
|
|
sub-directories. You do not normally need to use these commands
|
|
|
|
|
unless you are editing LAMMPS files or have downloaded a patch from
|
|
|
|
|
the LAMMPS WWW site.
|
2009-09-25 01:42:17 +08:00
|
|
|
</P>
|
|
|
|
|
<P>Typing "make package-update" will overwrite src files with files from
|
2011-08-19 01:31:58 +08:00
|
|
|
the package sub-directories if the package has been included. It
|
|
|
|
|
should be used after a patch is installed, since patches only update
|
|
|
|
|
the files in the package sub-directory, but not the src files. Typing
|
|
|
|
|
"make package-overwrite" will overwrite files in the package
|
|
|
|
|
sub-directories with src files.
|
2011-06-16 01:48:36 +08:00
|
|
|
</P>
|
|
|
|
|
<P>Typing "make package-status" will show which packages are currently
|
2011-08-19 01:31:58 +08:00
|
|
|
included. Of those that are included, it will list files that are
|
|
|
|
|
different in the src directory and package sub-directory. Typing
|
|
|
|
|
"make package-diff" lists all differences between these files. Again,
|
|
|
|
|
type "make package" to see all of the package-related make options.
|
2009-09-25 01:42:17 +08:00
|
|
|
</P>
|
|
|
|
|
<HR>
|
|
|
|
|
|
2011-08-26 02:01:18 +08:00
|
|
|
<A NAME = "start_3_3"></A><B><I>Packages that require extra libraries:</I></B>
|
2009-09-25 01:42:17 +08:00
|
|
|
|
2011-08-19 01:31:58 +08:00
|
|
|
<P>A few of the standard and user packages require additional auxiliary
|
2013-05-31 05:03:27 +08:00
|
|
|
libraries. They must be compiled first, before LAMMPS is built. If
|
|
|
|
|
you get a LAMMPS build error about a missing library, this is likely
|
|
|
|
|
the reason. See the <A HREF = "Section_packages.html">Section_packages</A> doc page
|
|
|
|
|
for a list of packages that have auxiliary libraries.
|
|
|
|
|
</P>
|
|
|
|
|
<P>Code for some of these auxiliary libraries is included in the LAMMPS
|
|
|
|
|
distribution under the lib directory. Examples are the USER-ATC and
|
2014-05-30 06:52:23 +08:00
|
|
|
MEAM packages. Some auxiliary libraries are NOT included with LAMMPS;
|
2013-05-31 05:03:27 +08:00
|
|
|
to use the associated package you must download and install the
|
|
|
|
|
auxiliary library yourself. Examples are the KIM and VORONOI and
|
|
|
|
|
USER-MOLFILE packages.
|
|
|
|
|
</P>
|
|
|
|
|
<P>For libraries with provided source code, each lib directory has a
|
|
|
|
|
README file (e.g. lib/reax/README) with instructions on how to build
|
|
|
|
|
that library. Typically this is done by typing something like:
|
2009-02-11 02:37:23 +08:00
|
|
|
</P>
|
2011-08-19 01:31:58 +08:00
|
|
|
<PRE>make -f Makefile.g++
|
2009-08-07 23:22:13 +08:00
|
|
|
</PRE>
|
2014-05-30 06:52:23 +08:00
|
|
|
<P>If one of the provided Makefiles is not appropriate for your system
|
|
|
|
|
you will need to edit or add one. Note that all the Makefiles have a
|
|
|
|
|
setting for EXTRAMAKE at the top that specifies a Makefile.lammps.*
|
|
|
|
|
file.
|
2013-05-31 05:03:27 +08:00
|
|
|
</P>
|
2014-05-30 06:52:23 +08:00
|
|
|
<P>If the library build is successful, it will produce 2 files in the lib
|
|
|
|
|
directory:
|
2013-05-31 05:03:27 +08:00
|
|
|
</P>
|
|
|
|
|
<PRE>libpackage.a
|
|
|
|
|
Makefile.lammps
|
|
|
|
|
</PRE>
|
2014-05-30 06:52:23 +08:00
|
|
|
<P>The Makefile.lammps file will be a copy of the EXTRAMAKE file setting
|
|
|
|
|
specified in the library Makefile.* you used.
|
|
|
|
|
</P>
|
|
|
|
|
<P>Note that you must insure that the settings in Makefile.lammps are
|
|
|
|
|
appropriate for your system. If they are not, the LAMMPS build will
|
|
|
|
|
fail.
|
|
|
|
|
</P>
|
|
|
|
|
<P>As explained in the lib/package/README files, the settings in
|
|
|
|
|
Makefile.lammps are used to specify additional system libraries and
|
|
|
|
|
their locations so that LAMMPS can build with the auxiliary library.
|
|
|
|
|
For example, if the MEAM or REAX packages are used, the auxiliary
|
|
|
|
|
libraries consist of F90 code, built with a Fortran complier. To link
|
|
|
|
|
that library with LAMMPS (a C++ code) via whatever C++ compiler LAMMPS
|
|
|
|
|
is built with, typically requires additional Fortran-to-C libraries be
|
|
|
|
|
included in the link. Another example are the BLAS and LAPACK
|
|
|
|
|
libraries needed to use the USER-ATC or USER-AWPMD packages.
|
2013-05-31 05:03:27 +08:00
|
|
|
</P>
|
|
|
|
|
<P>For libraries without provided source code, see the
|
|
|
|
|
src/package/Makefile.lammps file for information on where to find the
|
2014-01-10 00:32:42 +08:00
|
|
|
library and how to build it. E.g. the file src/KIM/Makefile.lammps or
|
|
|
|
|
src/VORONOI/Makefile.lammps or src/UESR-MOLFILE/Makefile.lammps.
|
|
|
|
|
These files serve the same purpose as the lib/package/Makefile.lammps
|
|
|
|
|
files described above. The files have settings needed when LAMMPS is
|
2014-05-30 06:52:23 +08:00
|
|
|
built to link with the corresponding auxiliary library.
|
|
|
|
|
</P>
|
|
|
|
|
<P>Again, you must insure that the settings in
|
|
|
|
|
src/package/Makefile.lammps are appropriate for your system and where
|
|
|
|
|
you installed the auxiliary library. If they are not, the LAMMPS
|
|
|
|
|
build will fail.
|
|
|
|
|
</P>
|
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
|
|
<A NAME = "start_3_4"></A><B><I>Packages that use make variable settings</I></B>
|
|
|
|
|
|
|
|
|
|
<P>One package, the KOKKOS package, allows its build options to be
|
|
|
|
|
specified by setting variables via the "make" command, rather than by
|
|
|
|
|
first building an auxiliary library and editing a Makefile.lammps
|
|
|
|
|
file, as discussed in the previous sub-section for other packages.
|
|
|
|
|
This is for convenience since it is common to want to experiment with
|
|
|
|
|
different Kokkos library options. Using variables enables a direct
|
|
|
|
|
re-build of LAMMPS and its Kokkos dependencies, so that a benchmark
|
|
|
|
|
test with different Kokkos options can be quickly performed.
|
|
|
|
|
</P>
|
|
|
|
|
<P>The syntax for setting make variables is as follows. You must
|
|
|
|
|
use a GNU-compatible make command for this to work. Try "gmake"
|
|
|
|
|
if your system's standard make complains.
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>make yes-kokkos
|
|
|
|
|
make g++ VAR1=value VAR2=value ...
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>The first line installs the KOKKOS package, which only needs to be
|
|
|
|
|
done once. The second line builds LAMMPS with src/MAKE/Makefile.g++
|
|
|
|
|
and optionally sets one or more variables that affect the build. Each
|
|
|
|
|
variable is specified in upper-case; its value follows an equal sign
|
|
|
|
|
with no spaces. The second line can be repeated with different
|
|
|
|
|
variable settings, though a "clean" must be done before the rebuild.
|
|
|
|
|
Type "make clean" to see options for this operation.
|
|
|
|
|
</P>
|
|
|
|
|
<P>These are the variables that can be specified. Each takes a value of
|
|
|
|
|
<I>yes</I> or <I>no</I>. The default value is listed, which is set in the
|
|
|
|
|
lib/kokkos/Makefile.lammps file. See <A HREF = "Section_accelerate.html#acc_8">this
|
|
|
|
|
section</A> for a discussion of what is
|
|
|
|
|
meant by "host" and "device" in the Kokkos context.
|
|
|
|
|
</P>
|
|
|
|
|
<UL><LI>OMP, default = <I>yes</I>
|
|
|
|
|
<LI>CUDA, default = <I>no</I>
|
|
|
|
|
<LI>HWLOC, default = <I>no</I>
|
|
|
|
|
<LI>AVX, default = <I>no</I>
|
|
|
|
|
<LI>MIC, default = <I>no</I>
|
|
|
|
|
<LI>LIBRT, default = <I>no</I>
|
|
|
|
|
<LI>DEBUG, default = <I>no</I>
|
|
|
|
|
</UL>
|
|
|
|
|
<P>OMP sets the parallelization method used for Kokkos code (within
|
|
|
|
|
LAMMPS) that runs on the host. OMP=yes means that OpenMP will be
|
|
|
|
|
used. OMP=no means that pthreads will be used.
|
|
|
|
|
</P>
|
|
|
|
|
<P>CUDA sets the parallelization method used for Kokkos code (within
|
|
|
|
|
LAMMPS) that runs on the device. CUDA=yes means an NVIDIA GPU running
|
|
|
|
|
CUDA will be used. CUDA=no means that the OMP=yes or OMP=no setting
|
|
|
|
|
will be used for the device as well as the host.
|
|
|
|
|
</P>
|
|
|
|
|
<P>If CUDA=yes, then the lo-level Makefile in the src/MAKE directory must
|
|
|
|
|
use "nvcc" as its compiler, via its CC setting. For best performance
|
|
|
|
|
its CCFLAGS setting should use -O3 and have an -arch setting that
|
|
|
|
|
matches the compute capability of your NVIDIA hardware and software
|
|
|
|
|
installation, e.g. -arch=sm_20. Generally Fermi Generation GPUs are
|
|
|
|
|
sm_20, while Kepler generation GPUs are sm_30 or sm_35 and Maxwell
|
|
|
|
|
cards are sm_50. A complete list can be found on
|
|
|
|
|
<A HREF = "http://en.wikipedia.org/wiki/CUDA#Supported_GPUs">wikipedia</A>. You can
|
|
|
|
|
also use the deviceQuery tool that comes with the CUDA samples. Note
|
|
|
|
|
the minimal required compute capability is 2.0, but this will give
|
|
|
|
|
signicantly reduced performance compared to Kepler generation GPUs
|
|
|
|
|
with compute capability 3.x. For the LINK setting, "nvcc" should not
|
|
|
|
|
be used; instead use g++ or another compiler suitable for linking C++
|
|
|
|
|
applications. Often you will want to use your MPI compiler wrapper
|
|
|
|
|
for this setting (i.e. mpicxx). Finally, the lo-level Makefile must
|
|
|
|
|
also have a "Compilation rule" for creating *.o files from *.cu files.
|
|
|
|
|
See src/Makefile.cuda for an example of a lo-level Makefile with all
|
|
|
|
|
of these settings.
|
|
|
|
|
</P>
|
|
|
|
|
<P>HWLOC binds threads to hardware cores, so they do not migrate during a
|
|
|
|
|
simulation. HWLOC=yes should always be used if running with OMP=no
|
|
|
|
|
for pthreads. It is not necessary for OMP=yes for OpenMP, because
|
|
|
|
|
OpenMP provides alternative methods via environment variables for
|
|
|
|
|
binding threads to hardware cores. More info on binding threads to
|
|
|
|
|
cores is given in <A HREF = "Section_accelerate.html#acc_8">this section</A>.
|
|
|
|
|
</P>
|
|
|
|
|
<P>AVX enables Intel advanced vector extensions when compiling for an
|
|
|
|
|
Intel-compatible chip. AVX=yes should only be set if your host
|
|
|
|
|
hardware supports AVX. If it does not support it, this will cause a
|
|
|
|
|
run-time crash.
|
|
|
|
|
</P>
|
|
|
|
|
<P>MIC enables compiler switches needed when compling for an Intel Phi
|
|
|
|
|
processor.
|
|
|
|
|
</P>
|
|
|
|
|
<P>LIBRT enables use of a more accurate timer mechanism on most Unix
|
|
|
|
|
platforms. This library is not available on all platforms.
|
|
|
|
|
</P>
|
|
|
|
|
<P>DEBUG is only useful when developing a Kokkos-enabled style within
|
|
|
|
|
LAMMPS. DEBUG=yes enables printing of run-time debugging information
|
|
|
|
|
that can be useful. It also enables runtime bounds checking on Kokkos
|
|
|
|
|
data structures.
|
2007-04-20 07:25:27 +08:00
|
|
|
</P>
|
2007-10-03 05:55:02 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2012-01-28 07:39:14 +08:00
|
|
|
<H4><A NAME = "start_4"></A>2.4 Building LAMMPS via the Make.py script
|
|
|
|
|
</H4>
|
|
|
|
|
<P>The src directory includes a Make.py script, written
|
|
|
|
|
in Python, which can be used to automate various steps
|
|
|
|
|
of the build process.
|
|
|
|
|
</P>
|
|
|
|
|
<P>You can run the script from the src directory by typing either:
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>Make.py
|
|
|
|
|
python Make.py
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>which will give you info about the tool. For the former to work, you
|
|
|
|
|
may need to edit the 1st line of the script to point to your local
|
|
|
|
|
Python. And you may need to insure the script is executable:
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>chmod +x Make.py
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>The following options are supported as switches:
|
|
|
|
|
</P>
|
|
|
|
|
<UL><LI>-i file1 file2 ...
|
|
|
|
|
<LI>-p package1 package2 ...
|
|
|
|
|
<LI>-u package1 package2 ...
|
|
|
|
|
<LI>-e package1 arg1 arg2 package2 ...
|
|
|
|
|
<LI>-o dir
|
|
|
|
|
<LI>-b machine
|
|
|
|
|
<LI>-s suffix1 suffix2 ...
|
|
|
|
|
<LI>-l dir
|
|
|
|
|
<LI>-j N
|
|
|
|
|
<LI>-h switch1 switch2 ...
|
|
|
|
|
</UL>
|
|
|
|
|
<P>Help on any switch can be listed by using -h, e.g.
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>Make.py -h -i -p
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>At a hi-level, these are the kinds of package management
|
|
|
|
|
and build tasks that can be performed easily, using
|
|
|
|
|
the Make.py tool:
|
|
|
|
|
</P>
|
|
|
|
|
<UL><LI>install/uninstall packages and build the associated external libs (use -p and -u and -e)
|
|
|
|
|
<LI>install packages needed for one or more input scripts (use -i and -p)
|
|
|
|
|
<LI>build LAMMPS, either in the src dir or new dir (use -b)
|
|
|
|
|
<LI>create a new dir with only the source code needed for one or more input scripts (use -i and -o)
|
|
|
|
|
</UL>
|
|
|
|
|
<P>The last bullet can be useful when you wish to build a stripped-down
|
|
|
|
|
version of LAMMPS to run a specific script(s). Or when you wish to
|
|
|
|
|
move the minimal amount of files to another platform for a remote
|
|
|
|
|
LAMMPS build.
|
|
|
|
|
</P>
|
|
|
|
|
<P>Note that using Make.py is not a substitute for insuring you have a
|
|
|
|
|
valid src/MAKE/Makefile.foo for your system, or that external library
|
|
|
|
|
Makefiles in any lib/* directories you use are also valid for your
|
|
|
|
|
system. But once you have done that, you can use Make.py to quickly
|
|
|
|
|
include/exclude the packages and external libraries needed by your
|
|
|
|
|
input scripts.
|
|
|
|
|
</P>
|
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
|
|
<H4><A NAME = "start_5"></A>2.5 Building LAMMPS as a library
|
2007-02-10 05:37:30 +08:00
|
|
|
</H4>
|
2012-08-12 03:27:54 +08:00
|
|
|
<P>LAMMPS can be built as either a static or shared library, which can
|
|
|
|
|
then be called from another application or a scripting language. See
|
|
|
|
|
<A HREF = "Section_howto.html#howto_10">this section</A> for more info on coupling
|
|
|
|
|
LAMMPS to other codes. See <A HREF = "Section_python.html">this section</A> for
|
|
|
|
|
more info on wrapping and running LAMMPS from Python.
|
|
|
|
|
</P>
|
2012-08-14 01:01:35 +08:00
|
|
|
<H5><B>Static library:</B>
|
|
|
|
|
</H5>
|
2012-08-12 03:27:54 +08:00
|
|
|
<P>To build LAMMPS as a static library (*.a file on Linux), type
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
|
|
|
|
<PRE>make makelib
|
|
|
|
|
make -f Makefile.lib foo
|
|
|
|
|
</PRE>
|
2012-08-12 03:27:54 +08:00
|
|
|
<P>where foo is the machine name. This kind of library is typically used
|
2012-08-13 22:34:09 +08:00
|
|
|
to statically link a driver application to LAMMPS, so that you can
|
|
|
|
|
insure all dependencies are satisfied at compile time. Note that
|
2012-08-12 03:27:54 +08:00
|
|
|
inclusion or exclusion of any desired optional packages should be done
|
|
|
|
|
before typing "make makelib". The first "make" command will create a
|
2012-08-13 22:34:09 +08:00
|
|
|
current Makefile.lib with all the file names in your src dir. The
|
|
|
|
|
second "make" command will use it to build LAMMPS as a static library,
|
|
|
|
|
using the ARCHIVE and ARFLAGS settings in src/MAKE/Makefile.foo. The
|
2012-08-15 04:13:16 +08:00
|
|
|
build will create the file liblammps_foo.a which another application can
|
2012-08-13 22:34:09 +08:00
|
|
|
link to.
|
2012-08-12 03:27:54 +08:00
|
|
|
</P>
|
2012-08-14 01:01:35 +08:00
|
|
|
<H5><B>Shared library:</B>
|
|
|
|
|
</H5>
|
2012-08-12 03:27:54 +08:00
|
|
|
<P>To build LAMMPS as a shared library (*.so file on Linux), which can be
|
2012-08-14 01:01:35 +08:00
|
|
|
dynamically loaded, e.g. from Python, type
|
2012-08-12 03:27:54 +08:00
|
|
|
</P>
|
|
|
|
|
<PRE>make makeshlib
|
|
|
|
|
make -f Makefile.shlib foo
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>where foo is the machine name. This kind of library is required when
|
|
|
|
|
wrapping LAMMPS with Python; see <A HREF = "Section_python.html">Section_python</A>
|
|
|
|
|
for details. Again, note that inclusion or exclusion of any desired
|
|
|
|
|
optional packages should be done before typing "make makelib". The
|
|
|
|
|
first "make" command will create a current Makefile.shlib with all the
|
2012-08-13 22:34:09 +08:00
|
|
|
file names in your src dir. The second "make" command will use it to
|
2012-08-12 03:27:54 +08:00
|
|
|
build LAMMPS as a shared library, using the SHFLAGS and SHLIBFLAGS
|
|
|
|
|
settings in src/MAKE/Makefile.foo. The build will create the file
|
2012-08-15 04:13:16 +08:00
|
|
|
liblammps_foo.so which another application can link to dyamically. It
|
|
|
|
|
will also create a soft link liblammps.so, which the Python wrapper uses
|
2012-08-15 00:13:24 +08:00
|
|
|
by default.
|
2012-08-12 03:27:54 +08:00
|
|
|
</P>
|
|
|
|
|
<P>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
|
2012-08-15 00:13:24 +08:00
|
|
|
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
|
|
|
|
|
lib/packges, since they are always built as shared libraries with the
|
|
|
|
|
-fPIC switch. However, if a library like MPI or FFTW does not exist
|
|
|
|
|
as a shared library, the second make command will generate an error.
|
|
|
|
|
This means you will need to install a shared library version of the
|
|
|
|
|
package. The build instructions for the library should tell you how
|
|
|
|
|
to do this.
|
2012-08-13 22:34:09 +08:00
|
|
|
</P>
|
2012-08-14 01:01:35 +08:00
|
|
|
<P>As an example, here is how to build and install the <A HREF = "http://www-unix.mcs.anl.gov/mpi">MPICH
|
2012-08-13 22:34:09 +08:00
|
|
|
library</A>, a popular open-source version of MPI, distributed by
|
|
|
|
|
Argonne National Labs, as a shared library in the default
|
|
|
|
|
/usr/local/lib location:
|
|
|
|
|
</P>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<PRE>./configure --enable-shared
|
|
|
|
|
make
|
|
|
|
|
make install
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>You may need to use "sudo make install" in place of the last line if
|
2012-08-14 01:01:35 +08:00
|
|
|
you do not have write privileges for /usr/local/lib. The end result
|
2012-08-13 22:34:09 +08:00
|
|
|
should be the file /usr/local/lib/libmpich.so.
|
|
|
|
|
</P>
|
2012-08-15 00:13:24 +08:00
|
|
|
<H5><B>Additional requirement for using a shared library:</B>
|
2012-08-14 01:01:35 +08:00
|
|
|
</H5>
|
|
|
|
|
<P>The operating system finds shared libraries to load at run-time using
|
2012-08-15 04:13:16 +08:00
|
|
|
the environment variable LD_LIBRARY_PATH. So you may wish to copy the
|
|
|
|
|
file src/liblammps.so or src/liblammps_g++.so (for example) to a place
|
|
|
|
|
the system can find it by default, such as /usr/local/lib, or you may
|
2012-08-16 06:59:37 +08:00
|
|
|
wish to add the LAMMPS src directory to LD_LIBRARY_PATH, so that the
|
2012-08-15 07:16:29 +08:00
|
|
|
current version of the shared library is always available to programs
|
|
|
|
|
that use it.
|
2012-08-13 22:34:09 +08:00
|
|
|
</P>
|
2012-08-15 07:16:29 +08:00
|
|
|
<P>For the csh or tcsh shells, you would add something like this to your
|
2012-08-13 22:34:09 +08:00
|
|
|
~/.cshrc file:
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>setenv LD_LIBRARY_PATH $<I>LD_LIBRARY_PATH</I>:/home/sjplimp/lammps/src
|
|
|
|
|
</PRE>
|
2012-08-14 01:01:35 +08:00
|
|
|
<H5><B>Calling the LAMMPS library:</B>
|
|
|
|
|
</H5>
|
|
|
|
|
<P>Either flavor of library (static or shared0 allows one or more LAMMPS
|
|
|
|
|
objects to be instantiated from the calling program.
|
2012-08-12 03:27:54 +08:00
|
|
|
</P>
|
|
|
|
|
<P>When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS_NS
|
2007-02-10 05:37:30 +08:00
|
|
|
namespace; you can safely use any of its classes and methods from
|
2012-08-12 03:27:54 +08:00
|
|
|
within the calling code, as needed.
|
2007-02-10 05:37:30 +08:00
|
|
|
</P>
|
2012-08-12 03:27:54 +08:00
|
|
|
<P>When used from a C or Fortran program or a scripting language like
|
|
|
|
|
Python, the library has a simple function-style interface, provided in
|
2010-11-02 23:05:51 +08:00
|
|
|
src/library.cpp and src/library.h.
|
|
|
|
|
</P>
|
2012-08-12 03:27:54 +08:00
|
|
|
<P>See the sample codes in examples/COUPLE/simple for examples of C++ and
|
2012-08-14 01:01:35 +08:00
|
|
|
C and Fortran 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#howto_10">Section_howto 10</A> of the
|
|
|
|
|
manual. See <A HREF = "Section_python.html">Section_python</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 define the C-style API for
|
|
|
|
|
using LAMMPS as a library. See <A HREF = "Section_howto.html#howto_19">Section_howto
|
|
|
|
|
19</A> of the manual for a description of the
|
|
|
|
|
interface and how to extend it for your needs.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
|
|
|
|
<HR>
|
|
|
|
|
|
2012-01-28 07:39:14 +08:00
|
|
|
<H4><A NAME = "start_6"></A>2.6 Running LAMMPS
|
2006-09-22 00:22:34 +08:00
|
|
|
</H4>
|
2014-02-06 02:09:51 +08:00
|
|
|
<P>By default, LAMMPS runs by reading commands from standard input. Thus
|
|
|
|
|
if you run the LAMMPS executable by itself, e.g.
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>lmp_linux
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>it will simply wait, expecting commands from the keyboard. Typically
|
|
|
|
|
you should put commands in an input script and use I/O redirection,
|
|
|
|
|
e.g.
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>lmp_linux < in.file
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>For parallel environments this should also work. If it does not, use
|
|
|
|
|
the '-in' command-line switch, e.g.
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>lmp_linux -in in.file
|
|
|
|
|
</PRE>
|
|
|
|
|
<P><A HREF = "Section_commands.html">This section</A> describes how input scripts are
|
|
|
|
|
structured and what commands they contain.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
|
|
|
|
<P>You can test LAMMPS on any of the sample inputs provided in the
|
2011-02-11 23:28:32 +08:00
|
|
|
examples or bench 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.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-02-11 23:28:32 +08:00
|
|
|
<P>Here is how you might run a standard Lennard-Jones benchmark on a
|
|
|
|
|
Linux box, using mpirun to launch a parallel job:
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
|
|
|
|
<PRE>cd src
|
|
|
|
|
make linux
|
2011-02-11 23:28:32 +08:00
|
|
|
cp lmp_linux ../bench
|
|
|
|
|
cd ../bench
|
|
|
|
|
mpirun -np 4 lmp_linux < in.lj
|
2006-09-22 00:22:34 +08:00
|
|
|
</PRE>
|
2014-02-06 02:09:51 +08:00
|
|
|
<P>See <A HREF = "http://lammps.sandia.gov/bench.html">this page</A> for timings for this and the other benchmarks on
|
|
|
|
|
various platforms. Note that some of the example scripts require
|
|
|
|
|
LAMMPS to be built with one or more of its optional packages.
|
2011-02-11 23:28:32 +08:00
|
|
|
</P>
|
|
|
|
|
|
|
|
|
|
|
2010-07-17 05:34:50 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2011-06-14 08:33:26 +08:00
|
|
|
<P>On a Windows box, you can skip making LAMMPS and simply download an
|
2011-08-19 01:31:58 +08:00
|
|
|
executable, as described above, though the pre-packaged executables
|
|
|
|
|
include only certain packages.
|
2011-06-14 08:33:26 +08:00
|
|
|
</P>
|
|
|
|
|
<P>To run a 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.
|
2010-07-17 05:34:50 +08:00
|
|
|
</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:
|
2009-10-27 07:21:50 +08:00
|
|
|
</P>
|
2014-02-06 02:09:51 +08:00
|
|
|
<UL><LI>Download and install
|
2010-04-16 00:04:50 +08:00
|
|
|
<A HREF = "http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downloads">MPICH2</A>
|
|
|
|
|
for Windows.
|
|
|
|
|
|
2014-02-06 02:09:51 +08:00
|
|
|
<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.
|
2009-10-27 07:21:50 +08:00
|
|
|
|
2010-07-17 05:34:50 +08:00
|
|
|
<LI>Get a command prompt by going to Start->Run... ,
|
|
|
|
|
then typing "cmd".
|
2009-10-27 07:21:50 +08:00
|
|
|
|
2010-07-17 05:34:50 +08:00
|
|
|
<LI>Move to the directory where you have saved lmp_win_mpi.exe
|
|
|
|
|
(e.g. by typing: cd "Documents").
|
|
|
|
|
|
2014-02-06 02:09:51 +08:00
|
|
|
<LI>Then type something like this: "mpiexec -localonly 4 lmp_win_mpi -in
|
|
|
|
|
in.lj", replacing in.lj with the name of your LAMMPS input script.
|
2010-07-17 05:34:50 +08:00
|
|
|
|
2014-02-06 02:09:51 +08:00
|
|
|
<LI>Note that you may need to provide smpd with a passphrase (it doesn't
|
|
|
|
|
matter what you type).
|
2010-07-17 05:34:50 +08:00
|
|
|
|
2014-02-06 02:09:51 +08:00
|
|
|
<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. :l Alternatively, you can still
|
|
|
|
|
use this executable to run on a single processor by typing something
|
|
|
|
|
like: "lmp_win_mpi -in in.lj".
|
2009-10-27 07:21:50 +08:00
|
|
|
</UL>
|
2010-07-17 05:34:50 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2006-09-22 00:22:34 +08:00
|
|
|
<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.
|
2007-04-02 22:26:01 +08:00
|
|
|
</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
|
2007-05-01 08:14:45 +08:00
|
|
|
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.
|
2006-09-22 00:22:34 +08:00
|
|
|
</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
|
2011-12-14 04:35:35 +08:00
|
|
|
message and continue. See <A HREF = "Section_errors.html">Section_errors</A> for a
|
2006-09-22 00:22:34 +08:00
|
|
|
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>
|
|
|
|
|
|
2012-01-28 07:39:14 +08:00
|
|
|
<H4><A NAME = "start_7"></A>2.7 Command-line options
|
2006-09-22 00:22:34 +08:00
|
|
|
</H4>
|
|
|
|
|
<P>At run time, LAMMPS recognizes several optional command-line switches
|
2011-08-19 01:31:58 +08:00
|
|
|
which may be used in any order. Either the full word or a one-or-two
|
|
|
|
|
letter abbreviation can be used:
|
2011-05-27 06:35:54 +08:00
|
|
|
</P>
|
2011-06-01 07:08:32 +08:00
|
|
|
<UL><LI>-c or -cuda
|
2011-05-27 06:35:54 +08:00
|
|
|
<LI>-e or -echo
|
|
|
|
|
<LI>-i or -in
|
2011-08-19 08:34:10 +08:00
|
|
|
<LI>-h or -help
|
2014-05-30 06:52:23 +08:00
|
|
|
<LI>-k or -kokkos
|
2011-05-27 06:35:54 +08:00
|
|
|
<LI>-l or -log
|
2013-07-31 05:01:14 +08:00
|
|
|
<LI>-nc or -nocite
|
2011-05-27 06:35:54 +08:00
|
|
|
<LI>-p or -partition
|
2011-06-16 01:48:36 +08:00
|
|
|
<LI>-pl or -plog
|
|
|
|
|
<LI>-ps or -pscreen
|
2013-11-23 01:34:49 +08:00
|
|
|
<LI>-r or -restart
|
|
|
|
|
<LI>-ro or -reorder
|
2011-06-01 07:08:32 +08:00
|
|
|
<LI>-sc or -screen
|
|
|
|
|
<LI>-sf or -suffix
|
2011-05-27 06:35:54 +08:00
|
|
|
<LI>-v or -var
|
2011-02-05 03:13:00 +08:00
|
|
|
</UL>
|
|
|
|
|
<P>For example, lmp_ibm might be launched as follows:
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-06-01 07:08:32 +08:00
|
|
|
<PRE>mpirun -np 16 lmp_ibm -v f tmp.out -l my.log -sc none < in.alloy
|
2011-05-27 06:35:54 +08:00
|
|
|
mpirun -np 16 lmp_ibm -var f tmp.out -log my.log -screen none < in.alloy
|
2006-09-22 00:22:34 +08:00
|
|
|
</PRE>
|
2011-02-05 03:13:00 +08:00
|
|
|
<P>Here are the details on the options:
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-06-01 07:08:32 +08:00
|
|
|
<PRE>-cuda on/off
|
2011-05-21 06:46:32 +08:00
|
|
|
</PRE>
|
2011-06-01 07:08:32 +08:00
|
|
|
<P>Explicitly enable or disable CUDA support, as provided by the
|
|
|
|
|
USER-CUDA package. If LAMMPS is built with this package, as described
|
2011-08-26 00:46:23 +08:00
|
|
|
above in <A HREF = "#start_3">Section 2.3</A>, then by default LAMMPS will run in
|
|
|
|
|
CUDA mode. If this switch is set to "off", then it will not, even if
|
|
|
|
|
it was built with the USER-CUDA package, which means you can run
|
|
|
|
|
standard LAMMPS or with the GPU package for testing or benchmarking
|
|
|
|
|
purposes. The only reason to set the switch to "on", is to check if
|
|
|
|
|
LAMMPS was built with the USER-CUDA package, since an error will be
|
|
|
|
|
generated if it was not.
|
2011-05-21 06:46:32 +08:00
|
|
|
</P>
|
2006-09-22 00:22:34 +08:00
|
|
|
<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>
|
2011-05-27 06:35:54 +08:00
|
|
|
<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,
|
2014-02-06 02:09:51 +08:00
|
|
|
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.
|
2011-05-27 06:35:54 +08:00
|
|
|
</P>
|
2011-08-19 08:34:10 +08:00
|
|
|
<PRE>-help
|
|
|
|
|
</PRE>
|
2014-02-06 02:09:51 +08:00
|
|
|
<P>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.
|
2011-08-19 08:34:10 +08:00
|
|
|
</P>
|
2014-05-30 06:52:23 +08:00
|
|
|
<PRE>-kokkos on/off keyword/value ...
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>Explicitly enable or disable Kokkos support, as provided by the KOKKOS
|
|
|
|
|
package. If LAMMPS is built with this package, as described above in
|
|
|
|
|
<A HREF = "#start_3">Section 2.3</A>, then by default LAMMPS will run in Kokkos
|
|
|
|
|
mode. If this switch is set to "off", then it will not, even if it
|
|
|
|
|
was built with the KOKKOS package, which means you can run standard
|
|
|
|
|
LAMMPS styles or use styles enhanced by other acceleration packages,
|
|
|
|
|
such as the GPU or USER-CUDA or USER-OMP packages, for testing or
|
|
|
|
|
benchmarking purposes. The only reason to set the switch to "on", is
|
|
|
|
|
to check if LAMMPS was built with the KOKKOS package, since an error
|
|
|
|
|
will be generated if it was not.
|
|
|
|
|
</P>
|
|
|
|
|
<P>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.
|
|
|
|
|
</P>
|
|
|
|
|
<P>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. More explanation as to when to use these options and
|
|
|
|
|
what settings to use on different platforms is given in <A HREF = "Section_accerlerate.html#acc_8">this
|
|
|
|
|
section</A>.
|
|
|
|
|
</P>
|
|
|
|
|
<UL><LI>d or device
|
|
|
|
|
<LI>g or gpus
|
|
|
|
|
<LI>t or threads
|
|
|
|
|
<LI>n or numa
|
|
|
|
|
</UL>
|
|
|
|
|
<PRE>device Nd
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>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.
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>gpus Ng Ns
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>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.
|
|
|
|
|
</P>
|
|
|
|
|
<P>Depending on which flavor of MPI you are running, LAMMPS will look for
|
|
|
|
|
one of these 3 environment variables
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>SLURM_LOCALID (???) CT NOTE: what MPI is this for?
|
|
|
|
|
MV2_COMM_WORLD_LOCAL_RANK (Mvapich)
|
|
|
|
|
OMPI_COMM_WORLD_LOCAL_RANK (OpenMPI)
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>which are initialized by "mpirun" or "mpiexec". The environment
|
|
|
|
|
variable setting for each MPI rank is used to assign a unique GPU ID
|
|
|
|
|
to the MPI task.
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>threads Nt
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>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.
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>numa Nm
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>CT NOTE: what does numa set, and why use it?
|
|
|
|
|
</P>
|
|
|
|
|
<P>Explain. The default is Nm = 1.
|
|
|
|
|
</P>
|
2011-05-27 06:35:54 +08:00
|
|
|
<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.
|
2011-06-16 01:48:36 +08:00
|
|
|
Option -plog will override the name of the partition log files file.N.
|
2011-05-27 06:35:54 +08:00
|
|
|
</P>
|
2013-07-31 05:01:14 +08:00
|
|
|
<PRE>-nocite
|
|
|
|
|
</PRE>
|
2013-07-31 05:03:20 +08:00
|
|
|
<P>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 <A HREF = "http://lammps.sandia.gov/cite.html">citation page</A> for more
|
|
|
|
|
details.
|
2013-07-31 05:01:14 +08:00
|
|
|
</P>
|
2006-09-22 00:22:34 +08:00
|
|
|
<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>
|
2011-12-09 06:50:07 +08:00
|
|
|
<P>Running with multiple partitions can e useful for running
|
|
|
|
|
<A HREF = "Section_howto.html#howto_5">multi-replica simulations</A>, where each
|
|
|
|
|
replica runs on on one or a few processors. Note that with MPI
|
|
|
|
|
installed on a machine (e.g. your desktop), you can run on more
|
|
|
|
|
(virtual) processors than you have physical processors.
|
|
|
|
|
</P>
|
|
|
|
|
<P>To run multiple independent simulatoins from one input script, using
|
2011-12-14 04:43:36 +08:00
|
|
|
multiple partitions, see <A HREF = "Section_howto.html#howto_4">Section_howto 4</A>
|
|
|
|
|
of the manual. World- and universe-style <A HREF = "variable.html">variables</A>
|
|
|
|
|
are useful in this context.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2011-06-16 01:48:36 +08:00
|
|
|
<PRE>-plog file
|
|
|
|
|
</PRE>
|
2011-12-09 06:50:07 +08:00
|
|
|
<P>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.
|
2011-06-16 01:48:36 +08:00
|
|
|
</P>
|
|
|
|
|
<PRE>-pscreen file
|
|
|
|
|
</PRE>
|
2011-12-09 06:50:07 +08:00
|
|
|
<P>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
|
2011-12-13 23:58:47 +08:00
|
|
|
sub-directory (-pscreen replica_files/screen). If this option is not
|
2011-12-09 06:50:07 +08:00
|
|
|
used the screen file for partition N is screen.N or whatever is
|
|
|
|
|
specified by the -screen command-line option.
|
2011-06-16 01:48:36 +08:00
|
|
|
</P>
|
2013-11-26 01:18:51 +08:00
|
|
|
<PRE>-restart restartfile datafile keyword value ...
|
2013-11-23 01:34:49 +08:00
|
|
|
</PRE>
|
|
|
|
|
<P>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:
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>read_restart restartfile
|
2013-11-26 01:18:51 +08:00
|
|
|
write_data datafile keyword value ...
|
2013-11-23 01:34:49 +08:00
|
|
|
</PRE>
|
|
|
|
|
<P>Note that the specified restartfile and datafile can have wild-card
|
|
|
|
|
characters ("*",%") as described by the
|
|
|
|
|
<A HREF = "read_restart.html">read_restart</A> and <A HREF = "write_data.html">write_data</A>
|
|
|
|
|
commands. But a filename such as file.* will need to be enclosed in
|
|
|
|
|
quotes to avoid shell expansion of the "*" character.
|
|
|
|
|
</P>
|
2013-11-26 01:18:51 +08:00
|
|
|
<P>Also note that following datafile, the same optional keyword/value
|
|
|
|
|
pairs can be listed as used by the <A HREF = "write_data.html">write_data</A>
|
|
|
|
|
command.
|
2013-11-26 01:01:04 +08:00
|
|
|
</P>
|
2011-12-13 23:58:47 +08:00
|
|
|
<PRE>-reorder nth N
|
|
|
|
|
-reorder custom filename
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>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 <A HREF = "run_style.html">run_style verlet/split</A> 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 <A HREF = "Section_accelerate.html">Section_accelerate</A> doc pages for
|
|
|
|
|
more details.
|
|
|
|
|
</P>
|
|
|
|
|
<P>If the keyword <I>nth</I> is used with a setting <I>N</I>, then it means every
|
|
|
|
|
Nth processor will be moved to the end of the ranking. This is useful
|
|
|
|
|
when using the <A HREF = "run_style.html">run_style verlet/split</A> 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
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>0 1 2 3 4 5 6 7 8 9 10 11
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>to
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>0 1 2 4 5 6 8 9 10 3 7 11
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>so that the processors in each partition will be
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>0 1 2 4 5 6 8 9 10
|
|
|
|
|
3 7 11
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>See the "processors" command for how to insure processors from each
|
|
|
|
|
partition could then be grouped optimally for quad-core nodes.
|
|
|
|
|
</P>
|
2013-05-29 07:12:56 +08:00
|
|
|
<P>If the keyword is <I>custom</I>, then a file that specifies a permutation
|
2011-12-13 23:58:47 +08:00
|
|
|
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:
|
|
|
|
|
</P>
|
|
|
|
|
<PRE>I J
|
|
|
|
|
</PRE>
|
|
|
|
|
<P>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.
|
|
|
|
|
</P>
|
|
|
|
|
<P>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 <A HREF = "processors">processors out</A> command for how to output
|
|
|
|
|
info on the final assignment of physical processors to the LAMMPS
|
|
|
|
|
simulation domain.
|
|
|
|
|
</P>
|
2006-09-22 00:22:34 +08:00
|
|
|
<PRE>-screen file
|
|
|
|
|
</PRE>
|
2006-09-28 07:20:16 +08:00
|
|
|
<P>Specify a file for LAMMPS to write its screen information to. In
|
2006-09-22 00:22:34 +08:00
|
|
|
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
|
2011-12-09 06:50:07 +08:00
|
|
|
output is performed. Option -pscreen will override the name of the
|
2011-06-16 01:48:36 +08:00
|
|
|
partition screen files file.N.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2014-05-30 06:52:23 +08:00
|
|
|
<PRE>-suffix style args
|
2011-06-01 07:08:32 +08:00
|
|
|
</PRE>
|
|
|
|
|
<P>Use variants of various styles if they exist. The specified style can
|
2014-05-30 06:52:23 +08:00
|
|
|
be <I>cuda</I>, <I>gpu</I>, <I>kk</I>, <I>omp</I>, or <I>opt</I>. These refer to optional
|
|
|
|
|
packages that LAMMPS can be built with, as described above in <A HREF = "#start_3">Section
|
|
|
|
|
2.3</A>. The "cuda" style corresponds to the USER-CUDA package,
|
|
|
|
|
the "gpu" style to the GPU package, the "kk" style to the KOKKOS
|
|
|
|
|
pacakge, the "opt" style to the OPT package, and the "omp" style to
|
|
|
|
|
the USER-OMP package.
|
2011-06-01 07:08:32 +08:00
|
|
|
</P>
|
|
|
|
|
<P>As an example, all of the packages provide a <A HREF = "pair_lj.html">pair_style
|
2014-05-30 06:52:23 +08:00
|
|
|
lj/cut</A> variant, with style names lj/cut/cuda,
|
|
|
|
|
lj/cut/gpu, lj/cut/kk, lj/cut/omp, or lj/cut/opt. A variant styles
|
|
|
|
|
can be specified explicitly in your input script, e.g. pair_style
|
|
|
|
|
lj/cut/gpu. If the -suffix switch is used, you do not need to modify
|
|
|
|
|
your input script. The specified suffix (cuda,gpu,kk,omp,opt) is
|
|
|
|
|
automatically appended whenever your input script command creates a
|
|
|
|
|
new <A HREF = "atom_style.html">atom</A>, <A HREF = "pair_style.html">pair</A>, <A HREF = "fix.html">fix</A>,
|
2011-12-02 23:47:30 +08:00
|
|
|
<A HREF = "compute.html">compute</A>, or <A HREF = "run_style.html">run</A> style. If the variant
|
|
|
|
|
version does not exist, the standard version is created.
|
|
|
|
|
</P>
|
|
|
|
|
<P>For the GPU package, using this command-line switch also invokes the
|
|
|
|
|
default GPU settings, as if the command "package gpu force/neigh 0 0
|
|
|
|
|
1" were used at the top of your input script. These settings can be
|
2012-03-01 23:12:16 +08:00
|
|
|
changed by using the <A HREF = "package.html">package gpu</A> command in your script
|
2011-12-02 23:47:30 +08:00
|
|
|
if desired.
|
|
|
|
|
</P>
|
2014-05-30 06:52:23 +08:00
|
|
|
<P>For the KOKKOS package, using this command-line switch also invokes
|
|
|
|
|
the default KOKKOS settings, as if the command "package kokkos neigh
|
|
|
|
|
full comm/exchange host comm/forward host " were used at the top of
|
|
|
|
|
your input script. These settings can be changed by using the
|
|
|
|
|
<A HREF = "package.html">package kokkos</A> command in your script if desired.
|
|
|
|
|
</P>
|
2011-12-02 23:47:30 +08:00
|
|
|
<P>For the OMP package, using this command-line switch also invokes the
|
|
|
|
|
default OMP settings, as if the command "package omp *" were used at
|
|
|
|
|
the top of your input script. These settings can be changed by using
|
2012-03-01 23:12:16 +08:00
|
|
|
the <A HREF = "package.html">package omp</A> command in your script if desired.
|
2011-06-01 07:08:32 +08:00
|
|
|
</P>
|
2014-05-30 06:52:23 +08:00
|
|
|
<P>The <A HREF = "suffix.html">suffix</A> command can also be used set a suffix and it
|
|
|
|
|
can also turn off or back on any suffix setting made via the command
|
|
|
|
|
line.
|
2011-06-01 07:08:32 +08:00
|
|
|
</P>
|
2011-02-05 03:13:00 +08:00
|
|
|
<PRE>-var name value1 value2 ...
|
2006-09-22 00:22:34 +08:00
|
|
|
</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
|
2011-02-05 03:13:00 +08:00
|
|
|
string (referenced as ${abc}). An <A HREF = "variable.html">index-style
|
|
|
|
|
variable</A> 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 <A HREF = "variable.html">variable</A> command for more info on
|
2011-08-26 01:01:01 +08:00
|
|
|
defining index and other kinds of variables and <A HREF = "Section_commands.html#cmd_2">this
|
|
|
|
|
section</A> for more info on using variables
|
|
|
|
|
in input scripts.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2013-10-30 23:10:46 +08:00
|
|
|
<P>NOTE: Currently, the command-line parser looks for arguments that
|
|
|
|
|
start with "-" to indicate new switches. Thus you cannot specify
|
2011-10-10 23:01:46 +08:00
|
|
|
multiple variable values if any of they start with a "-", e.g. a
|
|
|
|
|
negative numeric value. It is OK if the first value1 starts with a
|
|
|
|
|
"-", since it is automatically skipped.
|
|
|
|
|
</P>
|
2006-09-22 00:22:34 +08:00
|
|
|
<HR>
|
|
|
|
|
|
2012-01-28 07:39:14 +08:00
|
|
|
<H4><A NAME = "start_8"></A>2.8 LAMMPS screen output
|
2006-09-22 00:22:34 +08:00
|
|
|
</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
|
2006-09-28 07:20:16 +08:00
|
|
|
force-evaluations the minimizer required. Multiple force evaluations
|
2006-09-22 00:22:34 +08:00
|
|
|
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>
|
|
|
|
|
|
2012-01-28 07:39:14 +08:00
|
|
|
<H4><A NAME = "start_9"></A>2.9 Tips for users of previous LAMMPS versions
|
2006-09-22 00:22:34 +08:00
|
|
|
</H4>
|
2009-08-13 00:45:55 +08:00
|
|
|
<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
|
2011-12-14 04:35:35 +08:00
|
|
|
in <A HREF = "Section_history.html">Section_history</A>. The F90 and F77 versions
|
2009-08-13 00:45:55 +08:00
|
|
|
(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.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
|
|
|
|
<P>If you are a previous user of LAMMPS 2001, these are the most
|
2009-08-13 00:45:55 +08:00
|
|
|
significant changes you will notice in C++ LAMMPS:
|
2006-09-22 00:22:34 +08:00
|
|
|
</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>
|
2009-08-13 00:45:55 +08:00
|
|
|
<P>(2) All the functionality of LAMMPS 2001 is included in C++ LAMMPS,
|
2006-09-22 00:22:34 +08:00
|
|
|
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
|
2009-08-13 00:45:55 +08:00
|
|
|
section "Nonbond Coeff" has been renamed to "Pair Coeff" in C++ LAMMPS.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2009-08-13 00:45:55 +08:00
|
|
|
<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
|
2006-09-22 00:22:34 +08:00
|
|
|
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
|
2009-08-13 00:45:55 +08:00
|
|
|
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.
|
2006-09-22 00:22:34 +08:00
|
|
|
</P>
|
2009-08-13 00:45:55 +08:00
|
|
|
<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.
|
2006-09-22 00:22:34 +08:00
|
|
|
However, your initial thermodynamic energy and MD trajectory should be
|
|
|
|
|
close if you have setup the problem for both codes the same.
|
|
|
|
|
</P>
|
|
|
|
|
</HTML>
|
