Add ability to get diagnostics manager controlled physics diagnostics #18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
447dce9
to
8cc67dd
Compare
8cc67dd
to
43549ec
Compare
This was referenced Nov 30, 2023
Now that NOAA-GFDL/SHiELD_physics#33 was merged, we no longer need to pin to a branch on our fork.
elynnwu
approved these changes
Dec 6, 2023
spencerkclark
added a commit
to ai2cm/fv3net
that referenced
this pull request
Dec 6, 2023
spencerkclark
added a commit
to ai2cm/fv3net
that referenced
this pull request
Dec 6, 2023
spencerkclark
added a commit
to ai2cm/fv3net
that referenced
this pull request
Dec 8, 2023
This PR builds on #2365 and makes the changes necessary to add `predictor` and `nudging` regression tests for SHiELD-wrapper-based prognostic runs. In so doing it refactors `test_regression.py` to parametrize over the wrapper type, and move the base fortran configs into YAML files in their own subdirectory. Note that unlike in #2350 no changes are required to the time loop of the prognostic run, thanks to ai2cm/SHiELD-wrapper#18, which has now been merged upstream. I updated the SHiELD-wrapper submodule accordingly in this PR. Significant internal changes: - Added a `wrapper` parameter to `file_configs_to_namelist_settings`, since one of the namelist parameters used to control the output frequency of physics diagnostics in SHiELD is different than that in FV3GFS. - Moved the base fortran config for the FV3GFS prognostic run regression tests into a YAML file in a subdirectory alongside the base fortran config for the SHiELD prognostic run regression tests. - [x] Tests added
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In FV3GFS, I included the diagnostics manager controlled physics diagnostics within the same data structure as the non-diagnostics-manager controlled physics diagnostics, while in SHiELD, I created a separate data structure for clarity. To enable getting diagnostics manager controlled diagnostics in the SHiELD-wrapper, some backend modifications are needed to work around this split. The frontend API remains identical, however.
In the fv3net prognostic run, we happen to always get a diagnostics manager controlled diagnostic within the time loop. This is not strictly necessary—we could introduce model specific logic in the time loop to work around this, as we did in ai2cm/fv3net#2350—but since this diagnostic does exist in SHiELD, we might as well enable getting it so that the fv3net prognostic run time loop (and testing logic) can remain as clean as possible.
Note that this does require a minor upstream change in the SHiELD_physics repository to make some additional objects public: NOAA-GFDL/SHiELD_physics#33, which has now been merged.
Backend changes
get_metadata_diagnostics,get_diagnostic_2d, andget_diagnostic_3dwithincoupler_lib.F90now take an additional boolean argument denoting whether one would like to get data from adiag_manager_controlleddiagnostic or not._get_diagnostic_infonow uses tuple-valued keys(module_name, name)instead of integer keys, since the index no longer uniquely defines a diagnostic.diag_manager_controlledandindexare now added as attributes to theDiagnosticInfonamed tuple. Not only is this more general than what was implemented previously, it also makes for simpler querying of whether the requested diagnostic exists withinget_diagnostic_metadata_by_name.