Incorrect calendar in MOM output

[russfiedler]

By specifying time units as "days since 0001-01-01 00:00:00" we have problems since calendar="GREGORIAN" refers to a mixed Gregorian/Julian calendar and not the Proleptic Gregorian calendar which is actually used in MOM. In other words times are strictly 2 days off in the mom output files.

There are 2 solutions for the data files.
a) Add 2 days to all the times (Ugh!)
b) Change the time calendar attributes to "proleptic_gregorian"

In the future I would suggest having a starting date after 1582 so that the two versions of calendar match.
MOM/FMS should also be fixed to output the attribute as "proleptic_gregorian" if the start date is earlier than 15/10/1582.

http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#calendar

[russfiedler]

Actually it's a CMIP 6 metadate requirement (17.c) that

Note that if a model has a gregorian calendar and the base time is defined as a date prior to 1582, then the user should specify 'proleptic_gregorian', rather than 'gregorian' for the calendar attribute.

MOM and CICE(?) should be fixed.

[AndyHoggANU]

Hi Russ Yes, I think you’re right - this will explain some the date-handling issues we have been having with the RYF cases. Does this just mean that we shouldn’t trust MOM time-stamps on those runs? Andy PS. Can’t see this issue on GitHub for some reason, hence replying by email … On 22 Oct 2018, at 3:02 pm, russfiedler <notifications@github.com<mailto:notifications@github.com>> wrote: By specifying time units as "days since 0001-01-01 00:00:00" we have problems since calendar="GREGORIAN" refers to a mixed Gregorian/Julian calendar and not the Proleptic Gregorian calendar which is actually used in MOM. In other words times are strictly 2 days off in the mom output files. There are 2 solutions for the data files. a) Add 2 days to all the times (Ugh!) b) Change the time calendar attributes to "proleptic_gregorian" In the future I would suggest having a starting date after 1582 so that the two versions of calendar match. MOM/FMS should also be fixed to output the attribute as "proleptic_gregorian" if the start date is earlier than 15/10/1582. http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#calendar — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#117>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AZg4TMQ9rJUKTxFQkSx7wspwm_4yzEiiks5unUNxgaJpZM4XyzUO>.

[russfiedler]

Hi Andy, I'm not sure what issues you're talking about but if the problem showed up as a 2 day offset then that would seem to be the case. There isn't really an internal issue for mom but this is a problem for any software that tries to use output from MOM and is using the correct defitniion of the calendars. In particular anything that uses udunits will have the dates wrong.
It exposed some problems in Ferret which are going to be adressed too.

No, the RYF output looks fine since it uses the NOLEAP calendar. However all your IAF runs look like they need fixing

e.g.
yes? sp pwd
/g/data3/hh5/tmp/cosima/access-om2-025/025deg_jra55v13_iaf/output147/ocean
...
TIME TIME 24 i 14-JAN-2252 12:00 14-DEC-2253 12:00
...

[russfiedler]

Just confirming that this is an issue for NCO. We need to calculate monthly averages for eta_t but
ncra -v eta_t -d time,"2003-1-1 00:00:00","2003-2-1 00:00:00" ocean_daily_eta_t-2003-01.nc ave_eta_t_date.nc
does not give the same answer as
ncra -v eta_t -d time,0,30 ocean_daily_eta_t-2003-01.nc ave_eta_t_index.nc

where ocean_daily_eta_t-2003-01.nc -> /g/data3/hh5/tmp/cosima/access-om2-01/01deg_jra55v13_iaf/output108/ocean/ocean_daily.nc

Unfortunately, NCO doesn't support proleptic_gregorian, grrrrr..., so I think the best solution will be postprocess the files to have offsets from a post 1582 date. My choices would be 1/1/1900 or the start of the experiment.

[AndyHoggANU]

Thanks Russ.
We are planning to post process the 0.1° data for publication, but obviously have to carefully consider how we do this.

[aekiss]

CICE is using days since run start (not days since 0001-01-01) so presumably time:calendar = "Gregorian" is OK for these.

e.g

ncdump -v time /g/data/hh5/tmp/cosima/access-om2-01/01deg_jra55v13_iaf/output001/ice/OUTPUT/iceh.1985-01.nc

shows time:units = "days since 1985-01-01 00:00:00" ;

whereas

ncdump -v time /g/data/hh5/tmp/cosima/access-om2-025/025deg_jra55v13_iaf_gmredi/output001/ice/OUTPUT/iceh.1960-01.nc

shows time_bounds:units = "days since 1958-01-01 00:00:00" ;

I guess there's no problem having different time units for the different files so long as the metadata allows us to take this into account.

But we need to be careful when overriding the metadata: COSIMA/ACCESS-OM2-1-025-010deg-report@ce3b633#commitcomment-31646163

[AndyHoggANU]

Amended this for 01-RYF case, but should be propagated to all cases.

[aekiss]

@AndyHoggANU, @russfiedler I'd like to propagate this fix across all 10 access-om2-* configs.

Is it just a matter of replacing
1 1 1 0 0 0
with
1900 1 1 0 0 0
on line 2 of diag_table, as in COSIMA/01deg_jra55_ryf@9a10653?

And this should be done for all IAF and RYF configs at all resolutions, right?

[russfiedler]

This only needs to be done for IAF runs. I think it's better to have RYF runs starting at 1/1/0001 to avoid confusion. I think MOM might complain about negative time units too if you start at 1/1/1 but have output referenced to 1/1/1900. It may stuff up other software as well.

[aekiss]

We have set the start date to 1/1/1900 for all the new RYF experiments:

01deg_jra55v13_ryf8485_spinup7
01deg_jra55v13_ryf8485_spinup7_newexe
01deg_jra55v13_ryf8485_spinup8
01deg_jra55v13_ryf9091

and there have apparently been no problems running them.

@AndyHoggANU have you had any problems processing the output?

[aekiss]

These runs all start on 1/1/1900 so there's no negative date problem.

[russfiedler]

Ah! I was just about to look if that was the case. Yep, I reckon that setting the start date for the diagnostics to coincide with the start date of the RYF experiments is the way to go.

[aekiss]

OK great. Is the experiment start date set by forcing_start_date in the libaccessom2 input accessom2.nml? (or maybe that's a question for @nichannah?)

[russfiedler]

Looks like it is

https://github.com/mom-ocean/MOM5/blob/master/src/accessom_coupler/ocean_solo.F90#L249-L266

[aekiss]

OK great, thanks. I've just pushed this fix for all configs.

[aekiss]

I guess we can close this now?

[access-hive-bot]

This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/payu-model-exited-with-error-code-1-aborting-stuck-at-a-leap-year/1038/8