Managing time in CABLE

[SeanBryan51]

There are a number of situations in CABLE where the behaviour of the code is determined by the time of the current time step. For example:

1. Timing of writing output and aggregating data in time
2. Timing of running CASA-CNP at the end of every day
3. Timing of CASA-CNP input/output
4. Timing of running POP at the end of every year

Potential differences in how time is managed throughout the model makes it difficult to synchronise functionality which happen at specific frequencies. This was highlighted recently by @Whyborn in #655 when looking into how output variables are aggregated and updated in time. It would be great if there were a centralised approach to managing time in CABLE which could provide time related information consistently. This information could include:

• The current time step index
• Whether the previous, current or next time step is the last or first time step of the hour, day, month or year
• Whether the current time step is the last time step
• The date and time of the previous, current or next time step
• The type of calendar being used

We can take inspiration from other models which follow a similar idea:

• next_time_mod in JULES
• clm_time_manager in CTSM/CLM

Relevant libraries:

• datetime-fortran library used in some access models could be useful for computing dates and times

[Whyborn]

I did a quick test of the datetime-fortran module and it's really easy to trigger things at given intervals. A construction like:

type(datetime) :: t, t_next
type(timedelta) :: dt
integer :: year

dt = timedelta(days=0, hours=0, minutes=30)
t = datetime(year=1995, month=1, day=1)

do while (t%getyear() <= 2005) ! Run until end of 2005
  t_next = t + dt
  if ((t_next%gethour() == 0) .and. (t_next%get_minute() == 0) then
    write(*,*) "It's the end of a day"
  end if

  if ((t_next%get_month() == 1) .and. (t_next%get_day() == 0) .and. (t_next%get_hour() == 0) .and. (t_next%get_minute() == 0)) then
    write(*,*) "It's the end of a year"
  end if
end do

The checkers can get a bit verbose, but they can be wrapped if that's a problem.

One issue is that it currently only supports leap year calendars, but support for other calendars could be added. A benefit of this is that we already have an SPR for it.

[Whyborn]

Can we bring this in before bringing in the PIO stuff?

[SeanBryan51]

Absolutely, for the PIO work (#655) the goal is just to reproduce the existing timing behaviour. There should be no issues if this enhancement is brought in before hand

[Whyborn]

I've made a fork of datetime-fortran to include different calendars here (side note, their testing procedure is interesting. I'd say it's simpler than fortuno, but not as featured). I've made on the issue on the upstream asking whether they have any interest in other calendars, since they may just say "we don't want it".