FixedPointSolve object was factored from Transient executioner, thus inherited the execution of objects on timestep_begin and timestep_end within multiphysics fixed point iterations. Users would imagine those objects are to be executed once per time step but not the case when fixed point iteration is turned on. In a more complicated executioner settings, where fixed point iteration could be an inner solve object, things can get worse, i.e. executed unnecessarily frequently. It is desired to have two new execute flags fixed_point_begin and fixed_point_end to replace the timestep_begin and timestep_end flags and make the two flags at the beginning and end of a time step possibly in timesteppers.
Design
To ease the transition, I suggest we create a legacy parameter in MooseApp, like use_legacy_fixed_point_execute_on, defaulting to true. When this flag is false, FixedPointSolve will not execute objects on timestep_begin and timestep_end. And we add the two new flags and execute objects on them within FixedPointSolve. This will allow application developers to gradually scrutinize their execute_on parameters and put objects on the desired flags.
Impact
This won't impact any existing capabilities except that users will be seeing a legacy message on the screen, which will be up to application developers to fix codes/tests to properly remove the legacy message. In Griffin, we have a strong motivation to make this happen because our complicated executioner settings.
YaqiWang
commented
1 month ago
Motivation
FixedPointSolveobject was factored fromTransientexecutioner, thus inherited the execution of objects on timestep_begin and timestep_end within multiphysics fixed point iterations. Users would imagine those objects are to be executed once per time step but not the case when fixed point iteration is turned on. In a more complicated executioner settings, where fixed point iteration could be an inner solve object, things can get worse, i.e. executed unnecessarily frequently. It is desired to have two new execute flagsfixed_point_beginandfixed_point_endto replace thetimestep_beginandtimestep_endflags and make the two flags at the beginning and end of a time step possibly in timesteppers.Design
To ease the transition, I suggest we create a legacy parameter in
MooseApp, likeuse_legacy_fixed_point_execute_on, defaulting to true. When this flag is false,FixedPointSolvewill not execute objects on timestep_begin and timestep_end. And we add the two new flags and execute objects on them withinFixedPointSolve. This will allow application developers to gradually scrutinize their execute_on parameters and put objects on the desired flags.Impact
This won't impact any existing capabilities except that users will be seeing a legacy message on the screen, which will be up to application developers to fix codes/tests to properly remove the legacy message. In Griffin, we have a strong motivation to make this happen because our complicated executioner settings.