Deep-dive on time-interpolation in the data atmosphere/runoff stream files

[anton-seaice]

The TLDR: Should we use linear or no time interpolation for incoming runoff fields ?

Splitting this off from #231 for simplicity:

In the drof.streams.xml and datm.streams.xml files, there are spefications for tintalgo - the time interpolation algorithm and offset - the offset between the time in the data file and the time used by the datm model. There is very little documentation on what these mean, but I did find this note from CESM:

2.1 offset in the 3 streamfiles
For ‘coszen’ interpolation (usually for solar forcing), the time-stamps of the data should corre-
spond to the beginning of the interval the data is measured for; for ‘linear’ and ‘nearest’ inter-
polation, the time-stamps of the data should correspond to the middle of the interval the data is
measured for. However, the 3-hr data is placed at the end of the 3-hr period in the coupler history
file (check variables time and time bounds in the data file).
To fix this, offset within the stream files should be set -10800 for ‘coszen’ and -5400 for the
other interpolation method. This becomes an issue because the time-stamps for the 3-hr coupler
history data can be different for different coupled runs. Typical patterns resulting from incorrect
offset is presented in Fig. 1 in comparison to Fig. 2. It is seen that tracks of the diurnal cycle can
be observed in the difference as in the third panel of Fig. 1, and the global-mean net shortwave
forcing is considerably biased to give less shortwave forcing. Similar patterns of difference can
also be observed if the albedo option is set incorrectly, as will be discussed in the next subsection.

Starting with RYF:

DROF:

For our 1990-91 RYF, the frequency is daily, with timestamps at the start of the day:

It's not clear we need linear time interpolation for runoff ... so we can probably just set the time interpolation method to lower and use offset of 0

Global sum of runoff to mediator with no time interpolation, no area weighting:

The alternative is 'linear' interpolation and 43200 seconds offset (0.5 days):

Global sum of runoff to mediator with linear interpolation, no area weighting:

DATM

The frequency is 3 hourly, timestamps are at the start of the interval. We presumably want to keep using linear time interpolation, so we need an offset of 5400 seconds (1.5 hours). This is true for all fields except the shortwave down field, where coszen is correct and offset 0 (as currently set).

IAF:

Annoyingly, the times in the IAF data are different relatively to the averaging period than for RYF ! For IAF, the original Input4MIPS has the timestamp in the middle of the averaging interval.

e.g for ROF:

So the time interpolation can be 'nearest' or 'linear' and no offset is needed. (Currently -43200)

For DATM:

For linear time interpolation, offset should be 0 (currently -5400). For coszen, it needs to be the start of the interval, so it should be -5400 (no change).

[anton-seaice]

Using 'linear' time interpolation for runoff can give differences between the incoming JRA product and the received MOM runoff of 0.1% for some days, although most days are much smaller than this (less than 0.015%). The monthly differences are small (0.0016% for january) and approaching single floating point precision for an annual sum - implying the differences average out over time.

e.g. daily global sums for January (volume per second):

[anton-seaice]

Not using time interpolation for runoff means the JRA & MOM runoff match to close to single point precision.

e.g. daily global sums for January (volume per second) (to match previous post):

[aekiss]

FYI the mismatch between the mean, and mean of interpolated means, is discussed here, with a solution (which I guess is not available in NUOPC) https://dx.doi.org/10.1175/1520-0485(1996)026%3C0136:TIOFFI%3E2.0.CO;2

[anton-seaice]

FYI the mismatch between the mean, and mean of interpolated means, is discussed here, with a solution (which I guess is not available in NUOPC) https://dx.doi.org/10.1175/1520-0485(1996)026%3C0136:TIOFFI%3E2.0.CO;2

I dont think its available but would be straightforward to implement (here). I guess for daily/3 hourly source data the error is much less than the interpolation of monthly data discussed in that Killworth paper ?

[aekiss]

Annoyingly, the times in the IAF data are different relatively to the averaging period than for RYF ! For IAF, the original Input4MIPS has the timestamp in the middle of the averaging interval.

Maybe we should fix https://github.com/COSIMA/make_ryf to retain the IAF timestamp location in RYF to avoid this gotcha?

[aekiss]

There is very little documentation on what these mean

There are also a few crumbs here I guess you've seen https://escomp.github.io/CDEPS/versions/master/html/streams.html

[aekiss]

I guess for daily/3 hourly source data the error is much less than the interpolation of monthly data discussed in that Killworth paper ?

Agreed, so I expect the linear interpolation error will be small enough to ignore.