Refactor med_methods_FB_init to allow handling of water tracer fields #620
Conversation
This file contains hidden or 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
Rather than having med_methods_FB_init accept one of fieldNameList or STflds, now it accepts an array of med_field_info_type objects. med_field_info_type is defined in a new module that also includes some creation methods, making calls to med_methods_FB_init a two-step process: first create field_info_array, then call med_methods_FB_init with this field_info_array. A key new feature is that the creation of a field_info_array from field_names will assume a single ungridded dimension with size given by shr_wtracers_get_num_tracers for any field with the water tracer suffix. This was the main motivation for the refactor here. Some specific notes about the changes in this commit: - Behavior change: if there are only scalar or blank fields, we do some unnecessary work now (retrieving the mesh that we won't end up ever using) - I think I got the gridToFieldMap right: before it was hard-coded to 2, but I think that was only right for a single ungridded dimension; here I'm generalizing that for multiple ungridded dimensions
We haven't set that up here; we'll fix this in an upcoming set of changes.
Member
Author
|
The build-cmeps workflow will fail here until ESCOMP/CESM_share#78 is merged... then we can try rerunning it at that point. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Description of changes
Rather than having med_methods_FB_init accept one of fieldNameList or
STflds, now it accepts an array of med_field_info_type objects.
med_field_info_type is defined in a new module that also includes some
creation methods, making calls to med_methods_FB_init a two-step
process: first create field_info_array, then call med_methods_FB_init
with this field_info_array.
A key new feature is that the creation of a field_info_array from
field_names will assume a single ungridded dimension with size given by
shr_wtracers_get_num_tracers for any field with the water tracer suffix.
This was the main motivation for the refactor here.
Some specific notes about the changes in this commit:
unnecessary work now (retrieving the mesh that we won't end up ever
using)
but I think that was only right for a single ungridded dimension; here
I'm generalizing that for multiple ungridded dimensions
This depends on the CESM_share changes in ESCOMP/CESM_share#78
Specific notes
Contributors other than yourself, if any:
CMEPS Issues Fixed (include github issue #):
Are changes expected to change answers? (specify if bfb, different at roundoff, more substantial) No - bfb
Any User Interface Changes (namelist or namelist defaults changes)? No
Testing performed
Please describe the tests along with the target model and machine(s)
If possible, please also added hashes that were used in the testing
Ran a subset of the CESM prealpha tests with baseline comparisons, using cesm3_0_alpha08a with this CMEPS branch and the share branch from ESCOMP/CESM_share#78:
All tests pass and are bit-for-bit with the baselines.
There were NLCOMP failures in some tests; from spot-checking, the NLCOMP failures all seem to be in MOM files. Nothing in this PR or the accompanying share PR could change the namelists, so I assume these are a pre-existing issue: