Open luca-heltai opened 5 months ago
I have started some work here, still there are some things to be done:
solve_ode()
to a loop with solve_ode_incrementally()
, because solver_should_restart()
is called at each output step. Instead, I'd like the restart time to be smaller than the output time.In any case, without using a custom setup, it seems to me that the only restart mode available is after a fixed amount of time. Maybe it gets too complicated, but I wonder if restarting after a fixed amount of steps instead would improve the error without a too big computational overhead. This way, we would exploit ARKode's timestep adaptivity at full.
A possibly better alternative would be to restart if the global error estimator is larger than a given fraction of the absolute tolerance. That way you don’t restart unless it is necessary. LucaIl giorno 3 lug 2024, alle ore 01:21, ste-dtst @.***> ha scritto: I have started some work here, still there are some things to be done:
Complete the implementation of the solution transfer, in particular I will have a look at the AffineConstraints documentation to use them correctly. Probably I will switch from solve_ode() to a loop with solve_ode_incrementally(), because solver_should_restart() is called at each output step. Instead, I'd like the restart time to be smaller than the output time.
In any case, without using a custom setup, it seems to me that the only restart mode available is after a fixed amount of time. Maybe it gets too complicated, but I wonder if restarting after a fixed amount of steps instead would improve the error without a too big computational overhead. This way, we would exploit ARKode's timestep adaptivity at full.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
Ok, I will try this way.
Regarding the AffineConstraints: I had a look at Step 52 and at the documentation. If I understand correctly, I can still make the hanging node constraints and distribute local to global as usual. The main difference is that I must call distribute
after solution
is interpolated from the initial condition and then at the end of each Runge-Kutta step. In particular, I should call distribute
either in solve_mass
and in solve_linearized_system
(linking this issue to #6 ). Am I right?
Yes, this is correct. The only tricky issue is that you have to properly transfer the solution between refinements.
Use an AffineConstraints object to distibute local to global and implement adaptive mesh refinement via SolutionTransfer and the solver_should_restart function.
Is there any caveat in using constraints with two different linear systems to be solved?