Hi Keith
Nice problem. It goes to the heart of discussions I've been having on and off
with Jonathan and others over the last year.
My take on this is that the standard name (in CF language) is not immediately
comparable to canoncial names in other vocabularies. In particular, we make
use of variable attributes to fully characterise a variable.
For example, a variable much loved by the climate impacts community is T_Max
(over some period, a day, a month) ... and we use the cell_methods attribute
to define the averaging period but the variable has a standard name of
temperature.
Using that as a model, I would recommend introducing a new standard name of
degree_day, and using attributes to identify the threshold_temperature and
growing season period. I think this model would deal with the other examples
you introduce.
The question I would have then for our community is how best to use the
attributes. Is this a modification to the cell_method attribute (I would
argue that is the right place to put it).
It's on the to-do list for future CF versions how to make sure that other
vocabularies can interoperate with CF usage like this, and how to make clear
to users of the CF vocabulary how such variables depend on their attributes
as well as standard names to be fully characterised.
Cheers
Bryan
On Thursday 01 December 2005 22:13, Keith Dixon wrote:
> As a CF newbie, I was hoping to be able to run a couple of questions by you
> CF knowbie folks. We are in the process of some diagnostic software work
> where we'd like to diverge from CF (or CF-like) practices as little as
> possible, but are not entirely sure how to accomplish that.
>
> The first question has to do with guidelines for names for variables such
> as accumulated degree days in their various forms (e.g., "Growing Degree
> Days", "Heating Degree Days", "Cooling Degree Days", "Freezing Degree
> Days", etc.). I don't think they're covered in the current CF standard name
> table, and for me, at least, they bring up some interesting questions
> (assuming such variables are of the type that the CF-conventions will
> eventually encompass).
>
> While a relatively simple concept, the various flavors of degree days pose
> some naming issues. There could be a naming building block of something
> like "degree_days" that would be consistent with the AMS Glossary
> definition (http://amsglossary.allenpress.com/glossary/browse?s=d&p=11).
> But there's also the issue of how one identifies the base (threshold)
> temperature (e.g., 0C for freezing days, or 65F for US heating and cooling
> days), and whether the accumulation of degree days occurs when the daily
> mean temperature is greater than the threshold (e.g., cooling DDs) or less
> than the threshold (e.g., heating DDs).
>
> Would names like...
> degree_days_above_65F
> degree_days_below_0C
> ...make any sense in an evolving CF world, or would such names violate some
> basic CF style convention? I assume it makes sense to include the
> threshold temperature info in the name itself (to allow one to distinguish
> between the different DD flavors) or would it be more appropriate to
> document that info in another attribute at the risk of non-unique variable
> names?
>
> The other part of my question has to do with the identification of the time
> period over which degree days may be accumulated (and here I admit to
> getting easily confused by CF and UDUNITS treatments of the time
> dimension). The problem has to do with a single variable that is
> accumulated over 12-month long seasons that are hemisphere dependent. For
> example, national meteorological services can accumulate growing degree
> days and cooling degree days from 1 Jan to 31 Dec in the Northern
> Hemisphere, but from July 1 to June 30 in the Southern Hemisphere. For
> heating and freezing degree days the hemisphere dependent 12-month season
> definitions are offset 6 months from those mentioned in the previous
> sentence.
>
> So, what is one to do when post-processing climate model degree day output
> that will be compared to observational data? Should one create two
> separate variables and files for each degree day type... one for the NH
> grid points and one for the SH ... to accommodate the differing season
> definitions (and perhaps extend the variable name to note the hemisphere of
> interest: e.g., degree_days_above_65F_NH)? Or, should one be able to
> produce a single variable and file containing DD values for all global
> lat/lon grid points and adopt a time axis of, I don't know, say an integer
> year with a convention that the integer year number is that for the
> beginning of the 12 month season?
>
> Though I raise this question after considering degree day seasons, I
> realize that the same issue would apply to the growing season length
> variable that was requested as part of table A4 of the IPCC AR4 data sets
> (http://www-pcmdi.llnl.gov/ipcc/standard_output.html#Table_A4). Degree days
> are found on the STARDEX (http://www.cru.uea.ac.uk/projects/stardex/) list
> of variables
> (http://www.cru.uea.ac.uk/cru/projects/stardex/deis/Diagnostic_tool.pdf),
> as were the 10 variables contained in the IPCC's Frich et al.-based A4
> table.
>
> -Keith
>
> PS - As background, such degree day quantities have the allure to some of
> our customers and researchers in that
> (a) they link a purely meteorological measure [daily mean temperature:
> (Tmin+Tmax)/2 ] to something with more societal relevance (e.g., energy
> use, plant growth, ice conditions) via the use of a base temperature
> threshold, and (b) accumulated over a 12 month season, they serve as a
> wonderful form of data reduction (a factor of 2*365) that, together with
> the use of a base temperature threshold, one can not achieve from
> considering annual mean temperature alone.
--
Bryan Lawrence
Director of Environmental Archival and Associated Research
Head of the NCAS/British Atmospheric Data Centre
CCLRC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence
Received on Fri Dec 02 2005 - 00:35:11 GMT
