A few refactorings to handle fields with ungridded dimensions, particularly for prep_rof_mod#628
Conversation
Expose two methods that will be useful for the water tracer work:
(1) med_field_info_create_from_field: create a single field_info object
from information in an ESMF_Field (extracted from
med_field_info_array_from_state)
(2) med_field_info_esmf_fieldcreate: create an ESMF Field based on a
field_info object (extracted from med_methods_FB_init)
The previous mechanism - using ESMF/NUOPC attributes - doesn't work in a new context where I want to use this routine. From some initial testing, it seems that this new mechanism of querying the Field for its various ungridded variables gives the same result in most cases; the one exception I see is for the cpl_scalars Fields. I'm guessing this will be okay, but I'll do some testing to verify this.
This will be needed for water tracers. The one piece that is *not* handled yet is the irrigation-specific mapping.
|
I'll need to make similar changes in med_phases_post_rof_mod and possibly some other prep/post modules, but for now I think I'll keep this PR as is and then open additional PRs with changes elsewhere as I tackle these additional modules for the water tracer work. |
| public :: med_field_info_create | ||
| ! Create a single field_info object from direct specification of values | ||
| public :: med_field_info_create_directly | ||
|
|
There was a problem hiding this comment.
You could create an interface and call these interchangably
There was a problem hiding this comment.
Yeah. I personally find that to often be more confusing than helpful except in very limited cases such as supporting multiple data types or array ranks: In cases where there is a completely different interface, my experience is that having a generic interface adds little if any value, and just makes it harder to figure out what's actually being called when trying to trace the code.
That said, I'm open to doing this if others prefer it.
There was a problem hiding this comment.
I agree that it's not always useful or prudent to do this and I leave it to your discretion.
3 participants
Description of changes
These are changes to support adding water tracers in CMEPS, which will be done using fields with ungridded dimensions. In particular, the changes here are needed to support adding ROF-related fields. I initially developed and tested these changes in the context of my branch for adding water tracers, but have split these off to their own PR to facilitate review of these changes, since they potentially impact things beyond just the addition of water tracers.
(1) Refactor med_field_info_mod and med_methods_mod to expose two methods that will be useful for the water tracer work: med_field_info_create_from_field (extracted from med_field_info_array_from_state) and med_field_info_esmf_fieldcreate (extracted from med_methods_FB_init)
(2) Change the mechanism for getting ungridded info from a Field: The previous mechanism - using ESMF/NUOPC attributes - doesn't work in a new context where I want to use this routine. So I have changed this to do a more direct querying of the Field. I added write statements to check whether there were any differences from this change, in
ERS_D_Ld3.ne30pg3_t232.B1850C_LTso.derecho_intel.allactive-defaultio. At least in that configuration, the only difference was that, in various calls,cpl_scalarsis now given an ungridded dimension of size 4, whereas previously it was not given an ungridded dimension. The new behavior seems probably correct, but I guess this didn't have any impact before. As noted below, this doesn't change answers, at least for the tests I ran.(3) Generalize code in prep_rof to handle fields with ungridded dimensions. This will be needed for water tracers. The one piece that is not handled yet is the irrigation-specific mapping.
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
Tested in the context of cesm3_0_alpha08b, or something close to it (ESCOMP/CESM@622984f), with share updated to share1.1.18, and the changes here rebased onto cmeps1.1.32.
The following tests all passed and were bit-for-bit with baselines: