Are changes needed to support a Gregorian (leap year) calendar?

[billsacks]

From @billsacks on April 8, 2016 1:25

For now this is more of a question than an issue... we can change it into an issue if it seems warranted:

Do people feel that any changes are needed for CISM to support a Gregorian (leap year) calendar? Typically CESM operates with a NOLEAP calendar, but some applications use it with a Gregorian calendar.

I'm pretty sure that CISM currently assumes a 365-day (no-leap) calendar (e.g., the scyr parameter is hard-coded to 365 days). I could imagine this possibly causing small errors both in terms of averaging quantities sent to / from the climate model, and also in terms of the number and size of the dynamics timesteps that fit within a year.

There are really two questions:

(1) Are people concerned about the small (but systematic) errors this will cause?

(2) Might the current assumptions cause any major problems, such as causing the run to crash?

This one will probably take some experimentation. I'm not sure how to test this, which is part of my motivation for filing this as an issue to come back to later.

Copied from original issue: E3SM-Project/cism-piscees#54

[billsacks]

cc @whlipscomb @JeremyFyke @matthewhoffman

[billsacks]

From @whlipscomb on April 8, 2016 3:4

HI Bill,

I’m not worried about having inaccurate sea level projections or model diagnostics on account of a 0.1% error in the length of the year. But I wonder if exact conservation could be broken if, for example, CLM computes a given SMB (in kg/m^2/s) over a 366-day year, and then CISM applies that SMB over a 365-day year. Maybe the coupler manages things correctly, but I’m not sure.

I don’t know whether the current assumptions would ever cause a run to crash. I’ve always found the Glimmer/Glint timestepping to be confusing, and sometimes I’d like to be able specify the number of timesteps in a year instead of setting dt to some decimal portion of a year. So a question would be whether the overall timestepping scheme would be worth reviewing and maybe revising before the CESM2 release.

Thanks,

Bill L.

On Apr 7, 2016, at 7:25 PM, Bill Sacks notifications@github.com<mailto:notifications@github.com> wrote:

For now this is more of a question than an issue... we can change it into an issue if it seems warranted:

Do people feel that any changes are needed for CISM to support a Gregorian (leap year) calendar? Typically CESM operates with a NOLEAP calendar, but some applications use it with a Gregorian calendar.

I'm pretty sure that CISM currently assumes a 365-day (no-leap) calendar (e.g., the scyr parameter is hard-coded to 365 days). I could imagine this possibly causing small errors both in terms of averaging quantities sent to / from the climate model, and also in terms of the number and size of the dynamics timesteps that fit within a year.

There are really two questions:

(1) Are people concerned about the small (but systematic) errors this will cause?

(2) Might the current assumptions cause any major problems, such as causing the run to crash?

This one will probably take some experimentation. I'm not sure how to test this, which is part of my motivation for filing this as an issue to come back to later.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/ACME-Climate/cism-piscees/issues/54

---

William Lipscomb Los Alamos National Laboratory Group T-3, MS B216 Los Alamos, NM 87545 505-667-0395

[billsacks]

From @matthewhoffman on April 9, 2016 2:20

@billsacks , thanks for bringing this up. Like @whlipscomb said, I'm not concerned about the small discrepancy between Gregorian and Gregorian_no_leap, except if conservation is an issue. If it is and we need to add flexibility, I would vote for keeping it as simple as possible - e.g., a run-time configurable scyr variable or something like that. I fear an overhaul of the timekeeping would become a substantial undertaking, and I don't think it would be a good use of time.

[billsacks]

Thanks for your thoughts, @whlipscomb and @matthewhoffman . I'll leave this open for now, and plan to come back to it later.

[billsacks]

From @JeremyFyke on April 11, 2016 14:30

Hi Bill,

I am trying to imagine when a Gregorian calendar would be preferable to a simpler NOLEAP calendar. Perhaps if one was doing a multi-millenial year run where orbitals were varying, the loss of 5 hours 48 minutes 46 seconds (difference between a NOLEAP and a Gregorian year, which Google tells me is itself 26 seconds off the true solar year) could cause a strange forcing drift. But I don�t think we should worry about that yet - so I�d definitely vote for sticking with the simpler NOLEAP calendar for now.

Given that, if it were up to me I would probably go for the simplest solution to keeping NOLEAP consistent - like, building a fatal error throw within glc_comp_init that kills any coupled run that attempts to run with a Gregorian calendar.

Jeremy G. Fyke Theoretical Division (T-3) Los Alamos National Laboratory Los Alamos, New Mexico 505-606-0025

On Apr 9, 2016, at 3:52 PM, Bill Sacks notifications@github.com wrote:

Thanks for your thoughts, @whlipscomb and @matthewhoffman . I'll leave this open for now, and plan to come back to it later.

� You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[billsacks]

From @stephenprice on April 11, 2016 14:32

I'd argue for whatever is the minimum that needs to be done so this doesn't become a problem. Overhauling time stepping / time keeping in general sounds like a lot of work that we don't really have the scope for right now.

[billsacks]

@JeremyFyke : It's not so much that we'd want to run with a Gregorian calendar ourselves, but rather that others want to do it. The main reason I'm aware of is when you're doing an application that involves direct comparisons with data, such as data assimilation, in which case you don't want to simply exclude every Feb 29.

[billsacks]

From @JeremyFyke on April 11, 2016 15:53

@billsacks - right, I agree for data assimilation experiments, for sure. But: I don't personally see a coupled CESM application that includes both dynamic ice sheets and data assimilation (or more generally, year-on-year comparisons to data, instead of comparisons of averaged climatologies). That thought process led to the idea of simply killing the model with an 'ice sheets+Gregorian capability not enabled' message, if someone requests both of these features at the same time (instead of taking the time to build out Gregorian capability in the ice sheet model for no clear objective).

[billsacks]

This is an issue within CESM: http://bugs.cgd.ucar.edu/show_bug.cgi?id=2507

We probably need to do a complete overhaul of CISM's time manager at some point, for this and other reasons.

[billsacks]

Gunter Leguy and I just discussed this. Two options we can see are:

1. Give CISM a more sophisticated time manager / calendar handling

2. Add an argument to a top-level CISM subroutine that allows the driver to pass in the current year's length

However, either of these will probably require some pretty significant changes, in order to change some things that used to be constant to instead be time-varying.

[billsacks]

From @gunterl on September 13, 2017 17:14

I talked followed up with Bill Lipscomb on this issue. We'd (idealy) like to:

1. Align time management in CISM on what other model components are using.
2. Allow a more dynamical time step (for leap years).

3. Modify the constraint on the time step dt. Problems might occur if dt is either different from a fraction of 1 or different from a multiple of one.

   We believe this to be a good project to work on post CESM2 release and will be helpful for deeper code cleanup.

Note on point 2: how do other CESM components handle the leap year with a time step of 1 year. Do they keep dt = 1 for that year or does it become dt = 1.0003 (this way scyr can remain fix)?

On Wed, Sep 13, 2017 at 10:30 AM, Bill Sacks notifications@github.com wrote:

Gunter Leguy and I just discussed this. Two options we can see are:

1.

Give CISM a more sophisticated time manager / calendar handling 2.

Add an argument to a top-level CISM subroutine that allows the driver to pass in the current year's length

However, either of these will probably require some pretty significant changes, in order to change some things that used to be constant to instead be time-varying.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ACME-Climate/cism-piscees/issues/54#issuecomment-329223530, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0K-AH4vC3kfaE3rZL-Un7vTpDbJJ9Pks5siAMsgaJpZM4ICnrT .

[billsacks]

Note on point 2: how do other CESM components handle the leap year with a time step of 1 year. Do they keep dt = 1 for that year or does it become dt = 1.0003 (this way scyr can remain fix)?

I think CISM is the only component whose time step is longer than 1 day. Other components have time steps that divide evenly into a day, so on a leap year they simply run more time steps. I agree that this will require some careful consideration for CISM. My initial inclination is that it probably makes sense to use a slightly longer time step on leap years, which is inconsistent with other model components, but seems to make the most sense given CISM's use of time steps greater than 1 day.

[billsacks]

From @jhkennedy on September 14, 2017 9:13

One benefit of removing the calendar assumptions, or at least isolating them to a module, is that it would make implementing adaptive time stepping much easier.

Post-CISM2 release, it might be worth adding that as a goal to the time-stepping clean up, which shouldn't require too much additional work, and might make the clean up effort more (scientifically) worthwhile.

[billsacks]

I imagine that the resolution of https://github.com/ESCOMP/CISM-wrapper/issues/75 will likely require a conversion from common_years to days that will need to be revisited when we want to support a Gregorian calendar.