What is DuMu^x?

DuMu^x is a simulation toolbox mainly aimed at flow and transport processes in porous media. DuMu^x is based on the DUNE framework and aims to provide a multitude of numerical models as well as flexible discretization methods for complex non-linear phenomena, such as CO2 sequestration, soil remediation, drug delivery in cancer therapy and more. Have a look at our publications (see below: How to cite) for a more detailed description of the goals and motivations behind DuMu^x.

Installation

Have a look at the installation guide or use the DuMu^x handbook, Chapter 2.

Automated testing of installation:

Documentation

The following resources are useful to get started with DuMu^x:

• Getting started guide on the DuMu^x website
• Handbook, a detailed DuMu^x manual,
• DuMu^x course materials,
• Examples, with detailed description of code and results,
• Class documentation generated from the source code,
• Mailing list,
• Changelog, where all changes between different release versions are listed and explained.

Some helpful code snippets are available in the Wiki.

License

DuMu^x is licensed under the terms and conditions of the GNU General Public License (GPL) version 3 or - at your option - any later version. The GPL can be read online or in the LICENSE.md file provided in the topmost directory of the DuMu^x source code tree.

Please note that DuMu^x' license, unlike DUNE's, does not feature a template exception to the GNU General Public License. This means that you must publish any source code which uses any of the DuMu^x header files if you want to redistribute your program to third parties. If this is unacceptable to you, please contact us for a commercial license.

See the file LICENSE.md for copying permissions. For a curated list of contributors see AUTHORS.md. If you notice that a contributor is missing on the list, please contact us or open a merge request adding the name.

How to cite

DuMu^x is research software and developed at research institutions. If you are using DuMu^x in scientific publications and in the academic context, please cite (at least one of) our publications:

• [Koch, T., Gläser, D., Weishaupt, K., Ackermann, S., Beck, M., Becker, B., Burbulla, S., Class, H., Coltman, E., Emmert, S., Fetzer, T., Grüninger, C., Heck, K., Hommel, J., Kurz, T., Lipp, M., Mohammadi, F., Scherrer, S., Schneider, M., Seitz, G., Stadler, L., Utz, M., Weinhardt, F. & Flemisch, B. (2021). DuMu^x 3 – an open-source simulator for solving flow and transport problems in porous media with a focus on model coupling. Computers & Mathematics with Applications, 81, 423-443. https://doi.org/10.1016/j.camwa.2020.02.012][7]

• [Flemisch, B., Darcis, M., Erbertseder, K., Faigle, B., Lauser, A., Mosthaf, K., Müthing, S., Nuske, P., Tatomir, A., Wolff, M., & Helmig, R. (2011). DuMu^x: DUNE for multi-{phase,component,scale,physics,…} flow and transport in porous media. Advances in Water Resources, 34(9), 1102–1112. https://doi.org/10.1016/j.advwatres.2011.03.007][2]

You can also cite specific releases published on Zenodo:

Automated Testing / Test suite

• Latest release (3.6):
• Master branch (development / unstable):

DuMu^x features many tests (some unit tests and test problems) that are continuously and automatically tested in the GitLab-CI framework (see badges). The test suite is based on CTest and can also be built and run manually

make -j8 build_tests && ctest -j8

The tests are labelled (see CMakeLists.txt of each individual test for its labels). You can build and run tests of a specific label (e.g. 2p for two-phase flow porous medium model tests) like this

make -j8 build_2p_tests && ctest -j8 -L ^2p$

Running individual tests

To find out how to build a test inspect the CMakeLists.txt file in the respective test folder.

The dumux_add_test command specifies some important parameters: NAME sets the name of the test. There is either SOURCES or TARGET specified. If SOURCES is specified NAME, corresponds to the build target, otherwise TARGET is the build target.

You can build the test by running make REPLACE_BY_NAME_OF_BUILD_TARGET (when using GNU Makefiles (default) this is possible within the test folder in the build directory, for ninja it has to be executed in the top-most build folder level).

Some tests may depend on additional optional dependencies. You can find this by inspecting the argument CMAKE_GUARD, e.g. HAVE_UMFPACK means UMFPack is required (via installing Suitesparse), or ( "dune-foamgrid_FOUND" AND "dune-alugrid_FOUND" ) means that the test requires the additional Dune modules dune-foamgrid and dune-alugrid. For installing external dependencies, have a look at the Handbook and the script dumux/bin/installexternal.py.

Test coverage

A weekly coverage report of the test suite is created by gcovr/gcov. The report currently doesn't include non-instantiated code, so the real coverage is likely lower. However, only a few lines of code are never instatiated in the comprehensive test suite.

Contributing

Contributions are highly welcome. Please ask questions over the mailing list. Please review the contribution guidelines before opening issues and merge requests.

Bug/issue reports or vulnerabilities

For bug reports or to report any detected security vulnerabilities contact us over the mailing list, or file an issue. For bug fixes, feature implementations open a merge request or send us formatted patches.

Releases and backwards compatibility policy

For a detailed description of the backwards compatibility policy, please see contribution guidelines.

DuMu^x releases are split into major (e.g. 2.0, 3.0) and minor (e.g. 3.1, 3.2, 3.3) releases. Major releases are not required to maintain backwards compatibility (see below), but would provide a detailed guide on how to update dependent modules. For each minor release, maintaining backwards compatibility is strongly encouraged and recommended.

Despite the goal of maintaining backwards compatibility across minor releases, for more complicated changes, this is decided upon on a case to case basis, due to limited developer resources. In the case that implementing full backwards compatibility for an update is not feasible, or would require unreasonable resources, the degree of backwards compatibility be decided by a vote in one of the monthly core developer meetings.