ERI test; consistency of compset and calendar #1447
Description
What happened?
I set up an ERI test with a spinup compset (F1850C_LT) with the (new) Gregorian calendar modifier (_cG) (was _CG, which led to CIME issue #4811 and CAM PR #1437 ):
ERI_D_C3_cG_Ld8.ne3_ne3_mg37.F1850C_LTso.derecho_intel.cam-outfrq9s_leapday
I expected the test to pass all stages because create_test did not object to this combination.
The test failed due to
/glade/derecho/scratch/raeder/ERI.ne3.F1850C_LT.outfrq9s_leapday_issue/ERI_D_C3_cG_Ld8.ne3_ne3_mg37.F1850C_LTso.derecho_intel.cam-outfrq9s_leapday.20251205_090118_nagcue.ref1/run/PET00.ESMF_LogFile:
ESMCI_Calendar.C:1059 ESMCI::Calendar::convertToTime()
Input argument out of range - ;
Gregorian: for February 1850, dd=29 > 28 days in the month.
It turns out that spinup compsets request a year of data from external forcing files which may not exist in the files, and the code can't find a suitable substitute. In my case this happens because 'F1850...' uses use_case 1850_cam_lt, which specifies using 1850, which is not a leap year. But the testmod for testing the Gregorian calendar specifies a start day of Feb 29, which doesn't exist in 1850.
Note that this grid (ne3) results in 1850_cam_lt choosing the default external forcing files, not the ones selected for the ne30 grid.
What are the steps to reproduce the bug?
See "What happened?" and run create_test using a CESM+CIME+CAM which have the fixes developed in the issues and PRs listed above. These can also be found in
/glade/work/raeder/Models/cesm3.0_testing_PRs2
What CAM tag were you using?
cesm3_0_alpha07g, cime6.1.143-9-g33b54d8e1, cam6_4_128-3-gc8ff6b13
What machine were you running CAM on?
CISL machine (e.g. cheyenne)
What compiler were you using?
Intel
Path to a case directory, if applicable
/glade/work/raeder/Exp/CESM+DART_testing/ERI.ne3.F1850C_LT.outfrq9s_leapday_issue
Will you be addressing this bug yourself?
No
Extra info
The first question is "Should users be able to specify a Gregorian calender with a spinup compset?"
Fundamentally, yes, but practically it's an open question.
It works perfectly well to use a non-Gregorian calendar when repeatedly using the same year to spin up a model. But some users might want to continue after the spinup using Gregorian and might want the spinup and continuations to be consistent.
If this combination should be supported, then the convertToTime failure should be fixed.
If it won't be supported, then I think there should be a check for this incompatibility some time before the run starts, to prevent failures whose root cause is hard to trace. @billsacks suggested that this check could be done in build-namelist, but there may be a better place.
@billsacks and @jedwards4b decided that these questions need to be answered in the components and not in cime