-
Notifications
You must be signed in to change notification settings - Fork 437
Open
Labels
EAMxxIssues related to EAMxxIssues related to EAMxx
Description
We should likely settle on a naming scheme for our IO. Currently, we have three different file classes of interest, with differing schemes
file type | current pattern | purpose |
---|---|---|
restart | [case_name].scream.r.[restart_spec].[date_spec].nc | restart simulation from a checkpoint |
restart history | [any_string].rhist.[restart_spec].[date_spec].nc | restart simulation from a checkpoint |
history | [any_string].[output_spec].[date_spec].nc | save simulation output |
Proposed changes
file type | proposed pattern |
---|---|
restart | [case_name].[model_name].r.[restart_spec].[date_spec].nc |
restart history | [case_name].[model_name].rh.[any_string].[output_spec].[date_spec].nc |
history | [case_name].[model_name].h.[any_string].[output_spec].[date_spec].nc |
Some notes
- any_string will come from the yaml files, e.g., myNcQcQr
- output_spec and restart_spec are EAMxx-specific, e.g., INSTANT.nhours_x3, for output and restart frequency
- restart history takes output specs in its name to avoid bugs like bug in same out, different freq scenario scream#2981
- model_name is scream for now, but we should change that to eamxx at some point
Rationale
- this will make us follow E3SM conventions while maintaining our own custom IO settings, a decent compromise
- this will enable us to make use of extensive infrastructure tooling (e.g., short-term archive, which is good for production but equally important for testing) without long-standing silent bugs...
Comment and vote below!
rljacob and bartgol
Metadata
Metadata
Assignees
Labels
EAMxxIssues related to EAMxxIssues related to EAMxx