Make sure data models share grid with forcing data?

[mnlevy1981]

trafficstars

When running CESM with datm and an active ocean, you can use either CORE forcing or JRA. The former is available on the T62 grid, while the latter is on the TL319 grid. In MCT, if you try to use the JRA forcing on T62 then CESM aborts with the error

MCT::m_AttrVectComms::GSM_scatter_: myID =     0.  Invalid input, GSMap%gsize = 1036800, lsize(iV) =   64800
shr_mct_sMatReaddnc: Error on scatter of areasrc0
000.MCT(MPEU)::die.: from shr_mct_sMatReaddnc()

I suspect NUOPC will run in this configuration, and map the forcing data from TL319 -> T62 before mapping it from T62 -> TL319.

Proper behavior would be an informative error message, preferable from buildnml, but silently mapping TL319 -> T62 -> [ocn grid] is worse than aborting with a cryptic error

[mvertens]

I this requirement is really only valid for forcing to the ocean. @erik, @billsacks, @jedwards4b - there are cases (particularly if you have input streams at more than one resolution) where this would not be the case. @mnlevy1981 - could you clarify why the mct aborts with the error if you try to run JRA at T62? Its not clear to me why this would not just work.

[billsacks]

Here are the notes from the cseg meeting where we discussed this:

Mike: with mct, a user got a cryptic error when running POP with the wrong atm resolution for the atm forcing.

This raises a bigger issue, even with nuopc: There's nothing right now saying that, if running with POP/MOM with datm, then you should run datm at the resolution of the forcing data. What's the best way to record that metadata?

One answer is that this could be integrated into the extra metadata that Alper talked about recently.

Is there a short-term solution?

• Mariana suggests a check in the cdeps buildnml: if using a JRA stream with datm, then atm model resolution should match the resolution of the stream
• Or, rather than basing this off of the stream, we could check if we're using an active ocean model with datm, and if so, the atm model resolution should match the resolution of the stream.

[jedwards4b]

@mnlevy1981 Can you meet with Mariana and I to discuss.

[mnlevy1981]

@mvertens

could you clarify why the mct aborts with the error if you try to run JRA at T62? Its not clear to me why this would not just work.

I just got off a call with @klindsay28 where we talked about this, and I think we have a better understanding of what is actually going wrong (but there is still some hand-waving in the following explanation). The T62_g37 grid uses the rx1 grid for runoff, but the JRA forcing creates a runoff stream file that uses a domain file with the JRA0.25v2 grid; we think this error is actually an issue with reading the ROF2OCN_LIQ_RMAPNAME because the coupler was expecting runoff to be on the rx1 grid, and the mapping file is mapping to the rx1 grid, but maybe at some point the coupler asked drof what grid it was on and drof told it about the JRA0.25v2 grid?

I created a case in /glade/work/mlevy/codes/CESM/cesm2_3_alpha07b/cases/GIAF_JRA.T62_g37.wrong_datm_grid that doesn't quite reproduce the error from the first post; it's missing the Error on scatter of areasrc0 line because the run dies before returning to shr_mct_sMatReaddnc()... but it does give a traceback:

36:MPT: #5  <signal handler called>
36:MPT: #6  0x0000000001270af7 in m_attrvectcomms_mp_gsm_scatter__ ()
36:MPT:     at /glade/work/mlevy/codes/CESM/cesm2_3_alpha07b/libraries/mct/mct/m_AttrVectComms.F90:1424
36:MPT: #7  0x0000000000fa8fd4 in shr_mct_mod_mp_shr_mct_smatreaddnc_ ()
36:MPT:     at /glade/work/mlevy/codes/CESM/cesm2_3_alpha07b/components/cpl7/mct_shr/shr_mct_mod.F90:549
36:MPT: #8  0x0000000000fadcda in shr_mct_mod_mp_shr_mct_smatpinitnc_mapfile_ ()
36:MPT:     at /glade/work/mlevy/codes/CESM/cesm2_3_alpha07b/components/cpl7/mct_shr/shr_mct_mod.F90:348
36:MPT: #9  0x00000000004e75d0 in seq_map_mod_mp_seq_map_init_rcfile_ ()
36:MPT:     at /glade/work/mlevy/codes/CESM/cesm2_3_alpha07b/components/cpl7/driver/main/seq_map_mod.F90:143
36:MPT: #10 0x00000000004771b3 in prep_ocn_mod_mp_prep_ocn_init_ ()
36:MPT:     at /glade/work/mlevy/codes/CESM/cesm2_3_alpha07b/components/cpl7/driver/main/prep_ocn_mod.F90:316
36:MPT: #11 0x000000000042816a in cime_comp_mod_mp_cime_init_ ()
36:MPT:     at /glade/work/mlevy/codes/CESM/cesm2_3_alpha07b/components/cpl7/driver/main/cime_comp_mod.F90:1930
36:MPT: #12 0x000000000042fbd5 in MAIN__ ()
36:MPT:     at /glade/work/mlevy/codes/CESM/cesm2_3_alpha07b/components/cpl7/driver/main/cime_driver.F90:122

It's notable because PE 36 is the root node for the coupler, while the data models are all running with ROOTPE=0. So this error is coming from the driver rather than datm (or drof). I'm playing around a little bit with attempts to get past this error... but before I go to far down that path, Keith and I will bring this up at an Oceanography Section meeting to see what behavior we expect.

---

@jedwards4b

Can you meet with Mariana and I to discuss.

Sure! My calendar is up-to-date but, per the missive above, it might make sense to wait until after we have a chance to talk to OS about it, though.

[mvertens]

@mlevy - thanks so much for looking into this. I'm not sure how much work its reasonable to do on the mct front given that we are moving away from this. The key point I think is that CMEPS/CDEPS does not run into this problem and I believe gives reasonable results regardless of what resolution you run your atm at. There is no reason why you could not run DATM on the MOM6 grid or keep DATM on the JRA grid. In both cases you will be mapping the data to the ocean grid. There might be reasons why you would prefer one over the other - but neither way would give you unreasonable answers I believe.