Skip to content
Snippets Groups Projects
Commit a7adaae5 authored by Timo Koch's avatar Timo Koch
Browse files

Merge branch 'cleanup/finalize-changelog' into 'master' 

finalize CHANGELOG.md for 3.0

See merge request !1468
parents 627d394a 407db709
No related branches found
No related tags found
1 merge request!1468finalize CHANGELOG.md for 3.0
Hide whitespace changes
Inline Side-by-side
Showing
with 131 additions and 120 deletions
CHANGELOG.md
+ 131
− 120
View file @ a7adaae5
Differences Between DuMuX 2.12 and DuMuX 3.0 Differences Between DuMuX 2.12 and DuMuX 3.0
============================================= =============================================
* __IMPORTANT NOTES:__ ## Important Notes
- DuMuX 3.0 is a major version update. Hence, it is not backward compatible in all aspect to 2.12.
The following minor version updated will be, as before for the DuMuX 2-series, always backward compatible - DuMuX 3.0 is a major version update. It is not backward compatible in all aspects to 2.12.
The following minor version updates will be, as before for the DuMuX 2-series, always backward compatible
to at least the last minor version update. to at least the last minor version update.
- DuMuX 3.0 is based on Dune 2.6 and is expected to run with the current Dune master. - The tutorial has been replaced by the new module `dumux-course` which is
We will try to keep the compatibility with the Dune master accessible at https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course.
as long as it is technically feasible and our resources allow it. We recommend new users and also users experienced with DuMuX 2.X to clone
the course and have a look at the exercises in there.
- DuMux 3.0 requires at least GCC 4.9 or Clang 3.5 in their C++-14 mode.
However, we suggest to use newer compiler versions, as we cannot test against all previous compiler versions. - DuMuX 3.0 is based on Dune 2.6 and is expected to run with the current Dune master.
We will try to keep the compatibility with the Dune master
- For employing corner-point grids by means of opm-grid, the OPM release 2018.04 has to be used. as long as it is technically feasible and our resources allow it.
* __IMPROVEMENTS and ENHANCEMENTS:__ - DuMuX 3.0 requires at least GCC 4.9 or Clang 3.5 in their C++-14 mode.
- Support for grid managers dune-subgrid (a meta grid selecting only certain elements from a host grid) However, we suggest to use newer compiler versions, as we cannot test against all previous compiler versions.
and dune-spgrid (a structured parallel grid manager, supporting periodic boundaries)
- __New style main files:__ 3.0 comes which a major overhaul of how the sequence of simulation steps is specified. - For employing corner-point grids by means of opm-grid, the OPM release 2018.10 has to be used.
Until 2.12 there was the start.hh header including the free function `start` that contained a predefined sequence of
steps. Customization of the sequence was possible by many hooks implemented in classes used in this sequence. This ## Improvements and Enhancements
made it hard to follow the course of the program and hard to implement customization at points where this was not previously envisioned.
In contrast, in the new approach the sequence of simulation steps was linearized, meaning that each step is visible ### General
in the program's main file. In the new main files, one can clearly see the io, initialization, assembly, solving, update, time loop, etc.,
of the program. Many parts of the simulation that were previously mandatory, i.e. simulations in 2.12 always contained a time loop, - __New style main files:__ 3.0 comes which a major overhaul of how the sequence of simulation steps is specified.
are now optional (instationary simulations just don't need a time loop). The new style main files make it easier two follow the course Until 2.12 there was the start.hh header including the free function `start` that contained a predefined sequence of
of the program, easier to customize, and offer more flexibility concerning the customization of steps and components of a simulation. steps. Customization of the sequence was possible by many hooks implemented in classes used in this sequence. This
All tests and examples in the dumux repository have been adapted to the new style main files. made it hard to follow the course of the program and hard to implement customization at points where this was not previously envisioned.
- __The grid geometry concept:__ In version 3.0, discretization methods use grid geometries which are wrapper or adapters around a `Dune::GridView`, In contrast, in the new approach the sequence of simulation steps was linearized, meaning that each step is visible
providing data structures and interfaces necessary to implement these discretization methods easily. In particular, the in the program's main file. In the new main files, one can clearly see the io, initialization, assembly, solving, update, time loop, etc.,
abstraction of sub-control-volumes (scv) and sub-control-volume-faces (scvf) are now separate classes and the grid geometry provides means to iterate of the program. Many parts of the simulation that were previously mandatory, i.e. simulations in 2.12 always contained a time loop,
over all scvs and scvfs of an element, using range-based-for loops. are now optional (stationary simulations just don't need a time loop). The new style main files make it easier two follow the course
- __The caching concept:__ Version 3.0 introduces a caching concept for the new grid geometry, the volume variables and the flux variables. of the program, are easier to customize, and offer more flexibility concerning the customization of steps and components of a simulation.
There are classes with a `Grid` prefix, that store data for the current grid view, and classes with the `Element` prefix that store data locally All tests and examples in the dumux repository have been adapted to the new style main files.
for an element or element stencil. Depending on the caching concept used, data will be either stored completely in the `Grid` objects - __Property system:__ The property system is now usable without preprocessor macros. To this end it was completely reimplemented using C++14 techniques and
(e.g. `GridGeometry`) and the `Element` object (e.g. `ElementGeometry`) are mere accessor objects, or, data will be partly only cached locally. variadic templates. The hierarchies can now be arbitrarily deep instead of being limited to 5 levels. The new implementation does not use
The local caching uses less memory but might result in a more runtime, the grid caching is memory intensive C++ inheritance. Properties and TypeTag now have to be properly qualified with the namespaces `Properties::`, `TTag::`. Types that share the
but can provide a significant run-time speedup. Choose whatever concept fits your available resources. name with properties have to properly qualified with the `Dumux::` namespace. This update makes it hopefully more readable
- __MPFA schemes:__ The new design of the DuMux core facilitates the incorporation of new finite-volume schemes. In particular, the new core comes with and removes the "magic" part from the property system.
a framework for MPFA schemes, in which currently the only available scheme is the MPFA-O scheme. It can be used in conjunction with any DuMux model and - __Runtime parameters:__ Runtime parameters are no longer accessed with preprocessor macros. They have been replaced by C++ function templates
also works on surface grids. More schemes will be added in the future. `Dumux::getParam`, `Dumux::hasParam`, `Dumux::getParamFromGroup`. The `..FromGroup` version has been redesigned to allow the specification
- __Interface solver:__ For the two-phase flow model in conjunction with the box scheme, an interface solver can now be used to reconstruct the saturations of parameters for different models in one input file. The concept of a parameter group string was extended to make it possible to
in the sub-control volumes adjacent to vertices that lie on material discontinuities. This allows a sharper representation of the saturation front evolving use a single input file for complex multidomain simulation setups.
in heterogeneous porous media. - __Restarting simulations:__ The old restart module was replaced by an implementation based on a VTK backend (other formats might be added later such as HDF5).
- __Box-dfm:__ The `2pdfm` model from version 2.12 has been generalized such that it can be used on any DuMux model and in both two and three dimensions. Restarted simulations can read solutions from vtk files. For parallel runs, there is currently the restriction that the number of processors has to be the same
- __MPNC:__ The general m-phase n-component model has been adapted in structure to the other porous medium flow models. as before the restart. Restarted simulations can read grids from vtk (currently only sequential, non-adaptive grids, support for parallel and adaptive
- __Tracer transport__: A new model for tracer transport with a given flow field has been added. The model can be also used to implement sequentially will be added in a future version).
coupled simulations, or iterative solvers where flow and transport are decoupled / weakly coupled. - __Assembly__: The assembler can now assemble implicit and explicit Euler time discretizations. An interface for implementing analytical Jacobians was added.
- __Mineralization__: An adapter model for mineralization has been added and can be used with all porousmediumflow models. A balance for the solid The CCTpfa assembler has been significantly improved for complex models that spend a lot of time computing constitutive laws. Also the numerical
volume fraction of precipitating, adsorbed, or absorbed substances is added to the existing equations. differentiation scheme was improved by altering the order in which derivatives are computed.
- __Multidomain:__ DuMux 3.0 introduces a new multidomain framework which does no longer depend on `dune-multidomain` and can be used for the coupling - __TypeTag templates:__ Implementers of code in DuMuX 3.0 are advised to avoid TypeTag as a template argument for class templates.
of an arbitrary number of subdomains. The sub-domains can be regions in which a different set of equations are solved and/or which have different Many classes in the DuMuX core have been changed to have a small number of specific template arguments, including `GridGeometry`,
dimensionalities. The implementation is such that any of the existing DuMux models can be used in the subdomains, while the data and functionality `TimeLoop`, `Newton`, `LinearSolver`, `SpatialParams`. This makes it possible to share objects of these types between models using
required for the coupling of the sub-domains is implemented in a `CouplingManger` class. Three different coupling concepts are available, for which different TypeTags. This was not possible before as `Class<TypeTag1>` and `Class<TypeTag2>` are different types, even if they contain
there are a number of available `CouplingManager` class implementations: exactly the same implementation code.
- _Boundary:_ coupling across sub-domain boundaries Furthermore, having TypeTag as a template argument leads to bad programming, and unnecessary dependencies that should be avoided in
- _Embedded:_ Coupling between a bulk domain and an embedded lower-dimensional sub-domain which has an independent grid every object-oriented code.
- _Facet:_ Coupling betweeen a bulk domain and a codimension-one sub-domain, which is conforming with the element facets of the bulk domain - __The grid geometry concept:__ In version 3.0, discretization methods use grid geometries which are wrappers or adapters around a `Dune::GridView`,
- __Free-flow models:__ The previous Navier-Stokes model using the box method has been replaced by one that employs a staggered grid discretization. providing data structures and interfaces necessary to implement these discretization methods easily. In particular, the
The latter does not require any stabilization techniques while those were necessary for the box method in order to avoid spurious oscillations. abstraction of sub-control-volumes (scv) and sub-control-volume-faces (scvf) are now separate classes and the grid geometry provides means to iterate
The free-flow models in DuMux 3.0 consider single phase flow with or without component/energy transport. So far, only regular cartesian grids are supported over all scvs and scvfs of an element, using range-based-for loops.
but local grid refinement will be added in a future release. - __The caching concept:__ Version 3.0 introduces a caching concept for the new grid geometry, the volume variables and the flux variables.
Several RANS models for turbulent flow have been added: k-omega, k-epsilon, low-Re-k-epsilon, one-eq, zero-eq. The RANS models might be subject to further (interface) There are classes with a `Grid` prefix, that store data for the current grid view, and classes with the `Element` prefix that store data locally
changes. for an element or element stencil. Depending on the caching concept used, data will be either stored completely in the `Grid` objects
- __Runtime parameters:__ Runtime parameters are no longer accessed with preprocessor macros. They have been replaced by C++ function templates (e.g. `GridGeometry`) and the `Element` objects (e.g. `ElementGeometry`) are mere accessor objects, or, data will be partly only cached locally.
`Dumux::getParam`, `Dumux::hasParam`, `Dumux::getParamFromGroup`. The `..FromGroup` version has been redesigned to allow the specification Local caching uses less memory but might result in an increased runtime. Grid caching is memory intensive
of parameters for different models in one input file. The concept of a parameter group string was extended to make it possible to but can provide a significant run-time speedup. Choose whatever concept fits your available resources,
use a single input file for complex multidomain simulation setups. the default being local caching.
- __Property system:__ The property system is now usable without preprocessor macros. To this end it was completely reimplemented using C++14 techniques and - __Support__ for grid managers `dune-subgrid` (a meta grid selecting only certain elements from a host grid)
variadic templates. The hierarchies can now be arbitrarily deep instead of being limited to 5 levels. The new implementation does not use and `dune-spgrid` (a structured parallel grid manager, supporting periodic boundaries).
C++ inheritance. Properties and TypeTag now have to be properly qualified with the namespaces `Properties::`, `TTag::`. Types that share the
name with properties have to properly qualified with the `Dumux::` namespace. This update makes it hopefully more readable ### Models, Physics and Methods
and removes the "magic" part from the property system.
- __TypeTag templates:__ Implementers of code in DuMuX 3.0 are advised to avoid TypeTag as a template argument for class templates. - __MPFA schemes:__ The new design of the DuMuX core facilitates the incorporation of new finite-volume schemes. In particular, the new core comes with
Many classes in the DuMuX core have been changed to have a small number of specific template arguments, including `GridGeometry`, a framework for MPFA schemes, in which currently the only available scheme is the MPFA-O scheme. It can be used in conjunction with any DuMuX model and
`TimeLoop`, `Newton`, `LinearSolver`, `SpatialParams`. This makes it possible to share objects of these types between models using also works on surface grids. More schemes will be added in the future.
different TypeTags. This was not possible before as `Class<TypeTag1>` and `Class<TypeTag2>` are different types, even if they contain - __Box-dfm:__ The `2pdfm` model from version 2.12 has been generalized such that it can be used on any DuMuX model and in both two and three dimensions.
exactly the implementation code otherwise. - __Tracer transport__: A new model for tracer transport with a given flow field has been added. The model can be also used to implement sequentially
Furthermore, having TypeTag as a template argument leads to bad programming, and unnecessary dependencies that should be avoided in coupled simulations, or iterative solvers where flow and transport are decoupled / weakly coupled.
every object-oriented code. - __Mineralization__: An adapter model for mineralization has been added and can be used with all porousmediumflow models. A balance for the solid
- __Restarting simulations:__ The old restart module was replaced by an implementation based on a VTK backend (other formats might be added later such as HDF5). volume fraction of precipitating, adsorbed, or absorbed substances is added to the existing equations.
Restarted simulations can read solutions from vtk files. In parallel, there is currently the restriction that the number of processors has be the same - __Solution-dependent spatial params:__ A redesign of the spatial params interface allows now to define spatial parameters such as permeability
as before the restart. Restarted simulations can read grids from vtk (currently only sequential, non-adaptive grids, support for parallel and adaptive and porosity that depend on the solution. This makes it easier to implement mineralization models altering the solid structure of the porous medium.
will be added in future version). - __Solid systems:__ DuMuX 3.0 introduces solid systems similar to fluid systems but for solid components. This allows a consistent
- __Components:__ Components can now derive from different base classes, `Base`, `Liquid`, `Solid`, `Gas`, depending on which implementation of mineralization models including reactions, dissolution, precipitation and other processes altering the solid
phase states are implemented. This can be used to determine at compile time if a component support a certain phase state. phase of the porous medium.
- __Solid systems:__ DuMuX 3.0 introduces solid systems similar to fluid systems but for solid components. This allows a consistent - __Multidomain:__ DuMuX 3.0 introduces a new multidomain framework which does no longer depend on `dune-multidomain` and can be used for the coupling
implementation of mineralization models including reactions, dissolution, precipitation and other processes altering the solid of an arbitrary number of subdomains. The sub-domains can be regions in which different sets of equations are solved and/or which have different
phase of the porous medium. dimensionalities. The implementation is such that any of the existing DuMuX models can be used in the subdomains, while the data and functionality
- __Tabulation of fluid parameter laws:__ The tabulation of fluid parameter laws has been improved to only tabulate those functions actually used during the required for the coupling of the sub-domains is implemented in a `CouplingManger` class. Three different coupling concepts are available, for which
simulation. To this end, the tabulation is done on the first call of certain fluid parameter. there are a number of available `CouplingManager` class implementations:
- __Assembly__: The assembler can now assemble implicit and explicit Euler time discretizations. An interface for implementing analytical Jacobians was added. - _Boundary:_ coupling across sub-domain boundaries
The CCTpfa assembler has been significantly improved for complex models that spend a lot of time computing constitutive laws. Also the numerical - _Embedded:_ Coupling between a bulk domain and an embedded lower-dimensional sub-domain which has an independent grid
differentiation scheme was improved by altering the order in which derivatives are computed. - _Facet:_ Coupling betweeen a bulk domain and a codimension-one sub-domain, which is conforming with the element facets of the bulk domain
- __Solution-dependent spatial params:__ A redesign of the spatial params interface allows now to define spatial parameters such as permeability - __Free-flow models:__ The previous Navier-Stokes model using the box method has been replaced by one that employs a staggered grid discretization.
and porosity that depend on the solution. This makes it easier to implement mineralization models altering the solid structure of the porous medium. The new method does not require any stabilization techniques while those were necessary for the box method in order to avoid spurious oscillations.
- __Different wettability:__ The 2p models can now model materials with different wettability (hydrophobic, hydrophilic) in different parts of the domain. The free-flow models in DuMuX 3.0 consider single phase flow with or without component/energy transport. So far, only regular Cartesian grids are supported
- __Thermal and chemical non-equilibrium:__ The possibility to consider thermal and/or chemical non-equilibrium of several types has been enabled for all but local grid refinement will be added in a future release.
porous medium models. Several RANS models for turbulent flow have been added: k-omega, k-epsilon, low-Re-k-epsilon, one-eq, zero-eq. The RANS models might be subject to further (interface)
- __Maxwell-Stefan-diffusion:__ Most models can now use Maxwell-Stefan diffusion for multi-component diffusion instead of Fickian diffusion. changes.
There is also a few tests demonstrating how to use it. - __Thermal and chemical non-equilibrium:__ The possibility to consider thermal and/or chemical non-equilibrium of several types has been enabled for all
porous medium models.
* __IMMEDIATE INTERFACE CHANGES not allowing/requiring a deprecation period:__ - __Interface solver:__ For the two-phase flow model in conjunction with the box scheme, an interface solver can now be used to reconstruct the saturations
- Many classes have been completely redesigned. See the numerous example applications included in 3.0 showcasing all new classes. in the sub-control volumes adjacent to vertices that lie on material discontinuities. This allows a sharper representation of the saturation front evolving
- The `GridCreator` has been replaced by the `GridManager`, which no longer uses a singleton for the grid object. in heterogeneous porous media.
This makes it possible to create two grids of the exact same type. The `GridManager` also handles user data provided in grid files. - __Components:__ Components can now derive from different base classes, `Base`, `Liquid`, `Solid`, `Gas`, depending on which
phase states are implemented. This can be used to determine at compile time if a component supports a certain phase state.
* __Deprecated CLASSES/FILES, to be removed after 3.0:__ - __Tabulation of fluid parameter laws:__ The tabulation of fluid parameter laws has been improved to only tabulate those functions actually used during the
- All classes of the sequential models are deprecated. The sequential models will be ported to the new structure simulation. To this end, the tabulation is done on the first call of a corresponding fluid parameter.
of porous medium models (formerly called implicit models). This way sequential and implicit model implementations - __MPNC:__ The general m-phase n-component model has been adapted in structure to the other porous medium flow models.
no longer differ and use the same numerical infrastructure. - __Different wettability:__ The 2p models can now model materials with different wettability (hydrophobic, hydrophilic) in different parts of the domain.
- The `TimeManager` class is to be replaced by the class `TimeLoop`. - __Maxwell-Stefan-diffusion:__ Most models can now use Maxwell-Stefan diffusion for multi-component diffusion instead of Fickian diffusion.
- The `VtkMultiWriter` class is to be replaced by the class `VtkOutputModule`. There are also a few tests demonstrating how to use it.
- The file `start.hh` is replaced by new style main files.
## Immediate interface changes not allowing/requiring a deprecation period
* __Deprecated MEMBER FUNCTIONS, to be removed after 3.0:__
- Many classes have been completely redesigned. See the numerous example applications included in 3.0 showcasing all new classes.
* __DELETED classes/files, property names, constants/enums, - The `GridCreator` has been replaced by the `GridManager`, which no longer uses a singleton for the grid object.
member functions, which have been deprecated in DuMuX 2.12:__ This makes it possible to create two grids of the exact same type. The `GridManager` also handles user data provided in grid files.
- Everything listed as deprecated below has been removed.
## Deprecated classes/files, to be removed after 3.0
- All classes of the sequential models are deprecated. The sequential models will be ported to the new structure
of porous medium models (formerly called implicit models). This way sequential and implicit model implementations
no longer differ and use the same numerical infrastructure.
- The `TimeManager` class is to be replaced by the class `TimeLoop`.
- The `VtkMultiWriter` class is to be replaced by the class `VtkOutputModule`.
- The file `start.hh` is replaced by new style main files.
## Deleted classes/files/functions... which have been deprecated in DuMuX 2.12
- Everything listed as deprecated below has been removed.
Differences Between DuMuX 2.11 and DuMuX 2.12 Differences Between DuMuX 2.11 and DuMuX 2.12
...@@ -134,7 +145,7 @@ Differences Between DuMuX 2.11 and DuMuX 2.12 ...@@ -134,7 +145,7 @@ Differences Between DuMuX 2.11 and DuMuX 2.12
[test/multidomain/README](test/multidomain/README) for details. [test/multidomain/README](test/multidomain/README) for details.
Also the geomechanics models require Dune 2.4 and PDELab 2.0. Also the geomechanics models require Dune 2.4 and PDELab 2.0.
- DuMux 2.12 requires at least GCC 4.9 or Clang 3.5 in their C++-14 mode. - DuMuX 2.12 requires at least GCC 4.9 or Clang 3.5 in their C++-14 mode.
- For employing corner-point grids by means of opm-grid (former - For employing corner-point grids by means of opm-grid (former
dune-cornerpoint), the OPM releases 2017.04 or 2017.10 have to be used. dune-cornerpoint), the OPM releases 2017.04 or 2017.10 have to be used.
...@@ -183,7 +194,7 @@ Differences Between DuMuX 2.10 and DuMuX 2.11 ...@@ -183,7 +194,7 @@ Differences Between DuMuX 2.10 and DuMuX 2.11
Dune 2.4 core and specific versions of other modules, see Dune 2.4 core and specific versions of other modules, see
`test/multidomain/README` for details. `test/multidomain/README` for details.
- DuMux 2.11 requires at least GCC 4.9 or Clang 3.5 in their C++-14 mode. - DuMuX 2.11 requires at least GCC 4.9 or Clang 3.5 in their C++-14 mode.
- For employing corner-point grids by means of opm-grid (former - For employing corner-point grids by means of opm-grid (former
dune-cornerpoint), the OPM release 2016.04 has to be used. dune-cornerpoint), the OPM release 2016.04 has to be used.
...@@ -234,7 +245,7 @@ Differences Between DuMuX 2.9 and DuMuX 2.10 ...@@ -234,7 +245,7 @@ Differences Between DuMuX 2.9 and DuMuX 2.10
Dune 2.4 core and specific versions of other modules, see Dune 2.4 core and specific versions of other modules, see
`test/multidomain/README` for details. `test/multidomain/README` for details.
- DuMux 2.10 requires at least GCC 4.9 or Clang 3.5 in their C++-14 mode. - DuMuX 2.10 requires at least GCC 4.9 or Clang 3.5 in their C++-14 mode.
- For employing corner-point grids by means of opm-grid (former - For employing corner-point grids by means of opm-grid (former
dune-cornerpoint), the OPM release 2016.04 has to be used. dune-cornerpoint), the OPM release 2016.04 has to be used.
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment