Dear Jon, dear all, Many thanks for raising this issue, and for moving the discussion towards the summary below. Indeed, it is timely to raise this issue. As it happens, within the European IS-ENES2 project we had a small technical workshop last week dealing with closely related issues. Among several other things we discussed the growing season length, start and end of the growing season (but not directly the growing degree days as such). Based on our discussion at the workshop and my own thinking on these matters here are a few comments on your points (same numbering):
1. The standard name for growing degree days should be integral_of_air_temperature_excess_wrt_time. In addition to the Wikipedia reference you give there are very well established definitions of the growing degree days and growing season length provided by the WMO CCL Expert Team on Sector-specific Indices (ET-SCI), and the joint CCl/WCRP/JCOMM Expert Team on Climate Change Detection and Indices (ETCCDI). The crux is that there are alternative (more or less complex) ways of defining the start and end of the period (the wikipedia article is a bit limited in this respect). And as you note, there is not yet a well-established way in CF to describe the day-of-year (or what the correct terms might be). 2. I support this, but also would like to point out that there exist be several alternative temperature thresholds, which are related to specific plants. 3-5. In addition to the day-of-year approach, we may consider the "time_elapsed_since_X" which is neutral in terms of the time unit used, and X would be in relation to a time coordinate variable, as Nan suggests. Others would be much more knowledgeable than I am regarding to the precise CF definition. While the canonical unit for such a variable would be seconds, in this context is would be conveniently expressed as days. If I understand your suggestion correctly the threshold in the tentative standard name "day_of_year_when_growing_degree_days_exceeds_threshold" refers to one or several GDD thresholds, and not one or more temperature thresholds? 6. Note that the ETCCDI definition of the growing season length is in relation to the "climatological year", i.e. 1 Jan -- 31 Dec in northern hemisphere, and 1 July -- 30 June in southern hemisphere. This was something that we particularly worked on at the workshop, but we do not yet have a complete proposal. Kind regards, Lars -- Lars Bärring FDr, Forskare PhD, Research Scientist SMHI / Swedish Meteorological and Hydrological Institute Rossby Centre SE - 601 76 NORRKÖPING http://www.smhi.se E-post / Email: [email protected] Tel / Phone: +46 (0)11 495 8604 Fax: +46 (0)11 495 8001 Besöksadress / Visiting address: Folkborgsvägen 17 -----Original Message----- From: CF-metadata [mailto:[email protected]] On Behalf Of Jon Blower Sent: den 21 mars 2017 17:15 To: [email protected] Subject: Re: [CF-metadata] Recording "day of year on which something happens" Dear all, Many thanks indeed for all the replies to this thread. It seems that there are a few issues here that lots of people would like to resolve! I’m going to try to summarise my take on the discussions here. I’m aware I’m probably missing some important contributions – apologies if so, I’m having trouble keeping up with all the replies. 1. Our specific use case is to record the day of the year on which a given number of “growing degree days” are reached within the year. There are a few ways of calculating GDDs, as this page [1] explains, but it’s essentially some kind of integral of temperature over time. I’m not sure how best to record the exact method used, since I don’t think there are snappy names for the various options that can be captured in a standard name. I guess that we could use a fairly generic standard name (see point 4 below) and use documentation to explain the exact derivation we used. 2. The NetCDF file might record days of year for several “threshold” values of GDD, so I would probably use a dimension to hold all the possible thresholds. (So we can find the day of the year on which 100, 200, 1000 GDDs were reached, etc.) 3. The variable itself would probably be the day of the year, expressed as an integer between 1 (January 1st) and 366. I note the helpful warnings not to refer to this as a “Julian Day” (I’ve made that mistake before!) and I also note Nan’s comment that the Navy might regard day of year as a fractional quantity (so noon on Jan 1st is “1.5”). But I think it’s simplest just to regard the day of the year as an integer number, starting at 1. Doing something else would probably surprise the users (mainly crop growers). 4. So a reasonable standard name, following the precedents cited by Antonio, might be “day_of_year_when_growing_degree_days_exceeds_threshold”. I would imagine that this would be unitless? A comment could contain more information about the method used. 5. Alternatively, we could record the date on which the degree days exceed threshold by using a time variable (with units of “days since X”), meaning that each year’s measurements would contain a different range of data values (year 1 would be [1:365], year 2 would be [366:730] etc. However, this would make it a little harder for users to compare measurements from year to year, which would be a very common phenological use case, so I would tend to prefer the “day of year” option. (I think Nan made a point essentially agreeing with this.) 5. We need a dimension representing the year of measurement. Nothing greater than yearly precision is meaningful here. It seems that the “CF way” of doing this would be to use a “nominal date” within the year of, say, 1st July and record time_bounds that span the length of each year, as was suggested by Jim. But, to be honest, it would be simpler to record the year as a number, without further precision being involved (so the axis values would simply be integers, 2015, 2016, 2017 etc). Also, this would make it much easier for users to “slice out” the year(s) they are interested in using simple scripts, without first needing to figure out what the “nominal date” is within the year. Thoughts? (The question of time precision must have come up before!) 6. Finally, there’s the question of cell_methods for the time axis bounds (if we use them). Jonathan suggested that “if it’s not ‘point’ it should be ‘sum’”. But in this case, although GDD is a kind of sum, the quantity we are expressing (day of year) is not a sum – it’s the day on which the sum reached a certain value. So, I’m still not sure which cell_method might be appropriate. Apologies for the long email, but thanks for listening, and any comments would be much appreciated. Best wishes, Jon [1] https://en.wikipedia.org/wiki/Growing_degree-day _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
