[CF-metadata] Daily mean temperature

From: Seth McGinnis <mcginnis>
Date: Fri, 29 Aug 2014 12:53:27 -0600

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   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
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> 

Received on Fri Aug 29 2014 - 12:53:27 BST