Fixes to some histaux atm2med xml values

[billsacks]

Description of changes

There are three separate but related changes here to the histaux atm2med files:

(1) Put Sa_co2prog and Sa_co2diag on a single file each: These two CO2 fields were both being output to both file4 (3-hourly) and file5 (daily). Based on discussion with @mvertens and @klindsay28 I'm keeping prognostic CO2 just on the 3-hourly file and diagnostic CO2 just on the daily file.

(2) Add Faxa_ndep to histaux_atm2med file 5 (daily) (see also ESCOMP/CTSM#1844)

(3) Change atm2med file5 to actually be daily rather than 3-hourly: My sense from the description and file name is that this file is intended to be daily but was accidentally set to 3-hourly. It was changed from daily to 3-hourly in #378 and I think that may have been a mistake, but I'd like to get confirmation of that from @kdraeder and/or @mvertens .

Specific notes

Contributors other than yourself, if any:

CMEPS Issues Fixed (include github issue #):

• Resolves Add ndep to one of the histaux_atm2med lists #375

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)? Changes some defaults related to atm2med histaux files.

Testing performed

No testing done yet!

[billsacks]

In addition to reviews from @mvertens and @ekluzek , I'd also welcome reviews from:

• @klindsay28 - especially to confirm the changes I'm making here to co2 output on these histaux files, but also for the other changes here since you tend to be thoughtful about cplhist configurations
• @wwieder - to confirm that these changes seem right from the CTSM perspective
• @kdraeder - to confirm my change of histaux atm2med file 5 to daily rather than 3-hourly: I couldn't tell for sure if the change in Aux cpl hist daily #378 was intentional or accidental

Also: I think the changes here may need corresponding changes in CDEPS to get the fields from the right files in cplhist-forced cases. In particular, I noticed that currently CDEPS expects co2diag from the 3-hourly file; that will need to be changed to get co2diag from the daily file. I think other changes will be needed, too, though I haven't looked closely to figure out exactly what. This is a little tricky because I guess we'll want to keep CDEPS as is while we're still pointing to older cplhist data, and then change it once we're ready to point to newer cplhist data. @ekluzek and @wwieder - would this fit in with the plans for ESCOMP/CTSM#1844?

[wwieder]

Yes, I think this makes sense to have daily NDEP from CPL_HIST. From conversations with @olyson it seems like this is what was previously done.

My only question was on timing, specifically if we'd be able to use this for CESM3 spinup, which may be starting soon?

[kdraeder]

• @kdraeder - to confirm my change of histaux atm2med file 5 to daily rather than 3-hourly

@billsacks
I agree that the default should be daily (history_option = 'ndays', atm history_n = 1).
The values currently in there are left over from testing in #378.
Apologies for not noticing them before the merge!

It would be very helpful to maintain the ability to use 'nhours', so I will define a test of that,
which will be included in the tests of DART-related functionality.
Unless it should be part of standard testing.

[kdraeder]

My only on timing was if we'd be able to use this for CESM3 spinup, which may be starting soon?

The accidental change to 'hourly' was part of expanding the capabilities from 'daily',
so daily should still work by changing your input namelists.

[billsacks]

Thanks for your feedback, @wwieder and @kdraeder .

@wwieder - as @kdraeder says, all of the changes in this PR could also be changed via user_nl settings. That said, I'm happy to merge it once it's officially approved. But, if you haven't already, it could be worth doing a more careful review to see if any other changes to these cplhist fields before starting the CESM3 spinup where you're going to want to produce them. It may be worth going so far as to do a short run that produces cplhist output and then verify that a datm cplhist-forced run works with that output (and ideally produces the same climate)... I think that was done in the past, but things have changed since then and I'm not sure how recently this has been carefully reviewed.

[olyson]

Regarding daily vs. hourly/3hourly ndep, I thought we had decided on daily, but I see this issue that has not been closed:

#375

Although I personally think daily is fine...

[billsacks]

Thanks for the pointer to that issue, @olyson ! I'll add a note that this PR will close that issue.

[olyson]

I tend to agree with @billsacks that we should perform another verification test on CPLHIST mode. I had done one in April 2023 with cesm2_3_alpha12c using a coupled case and an uncoupled case that I ran and compared them. We identified several issues at that time and resolved them satisfactorily (mainly with SourceMods and namelist changes).
Those verification results are here:

https://webext.cgd.ucar.edu/F1850/ctsm51_cesm23a12c_ne30pg3g17_CPLHIST_1850_offsetm900_iradswm1_nextswday_sadens/lnd/ctsm51_cesm23a12c_ne30pg3g17_CPLHIST_1850.2_3-cam6ctsm51_cesm23a12c_ne30pg3g17_CPLHIST_1850.2_3/set2/set2.html

I then did another verification in June 2023 using cesm2_3_alpha14a using an AMWG coupled case and an uncoupled case that I ran and compared those as well, results were satisfactory:

https://webext.cgd.ucar.edu/F1850/ctsm51_cesm23a14a_ne30pg3ne30pg3mg17_CPLHIST_VALIDATE2_1850AD/lnd/ctsm51_cesm23a14a_ne30pg3ne30pg3mg17_CPLHIST_VALIDATE2_1850AD.2_3-f.cam6_3_112.FLT1850.ne30.landspinup.001.2_3/setsIndex.html

But, these were done almost 3 years ago.

To do the validation, I added a set of history fields to the model and to the diagnostics package. Those fields appear to be present in the latest model version (I probably initiated a PR for that), but the fields added to the diagnostics package were for the version in the CESM postprocessing tool. these fields are not present in the older diagnostics package I'm currently running (and will be retired soon). I suggest it makes more sense to add these fields to the LDF.

[wwieder]

Thanks for this careful look @olyson can we start another verification test on CPLHIST mode with the current code base?

1. Maybe you can teach @slevis-lwmg and I how to do this? We can take this topic to LWMG_dev.
2. Happy to add diagnostics or variables to LDF, but unsure what these are. Can you create an issue on the ADF repo for this?

[olyson]

Thanks for this careful look @olyson can we start another verification test on CPLHIST mode with the current code base?

1. Maybe you can teach @slevis-lwmg how to do this? We can take this topic to LWMG_dev.

Yep, we can discuss further tomorrow at our liaison meeting.

2. Happy to add diagnostics or variables to LDF, but unsure what these are. Can you create an issue on the ADF repo for this?

Yep.

[slevis-lmwg]

Example of F-case followed by I-case using coupler history:
NCAR/LMWG_dev#138
NCAR/LMWG_dev#139