Hi Karl,
Thanks for your suggestions.
The complicating factor is that, as a result of crediting the maximum temperature to the previous day (but crediting the minimum temperature to the current day), the mean temperature is actually the average of values from two *different* 24-hour periods. For example, the mean for today will be the average of a) the minimum for the 24-hour period *ending* at 09:00 this morning, and b) the maximum for the 24-hour period *starting* at 09:00 this morning (a value which will only be recorded tomorrow morning and then credited to the previous day i.e. today). See also the example in my original posting.
It may seem a strange method but it makes sense when you consider that the max will typically occur mid-afternoon whereas the min will generally occur around dawn i.e. the process of 'throwing back' the maximum temperature (only) ensures that most of the time you will be computing the average of a min and a max that occurred within the same calendar (midnight-to-midnight) day.
Given the calculation method, setting the bounds to either one of the two constituent 24-hour periods would be arbitrary and inaccurate, and to give the bounds as a 48-hour period would probably be even worse. Consequently midnight-to-midnight seemed like the only viable option for mean temperature, but with the downside that the three temperature variables would then be dealt with in different ways (with the possibility for confusion this implies).
I hope that helps to clarify the issue. Regarding the solution, we had some further discussion here yesterday and concluded that Seth's suggestion to set the bounds to midnight-to-midnight for all three temperature variables (and with a time coordinate of midday) is a better option. However your idea to give more information in brackets is a good one and could be used for max and min as well e.g.
cell_methods = "time: maximum (observing period is 0900 on day D to 0900 on day D+1)
cell_methods = "time: minimum (observing period is 0900 on day D-1 to 0900 on day D)
The only thing we are still wondering about is whether to use 0900-0900 or midnight-to-midnight for daily precipitation (the former being the true observing period). For temperature the diurnal cycle means that the 0900-0900 observations are a pretty good estimate of the true calendar-day max or min (in many cases the values would be identical). The same is not true for a cumulative variable such as precipitation, so we think that sticking to the true bounds of 0900-0900 may be a better option, even though it would be slightly at odds with the approach for temperature. To ensure at least some consistency I suspect we would still specify a time coordinate of midday (the same as for temperature).
If you/anyone else has further comments or ideas then please let me know.
Thanks,
Dan
________________________________
From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Karl Taylor
Sent: 11 September 2014 00:44
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Daily mean temperature
Hi Dan, Seth, and all,
I'm not sure I understand what the practice is; do you calculate the daily mean from the max and min temperature that you read at 0900 GMT. If so, then I think it is straight-forward: the max and min temperatures occurred in the 24 hour period ending at 0900 GMT, and the "daily mean" is the mean of those 2 temperatures by definition and would apply to the same interval. I would simply indicate, as provided for by CF, that the mean is computed as the mean of only the max and min values recorded. So
cell_methods = "time: mean (estimated from mean of the maximum and minimum temperature observed)"
All measurements would have the same bounds. So, for example, a measurement recorded on 13 August 2013 would have bounds for both the max and min temperature of: 2013-08-12 09:00, 2013-08-13 09:00. The coordinate value should be somewhere within the closed interval defined by the bounds, and if you choose the mid-point, then you'd record 2013-08-12 21:00, but you could also choose noon of that day if you like (or any other time).
I wouldn't worry too much about which day the WMO "credits" the temperature measurement to. I would record the information correctly (as above). I would say this describes your estimate of daily mean with complete accuracy.
For monthly means, I would record the bounds as beginning at 0900 of the first day of the month and extending through 0900 of the first day of the next month. Again this is an accurate description of what the mean represents (within the limitations of computing a mean over 24 hours from the max. and min. found in that period). This interval would also apply to daily tmin and tmax.
Does this make sense?
Karl
On 9/3/14, 3:50 AM, Hollis, Dan wrote:
Hi Seth,
Many thanks for your comments and good advice.
On the one hand I was keen to use the cell methods and bounds to describe the data as accurately as possible, but on the other hand I want to be sure that users can find the data they need easily and unambiguously. Given that it seems impossible to describe our daily mean temperatures with complete accuracy some compromise is going to be inevitable. I'm now swayed by your argument that inconsistency is dangerous and that we can use the comment attribute to flag up the true nature of the data. Using midnight-to-midnight bounds will also be less confusing for our monthly means of daily tmax and tmin (if I use 0900-0900 bounds for the daily values the month will end up starting and ending 24 hours earlier for tmin compared with tmax).
I'll wait to see if anyone else has alternative suggestions and will also discuss this again with my colleagues. I'll let you know what we decide.
Dan
-----Original Message-----
From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Seth McGinnis
Sent: 29 August 2014 19:53
To: cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu>
Subject: Re: [CF-metadata] Daily mean temperature
Hi Dan,
Your proposed solution is consistent with regard to the time
coordinates, but inconsistent with regard to how that coordinate relates
to the time bounds, and I think that's dangerous.
Users are going to assume that these files all have the same
representation, and will treat them as identical when they run them
through various processing tools. If the time coordinate is at the
beginning of the period for one variable and the end for another, then
when you run something like "ncks -d time,2013-08-01,2013-09-01" on
those files, you'll get back different sets of days for Tmin and Tmax.
Ambiguity is also a problem with time representation, and for that
reason I recommend always putting the time coordinate somewhere in the
interior of the time_bounds period, not at one of the ends. If it's in
the middle, you generally don't have to worry about it, but if it's at
the end, you have to remember which end, and it's just too easy to get
it wrong. (And when it does go wrong, it can go invisibly but
catastrophically wrong. I once generated a climatology where one of the
"years" being averaged over was actually a single 3-hour timestep
because of this problem...)
I think your colleague is correct. Although the reporting period runs
0900-0900, by following the WMO guidance you're implicitly adjusting
your data to match the calendar day, i.e., to have a midnight-midnight
period.
So putting all that together, my recommendation would be to set
time_bnds to run midnight-midnight, and to set the time coordinate to
noon on the corresponding day for both Tmin and Tmax. Plus that solves
the problem of what to do about Tavg - it's also at noon.
(Note that the Tmax record will now start a day earlier than the Tmin
record; personally, I would also trim off the first day of Tmax and the
last day of Tmin so that they're identical in that regard, too. Because
a lot of users don't look at time *or* time_bnds, they just count array
indices from the beginning of the file...)
If you want to record the fact that the original reporting period was
9AM-9AM, I would do it in a human-readable global comment. There's no
standard governing that, but the CMIP requirements use an attribute
named "comment" for this kind of thing. So something like:
:comment = "Original reporting period was 9am-9am GMT, but following
WMO guidance effectively adjusts this to 0Z-0Z."
Cheers,
--Seth
----
Seth McGinnis
NARCCAP Data Manager
Associate Scientist III
RISC / IMAGe / NCAR
----
On 8/29/14 6:19 AM, Hollis, Dan wrote:
Hi all,
Here is the third in a series of questions relating to our work on
converting gridded UK observations data to NetCDF...
As many of you will know, climatological observations made in the UK
have traditionally been gathered at 0900 GMT. These include maximum
temperature, minimum temperature and precipitation amount.
We follow the guidance given in the WMO Guide to Climatological
Practices which states:
"Precipitation amounts and maximum temperatures noted at an early
morning observation should be credited to the previous calendar day" (p2-13)
The implication is that minimum temperatures should be credited to the
calendar day of the observation. This all makes sense as the max will
typically occur mid-afternoon whereas the min will generally occur
around dawn.
So, for an arbitrary calendar day (e.g. 13 August 2013) the cell bounds
would be:
Minimum temperature: 2013-08-12 09:00, 2013-08-13 09:00 (cell_method:
minimum)
Max temp and precip: 2013-08-13 09:00, 2013-08-14 09:00 (cell_method:
maximum and sum respectively)
We also follow the WMO guidance regarding the calculation of daily mean
temperatures:
"the recommended methodology for calculating average daily temperature
is to take the mean of the daily maximum and minimum temperatures" (p4-18)
The problem we have is how to describe the daily mean temperature, given
that it is the mean of values from two different 24-hour periods.
One possibility is to simply interpret it as an estimate of the true
mean temperature for the calendar day in question, and thus specify the
bounds as midnight-midnight i.e.
2013-08-13 00:00, 2013-08-14 00:00 (cell_method: mean)
For consistency we propose specifying the value of the time coordinate
to be the same for all variables i.e. 2013-08-13 09:00 (which is 09:00
on the calendar day to which the observations are credited - it is the
end point of the minimum temperature bounds, the start point of the
maximum temperature bounds, and part way through the proposed mean
temperature bounds).
One colleague wondered whether it would be better (less confusing to the
user) to consider all of the values to be estimates for the calendar day
and therefore give all of the variables (max, min, mean and precip) the
same midnight-to-midnight bounds (even though the actual observation
period is different to this).
If anyone else has had to tackle this type of issue I would be very
interested to know what approach you followed. Alternatively if anyone
can give advice on how to correctly describe a mean value calculated in
the way I have described that would be much appreciated.
Thanks,
Dan
PS We will also need to store monthly means and climatological averages
of all these variables. I thought I'd start by asking about the daily
quantities and see where the discussion led...
Dan Hollis Climatologist
*Met Office* Hadley Centre FitzRoy Road Exeter Devon EX1 3PB
United Kingdom
Tel: +44 (0)1392 886780 Fax: +44 (0)1392 885681
E-mail: dan.hollis at metoffice.gov.uk<mailto:dan.hollis at metoffice.gov.uk> Website: _http://www.metoffice.gov.uk_
For UK climate and past weather information, visit
_http://www.metoffice.gov.uk/climate_
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140911/452b7470/attachment-0001.html>
Received on Thu Sep 11 2014 - 08:59:34 BST
