Elemental: a distributed-memory C++ linear algebra library frozen since 2016

Elemental's own notice points readers to a fork, not to a roadmap

The first thing in the project documentation is a deprecation notice, and it is unusually blunt. It says Elemental has not been maintained since 2016, that the project was forked by Lawrence Livermore National Lab, and that the original author stopped volunteering on MPI codes with nobody stepping up after three years. The document then makes an argument about funding rather than roadmap, pointing readers to hodgestar.com where the developer now volunteers on high-performance math software for workstations.

That context changes how the repository should be read. The code is not a product with a support window. It is a snapshot of a research framework, plus a live upstream fork that carries the same design in a different home. The recent release list mixes eras: v0.88.0 on 2026-03-04 sits above v0.87.7 from 2017-02-07 and v0.87.6 from 2016-12-17. The last push on this repository was on 2026-10-15, on the master branch, which tells you files still move, but it does not tell you that the 2016 feature set grew.

So the useful reader here is an engineer who wants the algorithms and the design, not a team looking for a dependency with a support contract.

The data model is distributed matrices, and it is mid-refactor

The core abstraction is a distributed matrix type. The documentation names DistMatrix as the structure that is being extended, and DistMultiVec as the older type the roadmap intends to eliminate in favour of it. That single line, item 1a on the roadmap, tells you the type system is in flux: vector and matrix operations are being consolidated under one distributed container.

The second roadmap item, 1b, is to extend DistSparseMatrix to support elementwise and blockwise 2D distributions. This is not a minor feature. Everything above it in the plan depends on it: sparse scalability work (3b) explicitly depends on 1b, and the distributed sparse semidefinite work (3c) depends on 3b. The planning therefore acknowledges that the sparse side is the weak point of the library, and that the dense side is what the type system is being reorganised around.

Beyond that, the library covers a wide band of dense work: least squares and Tikhonov regression, column-pivoted QR, LU and Cholesky with full pivoting, Hermitian matrix functions, sign-based Lyapunov and Sylvester solvers, and arbitrary-precision distributed SVD and eigenproblems. A separate note marks aggressive early deflation Schur decompositions as currently sequential only, so even in the dense area some routines do not exploit the distributed setup.

Number types range from float to MPFR-backed BigFloat

One of the more unusual choices in Elemental is the range of scalar types treated as first class. The documentation lists float and double, their complex counterparts, and then a stack of extended precision types: El::DoubleDouble and El::QuadDouble built on QD's dd_real and qd_real, El::Quad on GCC's __float128, and El::BigFloat on top of MPFR's mpfr_t and MPC's mpc_t. Every one of these has a matching complex variant.

This is what lets the library advertise arbitrary-precision distributed SVD, generalized Hermitian eigenproblems and Schur decompositions as ordinary features rather than research spins. The cost is that the arithmetic paths multiply, so an application pays in build complexity and compile time for the precision it selects. It also means the dependency footprint is not trivial: QD and MPFR are external, and the LGPL-licensed libquadmath enters the picture when the __float128 path is used.

For most users, that trade-off is not worth making. The interesting part of Elemental for a modern reader is less the extended precision and more the distributed algorithm layer built on top of it.

Convex optimization support exists, but sparse interior point scaling is called out as missing

The optimization component covers dense and sparse interior point methods for linear, quadratic and second-order cone programs, with named applications including Basis Pursuit, Dantzig selectors, LASSO and basis pursuit denoising, least absolute value regression, non-negative least squares, support vector machines and one-dimensional total variation.

There is also a Jordan algebra layer over products of second-order cones, prototype dense alternating direction method of multipliers routines for sparse inverse covariance selection and for principal component analysis of data with outliers, and a prototype alternating direction non-negative matrix factorization routine. The honest word in that list is prototype, and it applies to the ADMM and NMF pieces.

The important caveat is stated plainly in the documentation: scalability for sparse interior point methods will be lacking until more general sparse matrix distributions are introduced into Elemental. That ties the optimizer back to roadmap item 1b. In other words, the solver layer and the sparse data model are the same limitation seen from two angles. If your problem is a large sparse cone program, this library, in its current documented state, is not the tool that solves it.

Lattice reduction and number theory live in the sequential part of the library

The third domain is lattice reduction, listed alongside the other functionality Elemental absorbed and expanded after releasing its dense linear algebra framework. The list includes an extension of Householder-based LLL to real and complex linearly dependent bases, generalizations of BKZ 2.0 to complex bases incorporating y-sparse enumeration, and integer image and kernel computation with relation finding. All three are marked as currently sequential only, which means the distributed machinery is not what makes them work.

This is a real limitation for anyone who assumes the whole library scales. It also explains the split in the repository: the examples directory separates blas_like, core, interface, io, lapack_like, matrices, number_theory and optimization, and the last two carry the parts that are not the distributed linear algebra core.

The Clique connection matters for provenance. Elemental started as a framework for distributed memory dense linear algebra, published as a paper in the ACM literature, and then absorbed the functionality of Clique, which itself came out of work on parallel sweeping preconditioners.

Building Elemental means assembling BLAS, LAPACK and a custom license set

The documentation does not give a copy-and-paste install recipe, and there is no package-manager shortcut described anywhere in it. What it does give is the dependency list and the repository layout: a CMakeLists.txt at the root with a cmake directory, plus include and src trees, an external directory for vendored or fetched dependencies, and packaging directories named debian, redhat, vagrant and package_example. The internal dependency list starts with BLAS and LAPACK, with libflame listed as optional for faster bidiagonal SVDs.

The licensing is the messier part. The vast majority of Elemental is distributed under the New BSD License, and the documentation points to debian/copyright for a per-file overview. The optional METIS dependency is under Apache License 2.0, but ParMETIS can only be used for research purposes and can be easily disabled. libquadmath is under LGPL 2.1 or later, and QD carries the LBNL-BSD license. The repository's own LICENSE file is a custom license that GitHub cannot classify, which is a reason to read it and debian/copyright directly rather than trust a license badge.

Nothing here is legal advice, but the practical point is that enabling METIS, ParMETIS or the extended precision paths changes the license obligations of a derived binary, and a ParMETIS-enabled build carries a research-use restriction.

What a current alternative looks like from the same starting point

The clearest comparison available is the fork itself. The Lawrence Livermore fork exists because the author stopped volunteering, and it carries the same design forward under different maintainership. Anyone evaluating Elemental today is therefore choosing between this archive and that fork, and the practical difference is who answers issues, not which algorithm runs.

A second comparison is architectural rather than organisational. Elemental's distributed model depends on a sparse matrix type that, by the roadmap's own admission, lacks elementwise and blockwise 2D distributions. A dense-oriented stack built on BLAS and LAPACK, which Elemental already depends on, sidesteps that problem entirely by keeping everything in one process. For dense factorizations on a single node, that is simpler and often the better answer, and it is the direction the project itself points when it says the author now works on workstation-oriented high-performance math software.

For sparse direct work, the comparison goes back to Clique, whose functionality Elemental absorbed, and to newer sparse solvers that were designed around modern sparse distribution models from the start. Elemental's advantage is a unified dense, sparse, optimization and number theory surface in one C++ API. Its disadvantage is that the unified surface is only as good as its sparsest part.

What to verify before you build on this code

Several checks are cheap and worth doing before anything else. First, decide which copy you will use, because the fork at the Lawrence Livermore repository is the one that moved forward, and this repository's own documentation points there. Second, read the LICENSE file and debian/copyright rather than the license label, since the top-level license is custom and the per-file breakdown lives elsewhere.

Third, look at the DistSparseMatrix distribution support in the copy you plan to build, because roadmap item 1b is what gates sparse interior point scalability, sparse semidefinite work and the low edge-degree plus low-rank sparse improvements. If your work is dense, that item matters less. If it is sparse, it decides whether the library is usable at all.

Fourth, read the type list and pick the scalar type on purpose. El::BigFloat pulls in MPFR and MPC, El::Quad depends on GCC's __float128 and libquadmath, and the double-double and quad-double types depend on QD. Each adds build weight. Fifth, note that the documentation site is described as outdated, so the code is the reference, and that the archive includes an examples tree, a tests tree, an octave directory and a python directory that show intended usage patterns even where the prose is thin.

Editorial conclusion

Read Elemental if you are studying how a distributed-memory linear algebra library was put together, if you already depend on its API and need a reference implementation, or if you are working on code that LLNL now maintains separately. Do not adopt it as the foundation of a new numerical project, because the archive documentation is described as outdated, the sparse interior point methods are documented as lacking scalability, and the lattice reduction extensions are marked sequential only. Before relying on it, confirm that the fork you will actually build against still carries the pieces you need, check the license of each external dependency you enable, and read the roadmap items DistMultiVec removal and DistSparseMatrix 2D distributions, since the sparse data model is the part most likely to block new work.

Frequently asked questions

Official sources

1. elemental/Elemental on GitHub
2. Issues
3. README
4. Releases