Project

General

Profile

cdo daymean

Added by Jennifer Brauch over 6 years ago

Hello,

I try to calculate a daily mean value of 6hourly data. My data has the time stamps 6, 12 18, 24, ....
I understand, that I have to shift the time to include 24 on day 1, which I did, with a simply cdo shifttime,-3hours.
Now my time axis looks like this:
time = 3, 9, 15, 21, ...

Then I perform the cdo daymean separately. When I look at my time variable it looks like this:
time = 12, 36, ....

Which seems perfect for me, as the time in the centre is chosen. But I have time_bnds which look like this:

time_bnds =
3, 21,
27, 45,

Why are the bounds +/- 9hours for a daymean calculation? I do understand how it happened. The routine takes the times of the first and last entry of the day as the margins, but this seems to be weird for a daily mean value. How can I change this?

And I have an additional question. What is the difference between cdo daymean and cdo dayavg? I did not find an explanation for this in the documentation.

Many thanks in advance for any help given!

cdo -V
Climate Data Operators version 1.8.2 (http://mpimet.mpg.de/cdo)


Replies (3)

RE: cdo daymean - Added by Ralf Mueller over 6 years ago

the bounds contain the first and the last timestep, that was taken into account while computing the mean value. So, 3, 21 is the correct counds array for the first timestep (i.e. the first day) IMO.

I think you cannot change this with CDO. Could be possible with ncap/ncap2 from the NCO package, though. Please, not that you wanted to use 24 o'clock! What bounds do you expect/want to see?

mean and avg operators do missing value handling differently, see page 16 (chap. 1.7) of pdf-docu.

hth
ralf

RE: cdo daymean - Added by Jennifer Brauch over 6 years ago

Hello Ralf,

thank for your fast answer. I need the timebounds to look like this, i.e.:
1-Dec-1949 12:00:00 (2 bnds: 1-Dec-1949 00:00:00 -> 2-Dec-1949 00:00:00)

Which is the most logical way to define time bounds for a daily average. For me it is not clear why the time bounds should end in +/- 9 hours centered around 12:00.

Here is the text from "cordex_archive_specifications.pdf", Section 4:
Variables that are representative for an interval (averages, maxima, minima) must
use the midpoint of time intervals as time coordinate values and furthermore must
have a time_bnds field of dimensions (ntimes,2)^k, where ntimes is the dimension of
the time coordinate. The time_bnds values for daily, monthly and seasonal data
should be on 00:00:00 UTC or multiples of 3 and 6 hours from that time for 3
hourly and 6 hourly data, respectively. Seasonal-mean data are defined with
standard seasonal boundaries (DJF, MAM, JJA, and SON).

So I will try to set my bounds with ncap. Thanks for the hint!

Jenny

RE: cdo daymean - Added by Ralf Mueller over 6 years ago

Hi again!

Since you know how to tweak your data, I think the issue is solved. So what I write next is more a nice-to-have-my-2ct-I-cannot-resist-to-say

IMO part of the initial cause of the inconsistency is your interpretation of 24 hours after the reference data being 24 o'clock. Cordex seem to use 00:00:00 as a reasonable timestep - this implies that there is not such thing as 24 o'clock.

I dont know, what timesteps of instantaneous fields were taken into account for computing averages that were labeled with 6,12,18,24. Could be that the last timestep was used. or was it the middle timestep for the time-mean interval?

It could be that your the time-bounds will be computed as you need them, if you shift the initial time axes by 6 hours. it might be useful to check the environment variable CDO_TIMESTAT_DATE (see apendix A, page 205)

cheers
ralf

    (1-3/3)