The easiest way to install Dune is via binary packages. However, you may still have to build some parts of Dune from source, for a number of reasons:

• You need a recent feature that is not in a packaged release yet.
• You need one or more extension modules that do not exist in packaged form. Then you can mix a package-based installation of the modules that are packaged with an installation from source of the others.
• The program that you want to use the Dune libraries from may use any build system you like. However, it is convenient to set it up as yet another Dune module. Then, even if you have installed everything else from packages, you still need to follow the instructions on this page to build your own program.

Note: The process described below works for Linux/UNIX based systems. On Windows the easiest way to install Dune is to set up a Windows Subsystem for Linux (WSL). In that subsystem, Dune can be installed from binary packages or from source like on any other Linux system. See our WSL page for some additional hints.

Dependencies

In order to build DUNE you need at least the following software:

• The git version control system,
• A C++ compiler, e.g., g++ or clang,
• The CMake build system,
• pkg-config.
• For the Python bindings, you will need the Python headers and support for Python virtual environments. How to get them exactly depends on your distribution. On Debian-based systems it means installing the packages python3-dev and python3-venv.

Detailed information on supported compiler and CMake versions can be found in the release notes for releases and in the list of recent changes for the development branch.

The requirements listed above are the bare minimum. A number of features only get enabled if additional software is present. Some examples are

• MPI (e.g. OpenMPI or MPICH) for distributed grids,
• SuiteSparse for efficient direct sparse linear solvers,
• Doxygen for building documentation locally.

During the configuration process, each module prints a list of all optional dependencies. Consult this list for further software that may be of interest to you.

Getting the sources

First you need to download the DUNE core modules to your computer in one common directory. Create such a directory by

mkdir dune; cd dune

Then, either download tarballs of the last release of the core modules, or download directly from our git repositories:

git clone https://gitlab.dune-project.org/core/dune-common.git
git clone https://gitlab.dune-project.org/core/dune-geometry.git
git clone https://gitlab.dune-project.org/core/dune-localfunctions.git
git clone https://gitlab.dune-project.org/core/dune-istl.git
git clone https://gitlab.dune-project.org/core/dune-grid.git

While at it, you may also want to get the staging modules:

git clone https://gitlab.dune-project.org/staging/dune-typetree.git
git clone https://gitlab.dune-project.org/staging/dune-uggrid.git
git clone https://gitlab.dune-project.org/staging/dune-functions.git

Note: These commands give you the current development version of Dune. If you want a particular release, add the option

-b releases/<desired_release_number>

before the URL.

Building Dune

Building Dune means building the modules one by one, in a particular order. Each Dune module uses the CMake build system. In theory, you can build them all by hand, one after the other, but that is cumbersome. For user convenience, the dunecontrol utility determines the correct build order, and controls building of entire sets of modules. It can be found in the directory dune-common/bin/.

The easiest way to run dunecontrol is:

./dune-common/bin/dunecontrol all

in the directory that contains all the downloaded module source trees. This will configure and build all downloaded modules in the correct order. However, in most cases you will want to provide some options to the build process. For this, create a file called config.opts (or any other name of your choice) and call dunecontrol via

./dune-common/bin/dunecontrol --opts=config.opts all

The config.opts file contains the options passed to cmake for each module in a variable called CMAKE_FLAGS. For example,

CMAKE_FLAGS="-DCMAKE_BUILD_TYPE=Release
             -DBUILD_SHARED_LIBS=ON"

tells cmake to apply optimization, and to link Dune into shared libraries.

Note: Building Dune as shared libraries is crucial for the Python bindings. Without -DBUILD_SHARED_LIBS=ON, strange crashes can happen in particular situations.

By default, the Python bindings are built along with the rest of the code, but you can disable them by passing -DDUNE_ENABLE_PYTHONBINDINGS=NO.

More generally, dunecontrol can be used to perform other task on sets of Dune modules. For example

./dune-common/bin/dunecontrol [OPTIONS] cmake [CMAKE_FLAGS]

only calls cmake for each module (in the correct order), and

./dune-common/bin/dunecontrol [OPTIONS] make [MAKE_FLAGS]

does the same for make.

Automation

For convenience Peter Bastian maintains a set of helper scripts that automate the downloading and building of sets of Dune modules on Linux.

Building other Dune modules

Besides the core modules you can find lots of other Dune modules:

• Grid Modules
• Discretization Modules
• Extension Modules
• Tutorial Modules

If you want to use one of those modules make sure to download the module and all dependencies in the same common directory as the DUNE core modules. Building your modules is done in the same way as building the core modules by calling dunecontrol.

For further information on how to configure and build Dune modules please refer to the Build System documentation.