time counter in BLAZE

[har917]

The time counter in CABLE (or at least parts of CABLE, but not CASA) is carried as an INTEGER number of seconds since 1/1/1700.

Now that we are looking to run past ~2020 we are hitting limits on byte size. This is effectively resetting the clock part way through a run - at least in the output - with unknown and potentially unwanted consequences.

Solutions could involve a combination of:

• documentation of issue for user community
• reworking output to use a different calendar
• reworking the model to use a different clock.

Any changes to core model will require care with interaction between CABLE and UM @ccarouge @JhanSrbinovsky

[JhanSrbinovsky]

How does this affect coupled CABLE?

[har917]

One option to address this would be to go to number of days (not number of seconds) as the time counter - that would require alterations to the coupling (factors of 86400.0 in various places).

At the moment I'm not proposing to do anything to the code - just noting that this is issue.

[JhanSrbinovsky]

Even better :) .

I can imagine that offline keeps track of this in the drivers but I cant picture it in coupled. The only time(s) I can think of are dels(=1800 or 1200 in AM3 [I think]) and ktau(_gl), timestep_number which it gets from the UM.

[ccarouge]

@har917 Can you specify what time counter you are talking about so there is no ambiguity?

[har917]

@ccarouge Time in the model is extremely confusing - what I picked up is that the time in the output from the BLAZE_9184 runs instead of continuing onwards past ~2020 it backtracked to 1860(ish) (at least when picked up by xarray)

for a run from 1951 to 2023 (these plots were demonstrating to me that monthly output from BLAZE == average of the original daily output)

Even more weirdly the spin up run from 1700-1950 gives this

In the BLAZE_9184 branch time in the output is the combination of the calendar attribute (from cable_io_vars) and ktau. At the moment the calendar attribute (when read by ncdump or similar is number of seconds since 1700)

I've checked the time data in the files (via xarray) - for the 1700-1950 run monthly output

• time[0]=numpy.datetime64('1700-01-17T00:00:00.000000000')
• time[815]=numpy.datetime64('1767-12-17T00:25:36.000000000') !so looks kay to this point
• time[816]=numpy.datetime64('1715-05-12T07:31:44.000000000')
• time[817]=numpy.datetime64('2216-07-30T17:06:17.709551616')
• time[818]=numpy.datetime64('2216-08-29T17:08:25.709566616') !so now incrementing okay but odd base time
• time[1365]=numpy.datetime64('2262-03-30T17:05:13.709562616')
• time[1366]=numpy.datetime64('1677-10-09T05:31:44.000000000') !turning clock back
• time[1367]=numpy.datetime64('1677-11-08T17:57:20.000000000')
• time[2448]=numpy.datetime64('1767-12-09T17:33:52.000015000') !jumps back to the second base time here
• time[2449]=numpy.datetime64('1753-12-10T06:56:00.000000000')
• time[2450]=numpy.datetime64('2216-07-22T10:38:01.709562616')

This is all a bit odd - I'm thinking this is something to do with ktau and wrap around of digits. If so then this is a more serious problem (not just in the output) as there are conditions using ktau through the codebase.

However I'm aware that the output has been extensively rewritten in MAIN so this may not be a problem that needs following up.

[har917]

Perhaps lost in the above - I'm now suspecting that there's two things going on here:

• something to do with how the time/calendar is working and this manifesting in the netcdf time attributes (which is then being picked up python/xarray)
• ktau (or - more likely - how it is being used in the time output) hitting a byte limit, leading to the wrapping of values in long runs.

[JhanSrbinovsky]

A Y2020 bug - so its only offline/BLAZE then?

[har917]

@ccarouge @JhanSrbinovsky A follow up - this isn't a CABLE/CASA issue but a BLAZE issue.

1. using decode_times=False in the xarray read changes the picture somewhat (suggesting that the time attributes in the netcdf's are partial explanation). Instead of producing the two clumps of output, a continuum from ~-2 to +2e9 is created (but it still wraps)
2. Time output in the CABLE/CASA files (from the same runs) are okay. This problem is definitely linked to differences in how BLAZE output deals with time vs CABLE/CASA output deals with time.
3. key differences in how the write sections are work appear to be that BLAZE%time is an INTEGER (single precision) whereas time in the CABLE/CASA output is a double precision REAL; correspondingly time in BLAZE output is in NF90_INT, in CABLE/CASA it's a NF90_UNLIMITED.

Net result - I think we need to convert BLAZE%time from an INTEGER into a double precision Real and tweak the BLAZE_write_output routine accordingly. Updating the title accordingly and linking to #529

[har917]

Fixed via b9d0735 - closing issue as solved.

Code will be merged into other branches at later date alongside other developments.