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

Allow MAPL to overwrite checkpoint restarts #3262

Closed
rtodling opened this issue Dec 20, 2024 · 1 comment
Closed

Allow MAPL to overwrite checkpoint restarts #3262

rtodling opened this issue Dec 20, 2024 · 1 comment
Assignees

Comments

@rtodling
Copy link
Contributor

I am running into a problem that leads me to believe that the checkpoint restarts cannot be overwritten … I recall there was a similar issue w/ history sometime back, and you pointed me to a flag in history that allows history to (use its old behavior) to overwrite its nc4 output files, this is the toggle:

Allow_Overwrite: .true.

I am wondering if the checkpoint writing suffers from the same restriction, or rule, that then cannot be overwritten by default. If that is so, is there an equivalent statement that can be put in AGCM.rc that tells MAPL to allow for overwrite?

CONTEXT: when the ADAS ensemble crashes, all that's typically needed is for the job to be re-submitted and the ensemble picks up from where it left; it re-does only what hasn't completely successful in the original run. In case a member GCM crashes past the time it had written checkpoint files ... a re-submit will try to overwrite the checkpoint files previously written; with the present MAPL restriction of not allow restarts to be overwritten it is impossible to use the checkpoint mechanisms of the ensemble ADAS ... it requires re-running the who cycle from scratch.

The version of MAPL used in the 5.41.x ADAS is: v2.47.1.2 it would be nice to have the option added on top of this; and carried forward to more recent versions of MAPL.

bena-nasa added a commit that referenced this issue Dec 23, 2024
@bena-nasa
Copy link
Collaborator

@rtodling I'm implementing this, and once I've tested it, and do a PR into our develop branch I can back port this into a v2.47.1.2, I guess we would do a v2.47.1.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants