It is still under construction and content may change. Do not rely on the information on this page.
Introduction
Besides being implementations, BLAS and LAPACK are also API standards for basic linear algebra operations (such as vector and matrix multiplication).
Many implementations of these API exist. The reference implementation of BLAS and LAPACK from netlib is very stable but is not as fast as optimized ones such as ATLAS and OpenBLAS.
Implementations of BLAS:
- blas - Reference implementation from netlib
- atlas - Automatically Tuned Linear Algebra Software
- openblas - OpenBLAS, an optimized BLAS based on GotoBLAS2
Implementations of LAPACK:
- lapack - Reference implementation from netlib
- ATLAS and OpenBLAS both provide an optimized subset of LAPACK
Due to implementation differences, it is important that all components of a particular software stack link to the same BLAS/LAPACK implementation. Also, users may want to choose a particular implementation that works best for them at run time. This guideline gives a structure that can enforce the first while allowing the second.
BLAS/LAPACK implementations
Implementations of a BLAS and/or LAPACK library will provide relative symbolic links in %{_libdir}/IMPLEMENTATION-NAME/ of libblas.so.3 and/or liblapack.so.3 as appropriate pointing to the actual implementation library. Each implementation may have multiple IMPLEMENTATION-NAMEs, e.g. for serial and parallel versions.
For example, atlas would do:
%install
...
ln -s ../libsatlas.so.3 %{buildroot}%{_libdir}/atlas-serial/libblas.so.3
ln -s ../libsatlas.so.3 %{buildroot}%{_libdir}/atlas-serial/liblapack.so.3
ln -s ../libtatlas.so.3 %{buildroot}%{_libdir}/atlas-threaded/libblas.so.3
ln -s ../libtatlas.so.3 %{buildroot}%{_libdir}/atlas-threaded/liblapack.so.3
If ILP64 (64-bit integer) implementations are available, they should be provided as well. For openblas:
%install
...
ln -s ../libopenblas64.so.0 %{buildroot}%{_libdir}/openblas-serial/libblas64.so.3
ln -s ../libopenblas64.so.0 %{buildroot}%{_libdir}/openblas-serial/liblapack64.so.3
ln -s ../libopenblas64_.so.0 %{buildroot}%{_libdir}/openblas-serial/libblas64_.so.3
ln -s ../libopenblas64_.so.0 %{buildroot}%{_libdir}/openblas-serial/liblapack64_.so.3
For each IMPLEMENTATION-NAME, the implementation package will provide an environment module, e.g.:
#%Module 1.0 # ATLAS module for loading serial atlas library conflict blas prepend-path LD_LIBRARY_PATH /usr/lib64/atlas-serial
as %{_datadir}/modulefiles/blas/atlas-serial. The implementation must then require an environment module implementation:
Requires: environment(modules)
Because many (all except the reference?) BLAS/LAPACK implementations are combined BLAS/LAPACK libraries, we do not support separate specification of BLAS and LAPACK, only combinations that are explicitly known to work.
BLAS/LAPACK dependent packages
Generic Usage
If the BLAS/LAPACK consumer does not require special compile time configuration for different BLAS/LAPACK implementations, it should simply build against the reference implementation:
BuildRequires: blas-devel BuildRequires: lapack-devel
so that they end up linking to libblas.so.3 and liblapack.so.3, thus allowing the implementation to be switched at run time.
Compile time configuration
If the consumer requires special configuration for different implementations, it should provide versions compiled with each implementation.
End-User Documentation
End users will load the implementation they desire with:
module load blas/IMPLEMENTATION-NAME
TODO - choose a distribution default?