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

Restart workflow issues on complex multiapp setup #29673

Open
GiudGiud opened this issue Jan 10, 2025 · 0 comments
Open

Restart workflow issues on complex multiapp setup #29673

GiudGiud opened this issue Jan 10, 2025 · 0 comments
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: defect An anomaly, which is anything that deviates from expectations.

Comments

@GiudGiud
Copy link
Contributor

GiudGiud commented Jan 10, 2025

Description

The GCMR inputs, being modified here idaholab/virtual_test_bed#506, fail in most restart configurations. The current restart is very complex, with a hybrid workflow:

  • neutronics (parent) using the Griffin TransportSolutionVectorFile
  • thermo-mechanics (middle app) uses restart from a checkpoint. It's setup with 'force_restart = true' for now
  • thermal hydraylics (grand child app) should use the restart from its parent

This workflow fails if the middle app uses the checkpoint from the previous run, and passes if the middle app uses the full mesh generation like the previous run. This isnt right

How to reproduce

See changes in thermo-mechanics files in idaholab/virtual_test_bed#506

Design

Add an error message for what is actually happening rather than the current sanity check (which i am glad we have, but it's not catching the real issue)
Improve the sanity check to be more clear about what it is detecting

Impact

Easier user experience for restart simulations

@GiudGiud GiudGiud added C: Framework T: task An enhancement to the software. T: defect An anomaly, which is anything that deviates from expectations. P: normal A defect affecting operation with a low possibility of significantly affects. labels Jan 10, 2025
GiudGiud added a commit to GiudGiud/moose that referenced this issue Jan 10, 2025
@GiudGiud GiudGiud removed the T: task An enhancement to the software. label Jan 10, 2025
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: defect An anomaly, which is anything that deviates from expectations.
Projects
None yet
Development

No branches or pull requests

1 participant