idaholab / moose

Multiphysics Object Oriented Simulation Environment
https://www.mooseframework.org
GNU Lesser General Public License v2.1
1.77k stars 1.05k forks source link

TransientMultiApp catch_up should default to true #8168

Open dschwen opened 7 years ago

dschwen commented 7 years ago

Description of the enhancement or error report

Not setting catch_up to true 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.

dschwen commented 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 :-/

dschwen commented 7 years ago

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)

friedmud commented 7 years ago

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 .

rwcarlsen commented 7 years ago

@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.