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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Keith.Dixon.vcf
Type: text/x-vcard
Size: 185 bytes
Desc: not available
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20051201/02fc9227/attachment.vcf>
Received on Thu Dec 01 2005 - 15:13:12 GMT
