For water tracers: Add handling of rank-3 fields and refactor med_phases_prep_glc_map_lnd2glc#634
For water tracers: Add handling of rank-3 fields and refactor med_phases_prep_glc_map_lnd2glc#634billsacks wants to merge 6 commits intoESCOMP:mainfrom
Conversation
For code that used to handle 0 or 1 ungridded dimension, add handling of 2 ungridded dimensions. This is needed for fields that already had an ungridded dimension and now have an additional ungridded dimension for water tracers - currently just Flgl_qice_elev. Most of these code changes were written by Claude Code, but reviewed by myself.
Changes were mostly made by Claude Code, reviewed by myself.
This will be needed for qice_elev water tracers, which will have two ungridded dimensions (one for elevation class and one for water tracers). Code was written by Claude Code, reviewed by myself.
Precompute the vertical interpolation coefficients rather than recomputing them for each field. The main motivation is to avoid duplication of this logic when we add water tracer fields. Code mostly written by Claude Code with significant guidance from me, reviewed by myself.
|
The i/o of fields with 2 ungridded dimensions follows the pattern used for fields with 1 ungridded dimension: For fields with 1 ungridded dimension, a separate variable is written for each level (e.g., Now that I write that out, I'm realizing that there's something kind of confusing here: in this case, the name of the 'elev' dimension comes before the name of the 'wtracers' dimension, but the index of the 'wtracers' dimension comes before the index of the 'elev' dimension. I don't think I want to change the name: various code relies on '_wtracers' being the final suffix for all water tracer fields. Changing the order of the ungridded dimensions might be a bit more doable, though still isn't appealing to me, since @mvertens and I agreed that it made the most sense to put the water tracer dimension first. Maybe the solution is to add some metadata in the NetCDF file giving the meaning of each of these indices. But I'm not sure how easy that will be to do (without resorting to hard-coding stuff in an ugly way), because I'm not sure if we have that information readily available in any data structures that are accessible in med_io_mod. I haven't dug into this yet... maybe it's easier than I'm imagining... @mvertens I'd be happy to talk more with you about this if you think this feels important.... |
|
@billsacks - I am wondering if we need to rethink writing separate history fields for each ungridded dimension. I think there was a reason I did it this way for one ungridded dimension - and it was for simplicity. But I don't think this carries over very easily to more than one ungridded dimension. However, this could potentially effect CDEPS when it's trying to ingest this data. Let's chat. |
Sounds good - yes, I'd be very happy to talk this through with you. One issue I'm running into with thinking about adding metadata on the meaning of the indices is how to get a name associated with a given ungridded dimension. I don't think that's stored in the ESMF Field (though maybe it's settable/accessible somehow that I haven't thought to look... I haven't dug too deeply yet); if it isn't, then we may need to store this information somewhere else (or get an ESMF extension to handle this). It feels like a similar issue would arise with having an extra dimension, at least if we want the dimension to be named meaningfully (something more meaningful than "Flgl_qice_elev_wtracers_dim1" and "Flgl_qice_elev_wtracers_dim2"). |
|
@Katetc - if you'd like to look at the changes to prep_glc_mod that I mentioned to you, they're in this PR. More changes will be coming soon in a separate PR to actually add the water tracers, but this includes the preparatory refactor of the vertical interpolation. |
2 participants
Description of changes
Two sets of changes that will be needed for water tracers - and in particular, for the tracer version of Flgl_qice_elev, which will be the first field in CMEPS that has two ungridded dimensions:
(1) Extend various methods to support rank-3 fields
(2) Refactor med_phases_prep_glc_map_lnd2glc to pre-compute vertical interpolation weights; this will be helpful when we introduce Flgl_qice_elev_wtracers to avoid duplicating this calculation of vertical interpolation weights between the non-tracer (rank-2 on the lnd grid and rank-1 on the glc grid) and tracer (rank-3 on the lnd grid and rank-2 on the glc grid) fields.
Specific notes
Contributors other than yourself, if any: Claude Code did a lot of the writing of this code, but I have reviewed it all carefully
CMEPS Issues Fixed (include github issue #):
Are changes expected to change answers? (specify if bfb, different at roundoff, more substantial) bfb when using #633 as a baseline
Any User Interface Changes (namelist or namelist defaults changes)? No
Testing performed
In the context of cesm3_0_alpha08e, ran:
(1) aux_glc on derecho plus a few extra tests, with comparisons against baselines generated with #633 .
The extra tests beyond aux_glc were:
All tests passed and were bit-for-bit, except for this failure that also failed in the baseline:
FAIL NCK_Ly3.f09_g17_gris20.T1850Gg.derecho_gnu COMPARE_base_multiinst(2) Full prealpha testing on derecho and izumi with comparison against cesm3_0_alpha08e
Tests passed except for tests that also failed in the baselines or seemed to have passed due to tweaks made in the baseline (e.g., increasing wallclock time for
SUB_D_Ln9.ne3pg3_ne3pg3_mt232.FHIST.izumi_nag.cam-outfrq9s).Baseline failures were all as expected (except that a few B compset tests failed baseline comparison due to a difference in which cpl.hx.ww3 files were present in the run vs. baseline, which presumably is due to something outside of this PR):
Note that I showed that these differences go away when comparing against baselines generated with #633 , for similar or identical tests.
So I think it's safe to conclude that this is bit-for-bit with #633 .