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

Enable multi-level Picard iterations to restart from the latest solution #14056

Closed
vincentlaboure opened this issue Sep 17, 2019 · 2 comments · Fixed by #14574
Closed

Enable multi-level Picard iterations to restart from the latest solution #14056

vincentlaboure opened this issue Sep 17, 2019 · 2 comments · Fixed by #14574
Assignees
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.

Comments

@vincentlaboure
Copy link
Contributor

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:

  • Steady master calls a FullSolveMultiApp with picard iterations
  • Transient subapp level1 calls a TransientMultiApp from t = 0 to t = 1 with dt = 0.2
  • Transient subapp level2 from t = 0 to t = 1 with dt = 0.2

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)

@vincentlaboure 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
@fdkong
Copy link
Contributor

fdkong commented Oct 22, 2019

@vincentlaboure Do you have a simple inputfile to demonstrate this?

@fdkong fdkong self-assigned this Oct 22, 2019
@vincentlaboure
Copy link
Contributor Author

@fdkong Just sent you a PM directing you to a test in Sabertooth

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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants