Make separate instantaneous and non-inst. history tapes

[slevis-lmwg]

Description of changes

I started from issue #1059 and PR #2019 and am restarting here. From closed PR #2019 I preserved a few things:

• If avgflag /= 'I', time_bounds is present and time = mid of time_bounds
• Some long_name changes
• Treating avgflag as a tape (not field) trait for 'I' and 'L' tapes

In this PR we also intend to split all history tapes into instantaneous and non-instantaneous. The CAM group accomplished this in PR ESCOMP/CAM#903 and we plan to maintain consistency in the appearance of CLM and CAM history files.

UPDATE
Due to higher priority, changing "time" to equal the middle of time_bounds will now get done in
#2838
ESCOMP/MOSART#106
ESCOMP/RTM#39

Specific notes

Contributors other than yourself, if any:
@ekluzek @billsacks

CTSM Issues Fixed (include github issue #):
Fixes #1059

Are answers expected to change (and if so in what way)? No

Any User Interface Changes (namelist or namelist defaults changes)?
We intend to split all history tapes into instantaneous and non-instantaneous.

[slevis-lmwg]

This far I have tried one test:
ERP_D_P48x1.f10_f10_mg37.IHistClm51Bgc.izumi_nag.clm-decStart
The test completes as expected and shows different answers from dev175 only for the "time" variable.

[wwieder]

Conceptually, this seems like a good idea. Practically, this seems like a heavy lift.
I wonder how high a priority it should be for the CESM project and the CLM team?
How critical is this kind of consistency for CESM3?
@dlawrenncar and @briandobbins, could you weigh in here?
@billsacks and @phillips-ad, I think you've thought more about this too?

[phillips-ad]

I think that consistency in the component output of CESM3 is quite important from a user's standpoint. CTSM would be an outlier amongst the 4 major components if these changes were not implemented. Looking at the project page, these changes have already been put into CAM and CICE. MOM came with these settings out of the box. @slevis-lmwg has a couple of pull requests with these changes for MOSART and RTM. I am a bit unclear where CISM is on implementing this. The only component that I know of that will likely not be implementing this is WW.

[billsacks]

I started to write a reply but @phillips-ad beat me to it. The critical piece of this is fixing time values for time-averaged fields so that the time is in the middle of the averaging period instead of at the end. As @phillips-ad says, it is likely to be particularly confusing if CTSM (and the river components) differs from other components in this respect. The separation of instantaneous from time-averaged fields is not a critical piece of this, but seemed like the best way to support having correct time values for both time-averaged fields and instantaneous fields.

[slevis-lmwg]

I started to write a reply but @phillips-ad beat me to it. The critical piece of this is fixing time values for time-averaged fields so that the time is in the middle of the averaging period instead of at the end. As @phillips-ad says, it is likely to be particularly confusing if CTSM (and the river components) differs from other components in this respect. The separation of instantaneous from time-averaged fields is not a critical piece of this, but seemed like the best way to support having correct time values for both time-averaged fields and instantaneous fields.

@billsacks I find the distinction in priority between the "middle of averaging period" task and the "separating instantaneous and non" task very helpful, because the former will take me a few days at most, while the latter will take me a few weeks at least.

[billsacks]

I find the distinction in priority between the "middle of averaging period" task and the "separating instantaneous and non" task very helpful, because the former will take me a few days at most, while the latter will take me a few weeks at least.

Thanks, that's good to know, @slevis-lmwg . I'm curious what the plan is, then, for instantaneous fields? Will you just let the time be incorrect for those fields for now?

@phillips-ad do you agree that getting time correct for the time-averaged fields is the high priority thing here even if instantaneous fields aren't handled ideally for now?

[phillips-ad]

Yes I 100% agree, getting the time set to the middle of the averaging period for time-averaged fields is the higher priority.

[samsrabin]

Just wanted to add: Separating instantaneous and time-averaged fields will probably be an issue for #2061, which adds a namelist option to enable all our history fields and put them all on the h0 file. Depending on which PR comes in first, we'll have to think about how we want to handle that.

[slevis-lmwg]

Just wanted to add: Separating instantaneous and time-averaged fields will probably be an issue for #2061, which adds a namelist option to enable all our history fields and put them all on the h0 file. Depending on which PR comes in first, we'll have to think about how we want to handle that.

Thank you for pointing this out @samsrabin

[slevis-lmwg]

Based on the recent conversation here, I have opened a new PR #2838 that has the same starting point as this one (#2445). The new PR will not make separate instantaneous and non-instantaneous history tapes.

[ekluzek]

Thanks, that's good to know, @slevis-lmwg . I'm curious what the plan is, then, for instantaneous fields? Will you just let the time be incorrect for those fields for now?

@billsacks

Yes, we will let the instantaneous fields be incorrect to start with. And then a later more involved change will fix that.

I like the way that @samsrabin framed this when we discussed this. Right now "I" fields are correct, but "A" fields are incorrect. But, we care more about "A" fields (there's more of them output and they are the standard for most things) so getting them corrected at the expense of "I" fields is an improvement.