DOLFINx, the C++ and Python core of the FEniCSx finite element stack

What DOLFINx actually is in the FEniCSx stack

DOLFINx is described as the computational environment of FEniCSx and as the implementation of the FEniCS Problem Solving Environment in C++ and Python. It is a new version of DOLFIN and the documentation states that it is actively developed, with the last push to the repository on 2026-10-19. The problem solving environment is the layer where a finite element formulation becomes a discretisation and then a solved system: meshes, function spaces, forms, assembly, boundary conditions, and a linear or nonlinear solve handed to an external solver. The repository layout reflects that split. There is a `cpp/` directory holding the compiled core and a `python/` directory holding the interface, and the two are built and installed separately, which is the first structural fact a new user has to absorb. The primary language is C++, and the project also keeps a `docker/` directory, an `AGENTS.md`, a `CITATION.cff`, a `RELEASE.md` and a `ChangeLog.rst` at the root. The licence is LGPL-3.0, with both `COPYING` and `COPYING.LESSER` present, which matters because a solver library is normally linked into other software.

Building the C++ core and the Python interface separately

The source build is a two-stage procedure and the documentation is explicit that the Python interface needs the C++ core installed first. The core is built with CMake in its own directory, and the Python side is then installed with pip from the `python/` directory, using a pip group flag for the build dependencies and a no-build-isolation install. The reason for the unusual incantation is that the Python package compiles against the just-built core, so the build has to see the same environment the C++ install produced.

mkdir build
cd build
cmake ..
make install

pip install --group pyproject.toml:build
pip install --check-build-dependencies --no-build-isolation .

For anyone not on a Linux cluster, the first step of the journey is usually finding the dependency list, which the documentation points to rather than inlining.

Spack, and why HPC users get a different recommendation

Spack is the recommended approach for high performance computers, and the reason is the same reason the source build exists: a cluster needs control over compiler, MPI and library versions, and Spack manages that as an environment rather than as system packages. The documented flow clones Spack, sources its setup script, creates and activates an environment, and installs the `py-fenics-dolfinx` package with the `petsc4py` and `slepc4py` variants enabled. The project also maintains a separate Spack overlay repository, and the stated reason is that it may carry bug fixes and package specs for newer releases of the FEniCS components, particularly right after a release. Users are told to add it as a repository and list the repositories to confirm it appears above the builtin ones. The binary package recommendations follow the same logic of matching the platform: Spack or a source build for HPC systems, both using the system-provided MPI.

conda, apt and the one package that does not exist on Windows

The binary package story is where the platform differences get sharp. macOS is directed to conda, and Linux has several routes: the Ubuntu PPA, Docker, conda, and Spack. The Ubuntu route adds a PPA, updates the package lists and installs `fenicsx`, and the project aims to provide a package for the most recent Ubuntu LTS when a version is released, with other versions handled on a best-effort basis. Debian ships the project under `fenicsx` and it can be installed with apt-get. The conda environment creates a `fenicsx-env`, activates it, and installs `fenics-dolfinx` together with `mpich` and `pyvista` on Linux and macOS, and with `pyvista` and `pyamg` on Windows. That last line hides the real Windows story, which the documentation spells out separately: the Windows conda packages are in beta testing, PETSc and petsc4py are not available on Windows, and because FEniCS relies on just-in-time compilation, Microsoft Visual Studio has to be installed. On Windows the recommendation is therefore Docker, or WSL2 with Ubuntu.

Docker images, and switching between real and complex builds

The container images cover the range from a running environment to a full build environment. The stable image runs the latest release, the nightly image runs a build from the previous night, and the lab image is a Jupyter Lab environment published on port 8888. Two development images go further: `dev-env:stable` carries all the dependencies needed to build the latest release of the FEniCSx components, and `dev-env:current` does the same for the main branch. The images support both arm64 and amd64 architectures, and versioned tags are listed on Docker Hub. The detail worth knowing about is how the arithmetic type is chosen. The images ship scripts that switch the build between real and complex, and because a finite element problem may need complex numbers while the default is real, the same image covers both cases with an explicit source call rather than a rebuild.

A release train with post releases

The release history shows a version scheme that includes post releases, which is a signal about how the project manages packaging rather than about features. The recent tags are v0.11.0.post0 on 2026-06-10, v0.11.0 on 2026-06-09 and v0.10.0.post5 on 2025-12-17. A post release is what gets built when a source release needs repackaging, and the presence of several of them means the project expects packaging fixes to be needed after each version. The consequence for users is that the version you get from conda, apt or Docker may not correspond exactly to the tag you see in the repository, and that a source checkout and a binary package can differ in small ways. The version numbers are still pre-1.0, which is an honest signal from a project whose API surface has changed between releases. The `RELEASE.md` and `ChangeLog.rst` files at the root, along with the `CITATION.cff` for academic citation, suggest a project that expects to be cited and that keeps its release process documented.

Where the difficulty actually lives

The interface is not the hard part of this project. The hard part is that a solve touches PETSc for the linear and nonlinear algebra, MPI for parallelism, SLEPc for the eigenvalue problems, and a just-in-time compilation layer for the forms you write, and a mismatch anywhere in that chain produces a failure that says nothing helpful about the cause. The dependency list is where that shows up: the Windows note about Visual Studio exists because of just-in-time compilation, the SLEPc variants in the Spack command exist because eigenproblems need them, and the real and complex switch exists because the arithmetic type of the build has to match the problem. The project also lists a FEniCS Discourse forum and a Slack channel as the places to ask questions, which is a fair signal about where a real user ends up when the build breaks. Two facts are worth checking against your own setup before you start: the documentation covers installation in depth but says nothing about a rollback path, and the repository has no statement about which upstream solver versions are supported beyond the ones named in the Spack variants.

Editorial conclusion

Adopt DOLFINx if your work is finite element solution of partial differential equations and you need parallel solvers with PETSc rather than a prototype environment, and skip it if you want a quick linear or nonlinear solve, because the dependency chain is heavy. Verify three things before you install: which deployment you are on, since a Linux workstation with conda is a different exercise from an HPC cluster with Spack and a system MPI; that your MPI and PETSc versions match, since the real and complex builds are switched explicitly in the Docker images; and that the platform is one the project supports properly, because the Windows conda packages are in beta testing and PETSc and petsc4py are not available there.

Frequently asked questions

Official sources

1. FEniCS/dolfinx on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases