Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a legacy flag for the execute of timestep begin/end in fixed point solve object #28930

Open
YaqiWang opened this issue Oct 25, 2024 · 1 comment · May be fixed by #28932
Open

Add a legacy flag for the execute of timestep begin/end in fixed point solve object #28930

YaqiWang opened this issue Oct 25, 2024 · 1 comment · May be fixed by #28932
Labels
T: task An enhancement to the software.

Comments

@YaqiWang
Copy link
Contributor

Motivation

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 YaqiWang added the T: task An enhancement to the software. label Oct 25, 2024
@YaqiWang
Copy link
Contributor Author

I will push up a PR for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: task An enhancement to the software.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant