New CISM time management aborts for leap years

[billsacks]

Bill Sacks < sacks > - 2017-09-05 12:41:58 -0600 Bugzilla Id: 2507 Bugzilla CC: fyke, lipscomb, mvertens,

A few months ago, Mariana and I put in new CISM time management, where the coupler averages to a year before sending values to CISM. We put in place the following error check to ensure that CISM gets inputs at the time it expects them - because if the coupler and CISM are out of sync, CISM may be running with very wrong forcing values (e.g., always running with 0 values):

else if (time - av_start_time + params%time_step == params%tstep_mbal) then  

   if  (.not. valid_inputs) then
      write(message,*) &
           'Valid_inputs cannot be .false. if trying to do a mass balance time step'
      call write_log(message,GM_FATAL,__FILE__,__LINE__)
   end if

However, Louisa Emmons ran into a problem trying to run with a Gregorian calendar:

---

I am trying to run compset FCSD from 2011-2016, and seem to have gotten stuck because 2012 is a leap year. I guess I could just switch to a 365-day calendar.

My case run directory is: /glade/scratch/emmons/cesm2alph07_FCSD_09x1_TS1mamsoa/run which used source code in: /glade/p/work/fvitt/cesm/cesm2_0_alpha07c/

These are the log error messages: glc.log: WARNING: GLINT will not handle leap years correctly!!! ...

• FATAL ERROR : (glad_main.F90:650) Valid_inputs cannot be .false. if trying to do a mass balance time step

cesm.log: 189: * FATAL ERROR : (glad_main.F90:650) Valid_inputs cannot be .false. if trying 189: to do a mass balance time step 189: Exiting with fatal error: this_rank = 189 0: PARALLEL STOP in glimmer_log.F90 at line 180

Indeed, I don't think we tested this with a Gregorian calendar. CISM has never run correctly with a Gregorian calendar, but we've tried to make sure that it doesn't abort.

We need to determine how to get back to a situation where at least it doesn't abort.

Solutions I can see are:

• Fix the problem robustly to allow gregorian runs with cism, by changing cism's time management

This would likely be a lot of work, and isn't favored by CISM folks, because they have no need for it.

• Bypass the above error checks if running with a Gregorian calendar

This might work, but I think we'll get more and more out of sync over time, which might cause some other problems.

• Some kludgey change to CISM's time handling to sort of do the right thing when running with a Gregorian calendar

This would be non-trivial because of the complexity of CISM's time handling - though would likely be easier than a full, robust reimplementation of time management in CISM.

e.g., we could temporarily modify tstep_mbal and related variables in leap years. It may not do exactly the right thing, but we could probably get it to do approximately the right thing - e.g., still running the CISM dynamics at the end of each year, whether or not it's a leap year.

• Get CLM working with glc_mec with SGLC. Then don't allow CISM with a Gregorian calendar, but provide this alternative so you can run a reasonable glc_mec configuration with a Gregorian calendar.

This is probably my preference (because we want this SGLC support for other reasons, too), as long as there aren't too many people who want to be able to run with a Gregorian calendar.

[billsacks]

Bill Sacks < sacks > - 2017-09-08 12:44:35 -0600

The decision at the CLM-CMT meeting Tuesday was to go with this solution for CESM2, deferring a robust handling of Gregorian calendar in CISM until post-CESM2:

• Get CLM working with glc_mec with SGLC. Then don't allow CISM with a Gregorian calendar, but provide this alternative so you can run a reasonable glc_mec configuration with a Gregorian calendar.