Add ability to use noleap calendar with gregorian forcing files - #33
Conversation
…files Only adds support to override gregorian with noleap for now. The opposite aborts
0f3ce5d to
276aee9
Compare
Now checks both drop and replay leap year handling
- Updates to use JRA data on vk83/qv56 rather than ua8 - Removes JRA55_v1p4_IAF test config and updates JRA55_IAF and JRA55_IAF_SINGLE_FIELD to v1.4 - Updates instructions in README to use spack
|
I've fixed up the tests, which have been broken in a number of different ways for a long time. This included:
I struggled getting a test environment with working versions of I've also added tests for the new |
|
I ran three consecutive IAF cycles over the 5-year forcing period 1962-1966 (1964 is a leap year) with Some relevant snippets from
Also, ocean and ice diagnostics use noleap calendar: |
anton-seaice
left a comment
There was a problem hiding this comment.
If it's not much work, the older version of the forcing data are in
/g/data/qv56/replicas/input4MIPs/CMIP6/OMIP/MRI/MRI-JRA55-do-1-3
and might be a usecase we care about at some point?
Are there tests for not setting effective_calendar too ?
Sorry - I mean - have you run OM2 with an unmodified calendar / not setting the new namelist value |
Many of the tests do this. But I'll kick off a repro test with ACCESS-OM2 |
I added a |
The default repro tests all pass: ACCESS-NRI/ACCESS-OM2#156 I also ran the 1deg RYF and IAF configurations for 1 month each and checked that the calendars are correct: RYF IAF |
|
Back to you @anton-seaice |
This PR adds an optional
calendar_overrideentry todate_manager_nmlinaccessom2.nml. When set, it takes precedence over the file-derived calendar for both the forcing and experiment clocks. Onlycalendar_override='noleap'with gregorian forcing files is supported - the existing noleap date-skipping logic already handles this by dropping Feb 29 records. The reverse (calendar_override='gregorian'with noleap forcing files) aborts for now.Contributes to #32