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
Enable multi-level Picard iterations to restart from the latest solution #14056
Labels
C: Framework
P: normal
A defect affecting operation with a low possibility of significantly affects.
T: task
An enhancement to the software.
Milestone
Comments
vincentlaboure
added
P: normal
A defect affecting operation with a low possibility of significantly affects.
T: task
An enhancement to the software.
labels
Sep 17, 2019
@vincentlaboure Do you have a simple inputfile to demonstrate this? |
@fdkong Just sent you a PM directing you to a test in Sabertooth |
fdkong
added a commit
to fdkong/moose
that referenced
this issue
Jan 7, 2020
fdkong
added a commit
to fdkong/moose
that referenced
this issue
Jan 7, 2020
fdkong
added a commit
to fdkong/moose
that referenced
this issue
Jan 13, 2020
fdkong
added a commit
to fdkong/moose
that referenced
this issue
Jan 13, 2020
fdkong
added a commit
to fdkong/moose
that referenced
this issue
Jan 14, 2020
fdkong
added a commit
to fdkong/moose
that referenced
this issue
Jan 28, 2020
fdkong
added a commit
to fdkong/moose
that referenced
this issue
Jan 29, 2020
fdkong
added a commit
to fdkong/moose
that referenced
this issue
Jan 29, 2020
fdkong
added a commit
to fdkong/moose
that referenced
this issue
Feb 4, 2020
aeslaughter
pushed a commit
to aeslaughter/moose
that referenced
this issue
Feb 13, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C: Framework
P: normal
A defect affecting operation with a low possibility of significantly affects.
T: task
An enhancement to the software.
Reason
In #13310, the behavior of multi-level Picard iterations was fixed. However, for pseudo-transient calculations, it can be very efficient to be able to restart from the latest solution when taking starting another Picard iterations.
Consider the same as setup:
When level1 passes information back to master, and master takes another full solve, it then passes something back to level1 which currently would restart from t = 0. For large pseudo-transient problems, it is not only wasteful but is also hard to tell when the Picard iteration has converged (because even when fully converged, restarting from the initial condition means that the residual is still very large)
Design
It would be ideal to have a flag, similar to
FullSolveMultiApp/*/no_backup_and_restore = true
to make the desired behavior possible.Impact
It will enable efficient pseudo-transients for a fairly standard multiphysics setup (eigenvalue calculation + pseudo time-dependent physics)
The text was updated successfully, but these errors were encountered: