Build from source: LAMMPS

Start by setting-up a properly-versioned directory hierarchy for LAMMPS builds. For example:

$ mkdir -p ~/sw/lammps
$ cd ~/sw/lammps
$ mkdir attic

The attic directory is used to hold downloaded source packages, etc. I can download the latest LAMMPS stable source by visiting the official downloads page and getting a “tarball” of the latest stable release. This usually downloads as lammps-stable.tar.gz which is slightly annoying because it doesn't cite the release date (so every release you download uses the same filename). When I upload the source to ~/sw/lammps/attic I rename it: at the time of writing, the stable release is 11 August 2017, so I rename the file lammps-20170811.tar.gz to make that clear:

$ cd ~/sw/lammps
$ ls -l attic
total 117944
-rw-r--r-- 1 frey cadmin 120774006 2018-02-14 13:42 lammps-20170811.tar.gz

Create a directory to hold the new version you are building. The name should include the release (version or date, etc.) and any special features worth mentioning. In this case, we'll be building the 11 August 2017 release without any special features:

$ cd ~/sw/lammps
$ mkdir 20170811
$ ls -l
total 0
drwxr-xr-x 2 frey cadmin  6 2018-02-14 13:45 20170811
drwxr-xr-x 2 frey cadmin 35 2018-02-14 13:42 attic

Next, unpack the source code inside the version directory just created:

$ cd 20170811
$ tar -zxf ../attic/lammps-20170811.tar.gz
$ ls -l
total 0
drwxr-xr-x 10 frey cadmin 132 2017-08-11 14:19 lammps-11Aug17

The directory structure we promote will have all the executables, libraries, etc. installed in the 20170811 directory; I typically rename the source code directory src rather than whatever name the program author(s) used:

$ mv lammps-11Aug17 src
$ cd src
$ ls -l
total 100
drwxr-xr-x  5 frey cadmin  4096 2017-08-11 14:18 bench
drwxr-xr-x  5 frey cadmin   104 2017-08-11 14:23 doc
drwxr-xr-x 60 frey cadmin  4096 2017-08-11 14:18 examples
drwxr-xr-x 23 frey cadmin  4096 2017-08-11 14:18 lib
-rw-r--r--  1 frey cadmin 17775 2017-07-24 10:58 LICENSE
drwxr-xr-x  2 frey cadmin  4096 2017-08-11 14:18 potentials
drwxr-xr-x  3 frey cadmin    84 2017-08-11 14:18 python
-rw-r--r--  1 frey cadmin  1690 2011-09-23 19:48 README
drwxr-xr-x 66 frey cadmin 32768 2017-08-11 14:23 src
drwxr-xr-x 28 frey cadmin  4096 2017-08-11 14:19 tools

LAMMPS makes use of the Unix make command to manage the transformation of its source code into executables and libraries. There is no automated configuration or generation of a Makefile a'la GNU autoconf or CMake. Instead, a Makefile template is copied and edited by hand for each build variant:

$ cd src
$ ls -l MAKE
total 24
drwxr-xr-x 2 frey cadmin 4096 2017-08-11 14:18 MACHINES
-rw-r--r-- 1 frey cadmin 2972 2016-05-12 09:54 Makefile.mpi
-rw-r--r-- 1 frey cadmin 2960 2016-05-12 09:54 Makefile.serial
drwxr-xr-x 2 frey cadmin    6 2017-08-11 14:18 MINE
drwxr-xr-x 2 frey cadmin 4096 2017-08-11 14:18 OPTIONS
-rw-r--r-- 1 frey cadmin 4797 2016-04-26 15:38 README

For a simple serial build using GNU compilers (g++) nothing needs to be done: the Makefile.serial can be used as-is. The suffix serial is a machine identifier in the LAMMPS build system. Assuming I have GNU compilers setup in my environment, the build is as simple as:

$ which g++
/usr/bin/g++
$ make serial
  :

Quite a bit of information is displayed as the build proceeds: compilation commands for each individual source file, navigation through the source directory, and warning/error messages the compiler(s) may generate. A successful build will end with a summary line:

  :
   text	   data	    bss	    dec	    hex	filename
5722883	   7744	    968	5731595	 57750b	../lmp_serial
make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_serial'

All of the intermediate object code files and the completed executable are found in the Obj_serial directory (if you're keeping track, that's ~/sw/lammps/20170811/src/src/Obj_serial). That directory name consists of the prefix Obj_ and the LAMMPS machine name that was built. The executable itself is named lmp_«machine» and is in the src directory itself (where you issued the make command).

The final task is to finish setting-up the 20170811 directory where we have the source code. At this point we've produced an executable, so it should be made available in a bin directory:

$ cd ~/sw/lammps/20170811
$ mkdir -p bin
$ cd bin
$ cp ../src/src/lmp_serial lammps
$ ls -l
total 23956
-rwxr-xr-x 1 frey cadmin 24529796 2018-02-14 14:24 lammps
$ ldd lammps
	linux-vdso.so.1 =>  (0x00007fffa38d6000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f8bf6eca000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f8bf6c74000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8bf6a5d000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f8bf66ff000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8bf71d5000)

In essence, you installed a copy of the finished executable in the bin directory; if you make changes to the build, they may affect the lmp_serial executable down in the src/src directory, but they won't affect your working executable until you do another such cp.

LAMMPS contains additional code that can be selectively included/excluded from the executable you build. These components are known as packages in the LAMMPS build system. Standard packages are provided by the LAMMPS authors; user packages are contributed code and use a name prefixed with USER-.

Let's enable the LAMMPS built-in Python support (third variant on this page) and rebuild our serial variant:

$ cd ~/sw/lammps/20170811/src/src
$ make package-status | grep -i python
Installed NO: package PYTHON
$ make yes-python
Installing package python
$ make serial
make[1]: Entering directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_serial'
make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_serial'
make[1]: Entering directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_serial'
g++ -g -O3  -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -DLMP_PYTHON  -I../STUBS      -c ../fix_python.cpp
../fix_python.cpp:18:20: error: Python.h: No such file or directory
../fix_python.cpp: In constructor ‘LAMMPS_NS::FixPython::FixPython(LAMMPS_NS::LAMMPS*, int, char**)’:
../fix_python.cpp:55: error: ‘PyGILState_STATE’ was not declared in this scope
  :
../fix_python.cpp:111: error: ‘PyGILState_Release’ was not declared in this scope
make[1]: *** [fix_python.o] Error 1
make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_serial'
make: *** [serial] Error 2

This time the build was not successful. The first error cited indicates that there is no Python development package installed with our operating system: Python.h is the C header file that describes the Python API when programs wish to use the Python library.

On our clusters, the VALET configuration management tool is used to selectively add software to the environment:

$ vpkg_versions python
Available versions in package (* = default version):
python    Python Programming Language
  2.7.13  Version 2.7.13
* 3.2.3   Version 3.2.3
  3.2     (alias of 3.2.3)
  3       (alias of 3.2.3)
  2.7     (alias of 2.7.13)
$ vpkg_devrequire python/2.7
Adding package `python/2.7.13` to your environment

Since LAMMPS requires us to manually maintain Makefiles, we will make our own machine similar to serial:

$ cp MAKE/Makefile.serial MAKE/MINE/Makefile.local_serial

Edit the MAKE/MINE/Makefile.local_serial to modify:

• the line that sets the value of CCFLAGS
• the line that sets the value of LINKFLAGS
• the line that sets the value of LIB

  :
CC =            g++
CCFLAGS =       -g -O3 $(CPPFLAGS)
SHFLAGS =       -fPIC
DEPFLAGS =      -M

LINK =          g++
LINKFLAGS =     -g -O $(LDFLAGS)
LIB =           -lpython2.7
  :

Since the VALET vpkg_devrequire command adds appropriate header and library paths to the CPPFLAGS and LDFLAGS environment variables, we need only add their value to the other flags specified in the Makefile. The Python library must be added to the linking command via the LIB variable. A build is now successful:

$ make local_serial
  :
   text	   data	    bss	    dec	    hex	filename
6513443	   8048	    968	6522459	 63865b	../lmp_local_serial
make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial'

This variant of LAMMPS has the capability of embedding Python code inside the job input file. When I'm ready to use this variant of the build, I can copy the executable to the bin directory:

$ cp lmp_local_serial ../../bin/lammps

After logging out for a time, I've returned and want to try adding the KOKKOS package to the build:

$ cd ~/sw/lammps/20170811/src/src
$ vpkg_devrequire python/2.7
Adding package `python/2.7.13` to your environment
$ make yes-KOKKOS
Installing package KOKKOS
$ make local_serial
  :
g++ -g -O3    -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -DLMP_KOKKOS -DLMP_PYTHON  -I../STUBS    -I./ -I../../lib/kokkos/core/src -I../../lib/kokkos/containers/src -I../../lib/kokkos/algorithms/src  --std=c++11 -fopenmp   -c ../angle_charmm.cpp
cc1plus: error: unrecognized command line option "-std=c++11"
make[1]: *** [angle_charmm.o] Error 1
make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial'
make: *** [local_serial] Error 2

The GNU C++ compiler does not understand a command-line option that the KOKKOS code has added: –std=c++11 indicates a particular dialect of C++ that the compiler should target, and isn't available in the GCC 4.3.4 compiler collection we are using. The GCC 4.9 compilers do accept that flag, and we just happen to have that compiler available:

$ vpkg_versions gcc
Available versions in package (* = default version):
gcc       GNU Compiler Suite
* system  OS-default GCC installation
  4.9.3   Version 4.9.3
  4.9     (alias of 4.9.3)
$ vpkg_require gcc/4.9
Adding package `gcc/4.9.3` to your environment
$ which g++
/data/opt/gcc/4.9.3/bin/g++

Since the appropriate directories were added to the PATH environment variable, the command g++ no longer maps to /usr/bin/g++ but to the 4.9.3 version; thus, we do not need to alter our Makefile.local_serial to change the value of CC and LINK! Before proceeding, we need to clean-out all the previous object code files: since they were produced with a different version of the compiler, it's best to start anew:

$ make clean-local_serial
  :
$ make local_serial
  :
   text	   data	    bss	    dec	    hex	filename
12719862	  11624	 315272	13046758	 c713e6	../lmp_local_serial
make[1]: Leaving directory `/data/home/frey/sw/lammps/20170811/src/src/Obj_local_serial'
$ ldd lmp_local_serial 
	linux-vdso.so.1 =>  (0x00007fff591ff000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f5ee96c8000)
	libpython2.7.so.1.0 => /opt/python/2.7.13/lib/libpython2.7.so.1.0 (0x00007f5ee92ce000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5ee90b1000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f5ee8eae000)
	libstdc++.so.6 => /data/opt/gcc/4.9.3/lib64/libstdc++.so.6 (0x00007f5ee8b96000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f5ee8940000)
	libgomp.so.1 => /data/opt/gcc/4.9.3/lib64/libgomp.so.1 (0x00007f5ee8729000)
	libgcc_s.so.1 => /data/opt/gcc/4.9.3/lib64/libgcc_s.so.1 (0x00007f5ee8512000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f5ee81b4000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5ee98cc000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f5ee7fab000)

Note that there are now additional shared libraries referenced by the executable. Before running this copy both the Python and GCC packages used to build it must be added to the environment:

$ vpkg_require python/2.7 gcc/4.9
Adding package `python/2.7.13` to your environment
Adding package `gcc/4.9.3` to your environment
$ ldd ~/sw/lammps/20170811/src/src/lmp_local_serial 
	linux-vdso.so.1 =>  (0x00007fff49fb6000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f5fa712c000)
	libpython2.7.so.1.0 => /opt/python/2.7.13/lib/libpython2.7.so.1.0 (0x00007f5fa6d32000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5fa6b15000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f5fa6912000)
	libstdc++.so.6 => /data/opt/gcc/4.9.3/lib64/libstdc++.so.6 (0x00007f5fa65fa000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f5fa63a4000)
	libgomp.so.1 => /data/opt/gcc/4.9.3/lib64/libgomp.so.1 (0x00007f5fa618d000)
	libgcc_s.so.1 => /data/opt/gcc/4.9.3/lib64/libgcc_s.so.1 (0x00007f5fa5f76000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f5fa5c18000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5fa7330000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f5fa5a0f000)