ctsm5.3.021: 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.
Fixes #2923
Resolves ESCOMP/MOSART#66
Resolves ESCOMP/RTM#35

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).

[ekluzek]

@slevis-lmwg the next ccs_config tag won't help as it's unrelated and something about a change for CLUBB. Doing the bisect sounds like a useful thing to do to me.

[slevis-lmwg]

The following PASS in aux_clm despite issue #2310. I imagine they may still fail once in a while, but I do not know...

@samsrabin @ekluzek @adrifoster do you want me to remove these from EXPECTED? I don't think we covered these in this morning's meeting, did we?

    PASS SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Bgc.derecho_gnu.clm-default--clm-NEON-HARV SHAREDLIB_BUILD time=13 (UNEXPECTED: expected FAIL)
    PASS SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Bgc.derecho_gnu.clm-NEON-MOAB--clm-PRISM SHAREDLIB_BUILD time=11 (UNEXPECTED: expected FAIL)
    PASS SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Bgc.derecho_gnu.clm-NEON-MOAB--clm-PRISM RUN time=91 (UNEXPECTED: expected FAIL)
    PASS SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.derecho_gnu.clm-FatesPRISM--clm-NEON-FATES-YELL SHAREDLIB_BUILD time=9 (UNEXPECTED: expected FAIL)
    PASS SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.derecho_gnu.clm-FatesPRISM--clm-NEON-FATES-YELL RUN time=102 (UNEXPECTED: expected FAIL)
    PASS SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.derecho_intel.clm-FatesFireLightningPopDens--clm-NEON-FATES-NIWO SHAREDLIB_BUILD time=10 (UNEXPECTED: expected FAIL)

The following PASS in fates despite issue #2310. Same question.

    PASS SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.derecho_gnu.clm-FatesPRISM--clm-NEON-FATES-YELL SHAREDLIB_BUILD time=15 (UNEXPECTED: expected FAIL)
    PASS SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.derecho_gnu.clm-FatesPRISM--clm-NEON-FATES-YELL RUN time=99 (UNEXPECTED: expected FAIL)
    PASS SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.derecho_intel.clm-FatesFireLightningPopDens--clm-NEON-FATES-NIWO SHAREDLIB_BUILD time=102 (UNEXPECTED: expected FAIL)

[samsrabin]

The NEON ones sometimes pass—it all depends on how cooperative the data server is being. So they should stay as expected fail.

[ekluzek]

@slevis-lmwg yes leave them as expected fails in case they do fail for someone because of network/server issues. It's a signal to them that they can move on. The longer term solution that @adrifoster is endorsing and I agree -- I added to the new issue #2942. Once we get that going we'd be able to remove the expected fail.

[samsrabin]

RXCROPMATURITY tests are now working!

[slevis-lmwg]

RXCROPMATURITY tests are now working!

@samsrabin thank you! Could you tell me the vetted baselines to copy for these tests?

Reconsidering: I will rerun these tests myself due to the ccs_config update shown below. I still would like to point to your baselines for comparison.

I will assume /glade/derecho/scratch/samrabin/tests_0124-161436de unless I hear otherwise.

[ekluzek]

@slevis-lmwg and went over namelist differences as outlined in the Minor version update protocol wiki page with things like:

cd bld/unit_testers
./compare_namelists -b $SCRATCH/ctsm5.3.007/bld/unit_testers/ -pa clm6_0 -pb clm6_0 | & grep -v cnfun_inparm | grep -v upplim_destruct_metamorph | grep -v maximum_leaf_wetted_fraction | grep -v interception_fraction | grep -v paramfile | grep -v clm_canopyhydrology_inparm | grep -v DIFF | grep -v "No case id data available" | grep -v "Namelist diff" | grep -v jmaxb1 | grep -v clm_inparm
./cmp_baseline_lnd_in_files ctsm5.3.007 ctsm5.3.021 | & grep -v cnfun_inparm | grep -v upplim_destruct_metamorph | grep -v maximum_leaf_wetted_fraction | grep -v interception_fraction | grep -v paramfile | grep -v clm_canopyhydrology_inparm | grep -v DIFF | grep -v "No case id data available" | grep -v "Namelist diff" | grep -v jmaxb1 | grep -v clm_inparm | grep -v "hist_"

which highlighted just the namelist differences that were unexpected. We had to do it a few times to figure out what to remove with grep, so unexpected things would pop out. Doing the above helped highlight a few things that we had forgotten about, but realized were expected. And it also helped to ensure we have confidence that the namelist settings are correct and something didn't get changed in a tag to mess them up. This gives us confidence that this tag will be a good starting point for scientists who need to do simulations with a stable version to use with their science. As such it will be marked as a development release tag.

[ekluzek]

@slevis-lmwg I compared the namelists for ctsm_sci ctsm5.3.0 and ctsm5.3.021 baselines and saw the same things that popped out when we looked together. So the completes the namelist validation checking for this tag.

@slevis-lmwg and I also didn't think there was any additional code review that needed to be done by anyone for this. Tags that came in were reviewed and all reasonable ones (in terms of length). And we didn't see anything that seemed likely where a later tag might have messed something up from an earlier one.