-
Notifications
You must be signed in to change notification settings - Fork 68
Cheat mode #160
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
Cheat mode #160
Conversation
Add "cheat mode", which can be enabled via the `CHEAT_MODE_DIR` CPP definition. When enabled, `coupler_init` will check for the existence of a tarball corresponding to the current segment in the directory specified by `CHEAT_MODE_DIR`. If this tarball already exists, the main loop is skipped and the root PE extracts the tarball before the program exits (after `fms_end` is called). If the tarball does not exist, the main loop runs normally and the root PE creates the tarball before the program exits (after `fms_end` is called).
Use a quoting macro to create a string literal from `CHEAT_MODE_DIR`.
`error_mesg` calls do not seem to work after `fms_end`, so the information content of those messages is now printed at the end of `coupler_init`.
Add a module containing the variables and subroutines that are relevant to cheat_mode.
Fix the namelist reading code by adding the `fms_` prefix to `input_nml_file` and `check_nml_error`.
Use `FMS_PATH_LEN` to set the string lengths for the tarball's directory and path.
|
Honestly, having dealt with FRE-NCTools, I am not a fan of having test-related code in "real" code. What does the tar ball contain and is this implementation the only route for testing fre workflow? |
Curious because I don't know, what are some of the downfalls you found with having test-related code with "real" code in FRE-NCTools? |
|
Just for the reason why tests are usually separate from production code - readability, maintainability, etc |
|
The tarball contains all the output files generated by a previous model run. This PR's approach definitely isn't the only way to implement the workflow simulator: the other approach is to hack the runscript so that it doesn't invoke the model, and extracts a tarball instead. This PR's approach is closer to a true end-to-end test since model initialization still occurs, and it's a bit cleaner in the sense that it can be used to test unmodified runscripts (which makes the end-to-end test just a straight Another possibility is that we could add a generic mechanism to the coupler for invocation of hooks at the end of |
|
tagging authorities on this lol @thomas-robinson @uramirez8707 |
|
We will be discussing this at the 10am rewrite meeting tomorrow (Wed). |
|
#161 is a prototype of the alternative hook-based approach. |
Add "cheat mode", which can be enabled via the
CHEAT_MODECPP definition. When enabled,coupler_initwill check for the existence of a tarball corresponding to the current segment in the directory specified bydirincheat_mode_nml. If this tarball already exists, the main loop is skipped and the root PE extracts the tarball before the program exits (afterfms_endis called). If the tarball does not exist, the main loop runs normally and the root PE creates the tarball before the program exits (afterfms_endis called).The purpose of this feature is to support the FRE workflow simulator. No runscript hacking is required with this approach, as the "cheat mode" model run behaves (from the runscript's perspective) exactly like an actual model run.