Standardize time metadata (we will mark this as the release tag for ctsm5.3)

[samsrabin]

Description of changes

Standardizes a dimension name of output variable time_bounds (from hist_interval to nbnd), as well as attributes for that plus mcdate, mcsec, mdcur, and mscur.

Specific notes

Contributors other than yourself: @billsacks, @ekluzek

CTSM Issues Fixed: Resolves #1693.

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

Any User Interface Changes (namelist or namelist defaults changes)? No.

Testing performed

New metadata in a history file from a short test:

netcdf standardize-time-metadata_rtm.clm2.h0.1850-01-01-00000 {
dimensions:
...
    nbnd = 2 ;
...
variables:
...
    int mcdate(time) ;
        ...
        mcdate:calendar = "noleap" ;
    int mcsec(time) ;
        ...
        mcsec:calendar = "noleap" ;
    int mdcur(time) ;
        ...
        mdcur:calendar = "noleap" ;
    int mscur(time) ;
        ...
        mscur:calendar = "noleap" ;
...
    double time_bounds(time, nbnd) ;
        time_bounds:long_name = "time interval endpoints" ;
        time_bounds:units = "days since 1850-01-01 00:00:00" ;
        time_bounds:calendar = "noleap" ;

All aux_clm tests pass bit-for-bit against ctsm5.1.dev131, except for expected failures.

[samsrabin]

Marked as blocked:dependency because, at the moment, Externals.cfg points to branches of my personal MOSART (issue ESCOMP/MOSART#53) and RTM (issue ESCOMP/RTM#31) forks that contain the same changes. I haven't yet submitted those as pull requests, because I first wanted to see if any more testing is requested.

UPDATE
PRs ESCOMP/MOSART#66 and ESCOMP/RTM#35

[samsrabin]

From CTSM software engineering meeting today: This doesn't need to wait on other time-related PRs. It can come in as soon as the relevant externals are updated (and Externals.cfg here is changed to point to them).

[slevis-lmwg]

Testing includes all three "history" PRs (this one, #2084, #2838) and their mosart/rtm counterparts:

derecho
PASS build-namelist_test.pl
PASS python testing

PASS ./run_sys_tests -s rtm -c rtm1_0_83-ctsm5.3.012_zerothtstep -g rtm1_0_83-ctsm5.3.012_zeroth+stdize_tmeta
OK ./run_sys_tests -s mosart -c mosart1.1.05-ctsm5.3.012_zerothtstep -g mosart1.1.05-ctsm5.3.012_zeroth+stdize_tmeta
OK ./run_sys_tests -s aux_clm -c ctsm5.3.012_zerothtstep -g ctsm5.3.012_zeroth+stdize_tmeta

DIFF ERI_D.ne30pg3_t232.I1850Clm60BgcCropG.derecho_intel.clm-clm60cam7LndTuningModeLDust variable DPFCT_ROCK
...same diff in cprnc.out as in base.cprnc.out from this PR.
Explanation:

1. This diff from the baseline comes from comparing the .rest files, and the restart comparison failed in the baseline. The test does not differ from the baseline when comparing the .base files. So the issue to resolve is not this failure but the restart comparison in the baseline.
2. Also the restart comparison passed here, so the restart comparison failure in the baseline may not be critical to solve, as there is no sign of anything else being affected.

izumi

PASS ./run_sys_tests -s mosart -c mosart1.1.05_ctsm5.3.012_zerothtstep -g mosart1.1.05_ctsm5.3.012_zeroth+stdize_tmeta
OK ./run_sys_tests -s aux_clm -c ctsm5.3.012_zerothtstep -g ctsm5.3.012_zeroth+stdize_tmeta

[slevis-lmwg]

I updated my copy of this branch and its rtm/mosart counterparts with the changes from this commit
eeedbc6
and submitted
./create_test RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput
to see if we need to worry about the failure that I got in this test today in #2838. See follow-up below.

Also
./create_test ERI_D.ne30pg3_t232.I1850Clm60BgcCropG.derecho_intel.clm-clm60cam7LndTuningModeLDust -c /glade/campaign/cgd/tss/ctsm_baselines/ctsm5.3.012
to see if we need to worry about the restart diffs that I got in the zerothtstep branch. Other diffs are expected in this comparison, same as in the zerothtstep comparison I think. CONFIRMED: Yes, diffs from baseline; no diffs in restart.

[slevis-lmwg]

@samsrabin I confirmed that RXCROPMATURITYSKIPGEN_Ld1097 fails with a legit error, due to the updated if-statement that we discussed yesterday from what I can tell. The error I see says:
RuntimeError: Expected 2 timesteps in output but got 1
See here:
/glade/derecho/scratch/slevis/RXCROPMATURITYSKIPGEN_Ld1097.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput.20241121_195614_ddlohd

[samsrabin]

Okay, I'll look into it.