vasp-builds

Working makefile.include files and build notes for VASP, linked against Wannier90, on a shared HPC cluster — for both the Intel and the GNU toolchain.

I maintained these builds for my research group during my PhD. VASP ships no configure script, the bundled templates rarely work unmodified on a real cluster, and the failure modes are mostly link-time, mostly silent, and mostly cryptic. These are the files that actually worked, plus the reasoning behind the parts that are easy to get wrong.

VASP is licensed software. Nothing here contains VASP source — only build configuration.

Contents

Path	What it is
intel/makefile.include	VASP 5.4.4 · ifort + Intel MKL + Open MPI · linked to Wannier90. VASP 6 deltas noted inline
gnu/makefile.include	VASP 5.4.4 · gfortran + Intel MKL + Open MPI · linked to Wannier90
docs/workflow.md	The four-stage relax to SCF to DOS to bands workflow, and the INCAR flags that control it

The environment these were built against

OS	SUSE Linux
Intel Fortran	ifort (IFORT) 19.0.4.243
GNU Fortran	gfortran 7.4.0
MPI	Open MPI 4.0.1
Math library	Intel MKL 2019.4.243
Wannier90	3.0.0
Scheduler	LoadLeveler

Things that cost me time

Match the BLACS library to your MPI. MKL ships a separate BLACS for each MPI implementation — libmkl_blacs_openmpi_lp64, libmkl_blacs_intelmpi_lp64, and others. Pick the wrong one and everything links cleanly, then ScaLAPACK deadlocks or segfaults at runtime with no useful message. This is the single most expensive mistake in the file.

Wannier90 is a two-sided contract. You need -DVASP2WANNIER90v2 in CPP_OPTIONS and libwannier.a on LLIBS. Both halves, or the interface silently is not there. And libwannier.a must be built with the same Fortran compiler as VASP — an ifort-built library linked into a gfortran VASP fails with undefined symbols from name mangling, which does not look like a compiler-mismatch error at all.

GNU compilers with Intel MKL is fine. Use the LP64 Intel interface layer (-lmkl_intel_lp64 -lmkl_sequential -lmkl_core) even under gfortran. It is the documented combination, and it is often the better option when the site MKL is newer than the site ifort.

FREE is toolchain-specific. ifort needs -free -names lowercase. gfortran needs it empty — it infers free-form from the .f90 extension, and passing the ifort flags is an error. Copying one config over the other and forgetting this line is a classic.

-Duse_shmem and -Duse_shmemi are not interchangeable. My Intel config used -Duse_shmemi and my GNU config -Duse_shmem. If getshmem.c fails to compile, or you get undefined symbols around getshmem at link time, check this flag against the template that shipped with your VASP version before touching anything else.

FFTW comes from MKL. Point INCS at $(MKLROOT)/include/fftw and you do not need a separate FFTW build. The only reason a real FFTW appears in the GNU config is -lfftw3f for single precision.

Be careful with -xHOST. It targets the architecture of whichever node you happened to compile on. On a heterogeneous cluster that produces illegal-instruction crashes on the older nodes, weeks later, in jobs that ran fine before. Name the ISA explicitly instead.

Building

# 1. Wannier90 first, with the same Fortran compiler you will use for VASP
cd wannier90-3.0.0 && make lib

# 2. Drop the makefile.include into the VASP source root
cp vasp-builds/intel/makefile.include vasp.5.4.4/

# 3. Point it at your Wannier90 build
export WANNIER90_ROOT=/path/to/wannier90-3.0.0

# 4. Build
cd vasp.5.4.4 && make std

Binaries land in bin/. Sanity-check with a small known system and compare the total energy against a published value before trusting a production run.

License

MIT — these are build configuration files and notes, use them however is useful.