Open dschwen opened 7 years ago
Wait... if there is no catch up then the master app should fail and cut its timestep. But that is not quite what I observe. I have a coupled Bison Marmot run that at some point has Bison at time 5e5 and marmot at time 3e5 :-/
Also the timestepper does not seem to be working during catch up steps. I.e. a timestep cut due to solve failure does not grow back (tagging @friedmud because he is working on a new Stepper system)
Noted - but can't do anything about it currently. I hope to finish my semester this week and I may have some time after to push through the Steppers changes and look at this. On Mon, Dec 5, 2016 at 11:13 AM Daniel Schwen notifications@github.com wrote:
Also the timestepper does not seem to be working during catch up steps. I.e. a timestep cut due to solve failure does not grow back (tagging @friedmud https://github.com/friedmud because he is working on a new Stepper system)
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/8168#issuecomment-264896646, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1JMblJmVUcka7vVTNZSrHIOlo1w4Rqks5rFDgSgaJpZM4LEYPU .
@dschwen Under some circumstances, the IterationAdaptive stepper does not regrow after a cutback (due to converge/solve failure) until the second successful converged iteration. This sounds similar to #7842.
Description of the enhancement or error report
Not setting
catch_up
totrue
can result in unphysical time lag between master and subs.Rationale for the enhancement or information for reproducing the error
Seems like a broken default. Too easy to get junk results.
Identified impact
All TransientMultiApp simulations.