WIP Feature/timestepper test

Closed Dennis Gläser requested to merge feature/timestepper-test into feature/timestepmethods

Many todos...

One of them:

  • rethink commit providing access to assembler/linear solver in PDESolver

Furthermore, I guess we have to rethink our plan to not provide the current solution to the PDESolver/assembler - as a reminder: the motivation was to avoid multiple calls to gridVars.init() or update() in case users have instantiated grid vars before assembly. What we also wanted to achieve is that, when a user creates grid vars and a solution in the main file, after the time integration procedure we said we'd like both the solution and the grid variables to be on the state after time integration withouth the user having to do anything.

The problem is - I changed the (grid)variables concept such that they store a pointer to the solution with which they were updated. However, if we change that pointer in update() which is, for instance, called from the NewtonSolver after an iteration, this changes the pointer in the grid variables of the user as the user grid vars are used in the last stage of time integration such that everything is written into them. Now it works because the time stepper receives a user solution vector (in which to store the solution), which is the one stored in the user grid variables, and which is forwarded to the PDESolver. So the whole chain uses that solution vector. But, I guess we have to think more about this as this is error-prone. If the user provides another solution vector to store the result in then the grid variables won't be up to date after time integration. This issue is a general one in our current assembly concept (as we discussed).

W.r.t. time integration: what we could do is to always use temporary grid variables for all stages (also the last) and copy the last grid variables into the user grid vars. But, as the solution vector that created the object is a temporary, the pointer would lose validity - this could only be fixed using shared_ptr everywhere... But maybe we find a better way.

Edited by Timo Koch

Merge request reports