Installation

Table of Contents


Prerequisites


  • Modern C and Fortran compilers (GCC v4.7+ and Intel v14+ are known to work).
  • BLAS, LAPACK and fftw3 libraries.
  • libxc v2.2+
  • Python v2.7+
  • ninja build system v1.7+ (https://ninja-build.org or preferrably: https://gitlab.com/questaal/ninja-vw.git)

MPI, BLACS, SCALAPACK etc.. are optional.

A modified version of the official ninja build system is used. While the upstream code from https://ninja-build.org/ is good for building the programs and running most test locally or through a queing system, trying to run the parallel tests on a single node though may lead to overload and failures unless the modified ninja from https://gitlab.com/questaal/ninja-vw.git is used. The modification is pending review and until it is complete the following lines will produce a capable binary fairly quickly:

git clone https://gitlab.com/questaal/ninja-vw.git
cd ninja-vw && CXX=g++ ./configure.py --bootstrap
ln -s `pwd`/ninja ~/bin/

Downloading and Installation


First of all, clone the basic and GW repositories to your local machine using for example the command below (remember to change <username> to your bitbucket username).

git clone https://<username>@bitbucket.org/lmto/lm.git
git clone https://<username>@bitbucket.org/lmto/gw.git

You won’t need the second clone unless you want to use the GW codes. If you’d rather not be asked for pasword every time you can import a public ssh key to your account.

The basic package will install in directory lm, the GW source in directory gw. You may wish to rename either directory to something else. Go to the lm directory and (if you are using the GW package) create a soft link to the GW source directory. All packages are installed in the lm directory.

cd lm
ln -s ../gw gw

In an empty folder (we use build here), create file flags.mk which contains variables and flags necessary for the build.

mkdir build                              # Choose any directory name
cd build
../genflags.py intel opt > flags.mk      # assuming you are using the intel compiler ifort

If using gnu compilers, run genflags.py with gcc (cray and env are also options)

../genflags.py gcc   opt > flags.mk      # For gnu compilers

genflags.py will attempt to find include files, fortran modules and lib files for libxc in the commonly kept places. Environment variables INCLUDE and CPATH will be searched for .h and .mod files, and LIBRARY_PATH for the relevant .a or .so files. Beware that libxc .mod files have to be generated by the same compiler you are using now. If they are not, the compilation will most likely fail later.

An attempt is made to use intel’s mkl even with gcc however if MKLROOT variable is not found it is abandoned and the generic -lblas -llapack -lfftw3 are generated. If you have a more favourable libs implementing BLAS, LAPACK (+ BLACS and SCALAPACK for the MPI case) please specify them manually.

To obtain an mpi-enabled flags.mk, add an argument to genflags.py e.g.

../genflags.py intel openmpi opt > flags.mk      # Using openmpi
../genflags.py intel intelmpi opt > flags.mk     # Using intelmpi

The mpi version chages the interface to the intel mkl cluster libs and the default compiler wrappers.

Owing to the wide ranging variability of software environments on compute clusters we are not attempting to fully autoconfigure a compilation. flags.mk is a template which can be easily customised to any particular environment. If MPI is to be enabled the relevant quantities described above need to be specified.

Inspect flags.mk. If you have a more or less standard linux build, it may be fine as is. For the build to succeed you must have the libraries and utilities described at the beginning of this documentation. If you are using another OS, notably Mac OS, you will need to make some adjustments. See below.

In the folder where flags.mk resides, generate a build file with the configure.py utility from the source path.

../configure.py
Compiling the executables

The ninja build tool uses the generated build file to compile and link all executables as quickly as possible.

ninja

will build target all using N+2 (where N == all virtual cores) simultaneous compilation/linking processes. On a well integrated system, autocompleting after ‘ninja’ shall list all available targets.

It is advisable to test the build. Each module has a related set of tests which can be invoked with the following command after replacing ‘<modulename>’ with one of the modules: lm, fp, gf, pgf, sx, gwd, optics, tb, mol, dmft, gw.

ninja test-<modulename>

The following convenience command will start most of the tests:

ninja test

Additional Notes


If compiler optimisations cause erroneous results one may wish to set lower level of optimisations for certain sensitive files only or have a number of different flags applying to different groups of files. If such is the case the flags.mk file may be modified to contain the the special flags for a group of files in a variable beginning with the prefix lessflags and ending in a word of one’s choosing. Then a variable beginning with lessfiles and ending in the word chosen for the lessflags variable, must be defined containing the questionable file names relative to the lm/ path. Many pairs of special flags/sensitive files groups are allowed so long as the contents of the lesserfiles variables do not overlap.

To obtain an example containing special flags try

genflags.py intel opt

On CRAY installations it is advisable to use cray’s compiler wrappers ‘cc’, ‘ftn’ and ‘CC’ with the intel backend. Assuming the default backend is cray

module swap PrgEnv-cray PrgEnv-intel

will switch your environment to intel. The wrappers bundle pretty much all standard system libs (BLAS, LAPACK, SCALAPACK, FFTW3, MPI etc..) except libxc.

genflags.py cray opt

will give a reasonable starting point for such an endeavour.

The executables (and possibly other files in future) can be installed in a path defined in a variable named ‘prefix’ in the flags.mk file. Subsequent ‘ninja install’ will copy only the binaries already build, without introducing any additional dependencies.

Workarounds for problematic systems


Apple’s Mac OS
  1. The standard functions diff, zdiff and awk are less versatile than their GNU couterparts. Some of the testing scripts make use of the extra versatility of GNU versions. Before running the standard checks, please install the GNU versions of diff and awk, e.g. using macports. Also copy zdiff from a linux system and park it in the directory where diff is located.

  2. Apple’s BLAS library has some bugs. Apple’s vecLib framework follows an archaic F2C-style return value convention for some BLAS and LAPACK functions, notably functions which return complex numbers. This causes wrong results with gfortran if you use the Apples BLAS or LAPACK libraries.

    The best workaround is to install a substitute to Apple’s vecLibFort, which can be found at https://github.com/mcg1969/vecLibFort. If you install the build in the default directory /usr/local/lib, you should have an archive /usr/local/lib/libvecLibFort.a.

    This library substitutes for the Apple standard one. To make the link use this library, modify ldflags in flags.mk by inserting it as the first one, e.g.

    ldflags = /usr/local/lib/libvecLibFort.a -lfftw3 -llapack -lblas -L${LIBXCPATH}/lib -lxcf90 -lxc
    
  3. Mac OS lacks important features in readlink and comes with an archaic version of bash. Script testrun_simple.sh will not work with it.

    As a short term workaround, copy startup/testrun_simple-for-mac.sh to testrun_simple.sh in your build directory.

  4. If FFTW is installed through Homebrew, ensure the with-fortran option is included, i.e.,

    brew install fftw --with-fortran
    

    A similar option is probably required if using, for example, macports.


Edit This Page