timestep_limiting_postprocessor ineffective

[jessecarterMOOSE]

Check these boxes if you have followed the posting rules.

• Q&A General is the most appropriate section for my question
• I have consulted the posting Guidelines on the Discussions front page
• I have searched the Discussions forum and my question has not been asked before
• I have searched the MOOSE website and the documentation does not answer my question
• I have formatted my post following the posting guidelines (screenshots as a last resort, triple back quotes around pasted text)

Question

I'm trying to use a timestep_limiting_postprocessor in IterationAdaptiveDT to give a suggestion for the next dt. I'm using a Terminator (set to SOFT at TIMESTEP_END) to trigger a failed solve when the material model requests it. Theoretically, in this case, the timestep_limiting_postprocessor will limit the dt, but the failed solve causes a bunch of values to reset to end of the last good solve (seen in Reporter Restoration Summary printed to screen) . This includes my timestep_limiting_postprocessor value, so the information on what the material model was suggesting is lost.

Can I not reset the postprocessor on failed solve? Or is there some way to "trigger" another material loop and re-compute the processor? I'm using a custom TimeStepper that inherits from IterationAdaptiveDT so maybe I can do something there in the computeFailedDT method.

[GiudGiud]

Hello

you can try to adjust the postprocessor schedule to have it be computed before the reset but not after. Maybe timestep_end?

alternatively we could had an option to not restep a postprocessor during a restep. @zachmprince if you have more ideas

[zachmprince]

What exactly is the logic for your Terminator? Could you possibly use the reject_large_step logic? This is preferred over using Terminator since there is logic in IterationAdaptiveDT that will cache the postprocessor value and use it on the repeated step.

[jessecarterMOOSE]

I'm terminating if mateiral timestep postprocessor < dt.

I want to use IterationAdaptiveDT with MaterialTimeStepPostprocessor as the timestep_limiting_postprocessor, but this caveat is listed in the docs:

note:Time Step Limiter Lags Calculation
The value of the maximum allowable time step as collected by the MaterialTimeStepPostprocessor is enforced in the next simulation time step.

I'm trying to have to the MaterialTimeStepPostprocessor pick the timestep after the failed solve due to the Terminator.

[jessecarterMOOSE]

Oh, but I'm only having the terminator run at TIMESTEP_END.

[zachmprince]

I believe you can replace your Terminator with:

[Executioner]
  ...
  [TimeStepper]
    ...
    timestep_limiting_postprocessor = postprocessor
    reject_large_step = true
    reject_large_step_threshold = 0.999
  []
[]

This will cause the time step to be repeated if the resulting value of the postprocessor is less than the dt that was used. It will subsequently set dt to a cached version of thepostprocessor in the redone step, avoiding the restore behavior you observed.

[jessecarterMOOSE]

OK I'll try that.

In the meantime I found I can grab the postprocessor value by overriding the postStep() method, which gets called after the solve but before the postprocessor values are reset. Then I can check the value in computeFailedDT() against the current dt and use the lesser of the values. Your way sounds much simpler though.