Clean incoporation of new time integration methods
@timok, @bernd, @kweis, @martins and I are currently discussing/developing the incorporation of a generic time integration framework in Dumux. In general, time handling is currently problematic in Dumux and leads to a bug in MultiDomain (#792, #619).
We currently have a draft implementation, that is rather provisional and is spread over or depends on several branches and merge requests (!2134, !2281, !2130,
feature/timestepmethods). The latest status is that the draft implementation works for porous medium flow problems, however, involving changes to the main file. Moreover, we modified the assembly process in order for the time step methods to work. It is currently hard to review due to the number of branches and the huge discussions, and it would be nice to achieve a clean transition. I (still) think it can be achieved in a backwards-compatible way. To this end, I propose to undertake the following steps - with the goal that each of them are realized in a backwards-compatible way - successively:
- introduce new grid variables concept, where they represent the complete state of a simulation - thus, not only secondary but also primary variables. (see !2285)
introduce new assembly concept
PDESolveraccept both assemblers that assemble around given
SolutionVectorsor more generic
2.2. add generic version of
FVAssembler, which assembles around
Variablesand which can be extended to support the time integration methods (see !2295)
- add time step methods (see !2296)
- extend assembly to work with the time step methods (!2297)
MultiDomainto work with new approach and test with
These points are the individual ingredients that we realized in the draft, I think. Each point could be on a separate branch that build up on each other. The separation gives us the possibility to run the test suite for each piece and make sure everything still works. I would propose to leave respective merge requests open until the entire chain is developed and we can evaluate the quality of the overall result. Then, we could merge subsequently and delete old merge requests and branches.
I would start working on this, but wanted to check back with you beforehand, if you have any objections to this approach, or, if you disagree on the proposed fragmentation. And, we should of course still discuss if point 1 is desired, but maybe we can only really evaluate this once realized.