deal.II makes adaptive finite elements a CMake target, not a research project

What the library actually is

deal.II is a C++ program library aimed at the computational solution of partial differential equations using adaptive finite elements. Its stated contribution is not a new discretisation but the interface: modern programming techniques wrapped around the complex data structures and algorithms the method requires.

That framing explains why the project is shaped like a software product rather than a code drop. There is a CMake build, a packaging step, an install prefix, a Docker image, a regression test report, a performance test report, and continuous integration jobs covering serial, MPI, macOS, Windows and an Ampere machine, plus lint workflows for formatting and clang-tidy.

The topic list includes HPC and Kokkos, and the presence of both serial and MPI CI jobs means parallel configurations are tested continuously rather than treated as an experimental branch.

The audience is a computational scientist writing their own solver code in C++. The tutorial material exists, but it is framed as onboarding, not as the product.

The impatient build path, exactly as documented

The README gives a short path for people who already have a source tarball unpacked. From a fresh build directory:

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/path/where/dealii/should/be/installed/to /path/to/dealii/sources
make install
make test

make -j<N> install is offered as the parallel alternative. The documented sequence is to configure with CMake, install the library, and then run the tests.

From the repository instead of a tarball, the extra steps are only the clone and the directory change:

git clone https://github.com/dealii/dealii
cd dealii

after which you continue as before. There is no configure step distinct from CMake here, and no separate dependency manager. That is the modern packaging, and it is also where your first difficulty will land, because the dependency set is large and CMake will tell you what is missing.

A hundred tutorial steps instead of one example file

The tutorial lives under examples/ in the installation, as a sequence of step-N directories running from step-1 through step-100 and beyond in the listing. The directory names indicate a staged tutorial sequence.

The point of that design is that deal.II's difficulty is not the mathematics, it is the object model. A tutorial that walks a Poisson problem forward one concept at a time is teaching you how the library's data structures relate to each other: the triangulation, the degrees of freedom handling, the assembly, the solve, then the adaptivity loop that motivates the method in the first place.

Documentation is Doxygen based, with the tutorial index under doc/doxygen/tutorial/ in the source tree, and the developer readme lives at doc/readme.html with a user-focused CMake page at doc/users/cmake_user.html. All of it is also on dealii.org.

One practical debugging feature is worth knowing about early: deal.II ships support for pretty-printing its own objects inside GDB, configured through contrib/utilities/dotgdbinit.py. When a DoFHandler or cell iterator is not showing you what you expect, that file is usually the fastest path to seeing the structure.

Docker as the low-friction route on Ubuntu

Ubuntu based images are published on Docker Hub under dealii/dealii, with a range of tags. The README shows the pattern:

docker run --rm -t -i dealii/dealii:master-focal

That drops you into an isolated environment where the latest master development build is installed under /usr/local. For a project whose dependency graph is the main obstacle, this is the shortest path to a working compiler and library.

Two caveats. The example tag uses focal, so the images are tied to particular Ubuntu releases rather than a rolling latest, and choosing the wrong one gives you a system whose libraries do not match what you need elsewhere. And master-focal tracks the development branch, so an image built today is not the same as one built next month; if you need reproducibility, use a released version tag rather than the master build.

The image is for working, not for shipping. Anyone deploying a solver would build from source against the version they tested.

Continuous integration as the project's real documentation

The README's badge block is long, and it is more informative than it looks. Two badges point at regression test reports: one for the current state of the master branch and one for the previous state. Two more point at performance test reports. These are the closest thing deal.II offers to a public statement about whether the current commit is healthy.

Then there is Jenkins, with jobs for serial, MPI, macOS and an Ampere configuration. The README also lists a job labelled Ampere. GitHub Actions covers Linux, macOS and Windows, and separate workflows handle indentation and clang-tidy, with.clang-format and.clang-tidy in the repository root doing the configuring.

The badges show which platforms and checks have dedicated automation and where to inspect their results.

The repository also includes a pre-commit config, a typos configuration, a CODE_OF_CONDUCT file, a CONTRIBUTING guide and a SUPPORT file.

Licensing, versioning and the size of the commitment

The licence is not one GitHub recognises as a standard open source identifier, so the README defers to LICENSE.md and you should read it. A library that is neither clearly permissive nor clearly copyleft in the machine-readable sense deserves the actual text, not an inference.

Versioning is release based: v9.8.0 tagged on 2026-08-09, preceded by v9.8.0-rc1 on 2026-07-22 and v9.7.1 on 2025-09-14. The master branch was pushed on 2026-10-16, and the repository includes CHANGELOG.md and VERSION files. CITATION.cff records the citation metadata for academic use.

The size of the commitment is the thing to plan for. deal.II bundles some dependencies under bundled/ and configures others through the cmake/ directory, the header tree in include/ is large, and a full build includes compiling the library and running its tests. Anyone planning to use it should budget that time once, and should prefer a released version tag over master so the tutorial text they read matches the API they are compiling against.

Editorial conclusion

Adopt deal.II when you are writing adaptive finite element code in C++ and want the triangulation, DoFHandler and preconditioner machinery rather than a course example, and start from the step-N tutorial directories before writing anything from scratch. Do not adopt it for a one-off Poisson solve on a laptop that cannot spare the compile. Before building, decide between the source build and the dealii/dealii Docker image, keep the -DCMAKE_INSTALL_PREFIX you choose consistent, and read LICENSE.md yourself since GitHub cannot classify the licence as a standard one.

Frequently asked questions

Official sources

1. dealii/dealii on GitHub
2. Issues
3. Project website
4. README
5. Releases