DIVERCONT behaviour

[rjoussen]

While working on material-triggered timestep reduction, I came across the DIVERCONT behavior and was curious about how people use it. Changing its behavior slightly would make the necessary code for timestep adaptation due to other reasons (e.g. on material request) a lot cleaner, since they could use the same common mechanism.

Here is a small summary of what the DIVERCONT parameter does for the new solid time integration and whether the corresponding code is covered by tests.

DIVERCONT option	behaviour	test/coverage
stop (default)	stops simulation, potentially writing a final output.	not covered.
continue	continues simulation without any changes, ignoring divergence. Comment: I see how this might be useful sometimes, but I don't think any test that does not specifically target this exact behavior should make use of continue. For example, the contact2D_patch_linstatic_new_struct.4C.json test (which even has the minimal label, uses MAXITER: 1 and continue.	Covered by any of the 46 tests using this setting, including the preconditioner tutorial.
repeat_step	resets the step and repeats it without any changes. Comment: If that works, I think there is something else wrong.	not covered.
halve_step	halves step size. Also adapts NUMSTEP/step_end parameter.	not covered
adapt_step	same as halve_step, but also checks for possible increase after hardcoded number of 4 steps. Increase is only actually done if the number of remaining steps is even.	covered by any of the 17 tests using this setting.
rand_adapt_step	first computes an average random number across processors (???) and then either increases or decreases the timestep, depending on what it did last time.	not covered.
rand_adapt_step_ele_err	exactly the same behaviour as rand_adapt_step	not covered.
repeat_simulation	same as stop, but doesn't throw immediately. Instead, delegates abortion to the timeloop.	not covered.
adapt_penaltycontact	not implemented error	not covered.

On top of that, the timestep reduction is currently done inside solve(), which returns something called a convergence status. However, this return value is currently ignored by many partitioned solvers, namely: ehl, fsi, pasi, poroelast, porofluid_pressure_based_elast(_scatra), ssi, tsi. This is potentially very dangerous, since the solid timestep can fall out of sync with the timestep of the other field, or, if repeat_simulation is used, the simulation goes on even though the solid integration failed. I am definitely planning on changing this along the way.

My suggestion would be to only keep stop as default, adapt_step with a separate input for more control on how the timestep is changed, and maybe continue (but with reduced test coverage). But I would be interested to know if anyone is actively using any of the other options.

[ischeider]

I use DIVERCONTsometimes, but it rarely does what I want. If I am not mistaken it can only overcome non-convergence (or: slow convergence), not divergence. In addition, it does not overcome local material non-convergence. Anyway, it's better than nothing. If I use it, I use adapt_step, but often I would also like to increase the stepsize beyond the initial one. In addition, it reacts on the number of converged steps when increasing the time step size, but it should rather increase the time step size when the number of iterations decrease below some value.

I must admit as a previous abaqus user I am spoiled by the features there with a bunch of parameters to tweak the simulation.

[rjoussen]

If I am not mistaken it can only overcome non-convergence (or: slow convergence), not divergence

yes, non-convergence is probably more precise.

In addition, it does not overcome local material non-convergence

This is precisely what I am working on. I want to introduce a mechanism that allows materials to request a reduced global time step.

My current layout would be like this:

  TIME STEP CONTROL:
    DECREASE_FACTOR: 0.75
    MIN_TIME_STEP: 1e-7
    STEPS_TO_INCREASE: 10 # try increasing after this many successful steps
    INCREASE_FACTOR: 1.2
    MAX_TIMESTEP: 1e-5 # can be larger than the initial time step

which would be used jointly by DIVERCONT: adapt_step and if a material wants to reduce the timestep (e.g., local non-convergence).

[rjoussen]

but it should rather increase the time step size when the number of iterations decrease below some value.

That's an interesting idea I have not considered so far!

[ischeider]

Highest appreciation for this work!