Wolfgang Tichy

Important libraries

BLAS and LAPACK

BLAS contains functions for common linear algebra operations such as vector addition, scalar multiplication, dot products, linear combinations, and matrix multiplication.

LAPACK relies on BLAS to provide more complicated linear algebra routines for e.g. solving systems of linear equations and linear least squares, eigenvalue problems, or matrix factorizations such as LU.

Many different implementations of BLAS and LAPACK exist. A commonly used one is OpenBLAS, which contains both BLAS and LAPACK in one library file. I.e. if one uses OpenBLAS it suffices to add

-lopenblas

to link in support for both BLAS and LAPACK functions.

In other implementations BLAS and LAPACK are in separate libraries and then one usually adds

-lblas -llapack

to link in support for BLAS and LAPACK functions.

GSL

The GNU Scientific Library (GSL) is a numerical library. To use it, one can add

-lgsl -lgslcblas

In this form it uses the BLAS implementation gslcblas, provided by the GSL itself. However, since gslcblas is not optimized very well, it is better to use something like

-lgsl -lopenblas

Then it uses the faster OpenBLAS library.

UMFPACK

UMFPACK is a very fast library for finding the LU-decomposition of sparse matrices. To function it also needs the AMD library, as well as BLAS. I.e. to compile with UMFPACK one needs e.g.:

-lumfpack -lamd -lopenblas

Both UMFPACK and AMD are part of the very large SuiteSparse package. However, if you only need UMFPACK (and AMD) you can also just type

git clone https://github.com/wofti/Packages.git
cd Packages/forUMFPACK

and build it yourself by following the instructions in the Note.txt file, located in the forUMFPACK dir.

Using libraries on supercomputers

As explained in the Compile Notes one often also needs to specify the exact directories where the libraries and their include files reside (i.e. the -L and -I options). If there are several versions of each library, this can get tedious very quickly. For this reason many supercomputers have a module system, that can be used to set up the default search locations for the compiler. E.g. in order to link with OpenBLAS one would simply type

module load openblas

before compiling. Then the -L and -I options do not need to be given, and configurations such as MyConfig simplify.

This works because the module system will do one of two things:

It can change your PATH environment variable, so that each time you start gcc it will actually run a wrapper script instead. This wrapper script then inserts all the -L and -I options needed when it launches the real gcc.
Or it can set the environment variables LIBRARY_PATH and CPATH that the gcc compiler uses (if no -L or -I are given) to search for libraries and include files.

You can verify if LIBRARY_PATH and CPATH have been set with:

echo $LIBRARY_PATH
echo $CPATH

If the module system sets LIBRARY_PATH and CPATH, it should also set the environment variable LD_LIBRARY_PATH. LD_LIBRARY_PATH is not directly used by the compiler. Rather it is used at program start to find and load all shared libraries that the program needs. Check it with:

echo $LD_LIBRARY_PATH

If only LD_LIBRARY_PATH is wrong, the compilation will succeed, but when you start the compiled program, you may get "error while loading shared libraries".

Problems on Athene

Unfortunately, on FAU's Athene supercomputer some of these modules are broken in the sense that they do not set all required environment variables, so that one still may need to specify some -L and -I options anyway. For some libraries we can find out these options using pkg-config. E.g.

pkg-config --libs openblas
pkg-config --cflags openblas

should tell us the locations for openblas. When pkg-config works on Athene, we can even use

SPECIALLIBS += $(shell pkg-config --libs openblas)

directly in the MyConfig. But on Athene you never know if a module sets up the environment variables that pkg-config needs, so that pkg-config may fail as well.