-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Are changes needed to support a Gregorian (leap year) calendar? #12
Comments
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.commailto: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. — William Lipscomb |
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. |
Thanks for your thoughts, @whlipscomb and @matthewhoffman . I'll leave this open for now, and plan to come back to it later. |
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 On Apr 9, 2016, at 3:52 PM, Bill Sacks notifications@github.com wrote:
|
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. |
@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. |
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). |
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. |
Gunter Leguy and I just discussed this. Two options we can see are:
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. |
From @gunterl on September 13, 2017 17:14 I talked followed up with Bill Lipscomb on this issue. We'd (idealy) like
We believe this to be a good project to work on post CESM2 release and Note on point 2: how do other CESM components handle the leap year with a On Wed, Sep 13, 2017 at 10:30 AM, Bill Sacks notifications@github.com
|
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. |
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. |
Allow longer variable list for files Also, make this a parameter rather than a duplicated magic number.
I imagine that the resolution of ESCOMP/CISM-wrapper#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. |
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
The text was updated successfully, but these errors were encountered: