Users of Virginia Tech’s ARC computing clusters know that, if they want to find information about installed software, they only have to go to the main ARC webpage https://secure.hosting.vt.edu/www.arc.vt.edu/ , and then on the menu bar choose *RESOURCES* and from that menu select *SOFTWARE*. This produces an alphabetical list of the more than 250 installed software packages, including the locations and version numbers. But the package listed immediately after **lame** is **LBPMWIA**, and as more than one perplexed user has remarked, *“Where’s LAPACK?”*

Developers of scientific software are familiar with LAPACK as a fundamental building block, which supplies reliable algorithms for linear algebra tasks such as decomposition, factorization, linear system solutions, and eigenvalue analysis, for dense matrices in a variety of formats. LAPACK has been around so long, and is so useful, that many software packages simply include LAPACK as part of their distribution, or else expect to be able to link to a compiled version when the package is built. Users writing customized software also rely on being able to simply invoke LAPACK, rather than trying to write their own linear algebra functions. It seems then, that any computer cluster supporting scientific programming is in need of a copy of LAPACK, and yet, the standard reference copy of LAPACK, available from **netlib**, is not installed on any ARC cluster.

The explanation of this situation relies, in part, on the difference between *correctness* and *efficiency*. The LAPACK library was written well before parallel programming took its current form; it is written in a generic version of FORTRAN; it makes only very limited attempts to adjust to the particular computer it may be running on. It uses a small number of optimizations, such as unrolling and blocking, whereas many new techniques have since become available for improving memory accesses and reordering operations for maximum speed. For these reasons, the version of LAPACK available from **netlib** is best regarded as a *reference code*, which demonstrates a working, correct implementation of the linear algebra algorithms, but which is not heavily optimized for any particular computer architecture or programming scheme.

Since efficency and ease of use are important, this means that various “flavors” of LAPACK have been developed, to make the power of the package available, while adding some desirable features. And while the “vanilla” version of LAPACK is not visible on ARC systems, a number of these modified versions are, in fact, available to our users, although “hidden” under other names or within other libraries.

Some of these versions primarily address the language issue. For many users, the FORTRAN language is an obstacle; an early project created **CLAPACK**, a translation of the entire LAPACK library into C. The Python library **SCIPY** also includes a Pythonic interface to LAPACK functions.

Other versions of LAPACK take good performance as their highest concern. One might begin by looking at the **ATLAS** library, which includes a full set of LAPACK functions, “automatically tuned” for best performance. If a user is willing to use the Intel family of compilers, then the **MKL** library is available. Both ATLAS and MKL can be used with C, C++ or FORTRAN programs.

Any user can simply retrieve the source code for BLAS and LAPACK from netlib, and include it in their computational source code. We make CLAPACK and SCIPY/ANACONDA versions of LAPACK available, but we especially urge users to investigate ATLAS and MKL, which are easy to access..

Thus, the answer to “Where’s LAPACK?” is a little more complicated than you might have expected, but we hope that the choices made available on the ARC systems give you a pathway to efficient and optimized computation.