Payu potentially miscalculating a leap year

Technical
,
1

I have a student who is running ACCESS-ESM in a paleoclimate simulation. She starts at a virtual year 101, and the model runs fine until the year 400.

In the year 400, at the very end, oasis capitulates with the error message:

oasis_advance_run  at     31536000    31536000   ERROR: t_surf
 oasis_advance_run  ERROR model time beyond namcouple maxtime    31536000
    31536000
 oasis_advance_run  abort by model :           2  proc :           0

31,536,000 seconds is exactly 365 days, but the year 400 is a leap year (divisible by 400), and so the submodels want to keep going just one more day.

Has anyone else experienced this?

Thanks
Holger

1 Like
2

If it is payu I’m surprised it hasn’t been noticed before.

This seems to the relevant section in the payu code

which then calls dateutil.relativedelta.relativedelta

As long as the calendar type isn’t NOLEAP it should rely completely on the dateutil library.

3

It should. But it doesn’t.

I’ve tested it:

from datetime import datetime
from dateutil.relativedelta import relativedelta

start = datetime(year=400, month=1, day=1)
end = start + relativedelta(years=1, months=0, days=0)

print(int((end-start).total_seconds())) # prints 31622400

But the namcouple file in the work directory the value is clearly set to 31536000

The first code snippet of your answer is surrounded by an if clause:

if self.expt.runtime:
    run_runtime = cal.runtime_from_date(
        run_start_date,
        self.expt.runtime['years'],
        self.expt.runtime['months'],
        self.expt.runtime['days'],
        self.expt.runtime.get('seconds', 0),
        caltype
    )
else:
    run_runtime = cpl_nml[cpl_group]['runtime']

I couldn’t figure out what self.expt is in this regard, or what cpl_nml[cpl_group]['runtime'] is for that matter.

4

Hi,
We have had a similar issue with @HIMADRI_SAINI when we get to year 1000 or year 400 of an ACCESS-ESM1.5 simulation. Did anything come of this discussion in terms of a payu or oasis fix?
More importantly, I was wondering if anyone could advise how to switch from Gregorian to NOLEAP calendar for ACCESS-ESM. @holger or @Scott ?
I’m pretty sure I know how the calendar is specified for the ocean, but not the other components.
Regards,
David

5

Python’s datetime shouldn’t be trusted before the gregorian transition, try cftime instead.

UM calendar type will be somewhere in the namelists, for modern UM:

[namelist:nlstcall=lcal360]
compulsory=true
description=Use 360 day calendar
help=Climate users normally use a 360 day calendar to keep months and seasons a
    =standard length. Others will use a normal Gregorian calendar to define the time
    =information in model headers etc.
    =
    =The Gregorian calendar can be used with the coupled atmosphere-ocean
    =climate model. When running the coupled model with the Gregorian calendar
    =ancillaries created for the correct calendar must be used. If the
    ="Use 360 day calendar" option is not selected and the UM atmosphere
    =is not running (i.e. NEMO,
    =CICE,or NEMO-CICE runs),
    =then the model
    =will use a fixed 365-day calendar (no leap days).
ns=namelist/Top Level Model Control/Run Control and Time Settings
sort-key=4b
trigger=namelist:run_aerosol=l_temporal_emi: .false.
type=logical
warn-if=this==".true." and namelist:nlstcall=lclimrealyr==".true."
1 Like
6

Hi Scott,
In the atmosphere/namelists file, I can see the following:

 LCLIMREALYR=.FALSE.,
 LCAL360=.FALSE., 
 LTIMER=.TRUE., 
 L_IO_TIMER=.TRUE.,
 TIME_CONVENTION='Absolute_standard',

The same lines also pop up in CNTLALL and CONTCNTL.
I would guess that namelists is the file that controls everything, but that is just a guess. (If so, why does it appear in the other 2?)

I don’t fully understand what all these options mean. LCAL360 would seem to imply 30-day months, not sure about the other ones.

7

See e.g. /g/data/access/rose-meta/um/um-atmos/vn13.4/rose-meta.conf for what namelist variables mean in the current UM. Yes LCAL360 is for a 360 day calendar, I don’t believe that the UM supports a 365 day calendar.

You are using a very old version of the UM before the namelist files were cleaned up and rationalised in version 10. Settings can be interdependent and appear in multiple locations as you see.

1 Like
8

Thanks for this. Well, if my only choices are 360 day years and Gregorian calendar, I think I will opt for the 360-day years. Others might stick with Gregorian if they have more simulations already advanced… I am early enough in mine that I could pull the plug and switch calendars.

9

Update:
I just came across this utility:

/g/data/access/projects/access/apps/pythonlib/umfile_utils/change_dump_date.py

This gives a method of changing the date in a UM restart file. I think we might try and use this to reset the calendar and hopefully get over this issue with leap years not being in sync.

1 Like
10

Are these paleo simulations?

I ask because the Gregorian calendar implementation in MOM5 is bad. Super-bad.

They even say it isn’t supported

even though they have some code to handle Gregorian, it is buggy

Later versions of FMS, the library that provides this stuff has much improved Gregorian date handling

But that version of FMS isn’t compatible with MOM5.

And there are still some issues.

I don’t know why they wouldn’t just support Proleptic Gregorian, which is much simpler.