This page explains how Degree Days.net calculates degree days. If you just want heating or cooling degree-day data, there's probably no need to understand the calculation processes in detail - just use our Degree Days.net tool to calculate the degree days for you. But you might find our answers to these calculation-related questions useful if you're curious, or deciding whether to get your degree days from here or another source, or if you're comparing data from our site with data from elsewhere.
We start with temperature data from Weather Underground. But the type of temperature data we use, and the process we use to calculate degree days from that temperature data, depends on the weather station:
We're already using the Integration Method for the higher-quality weather stations - the ones that matter most. We generally advise people to stick to those stations, and those are the only stations that our API will ever select automatically (if it's asked to supply degree days for a given longitude/latitude or postal/zip code).
Ideally we'd use the Integration Method for all stations, but there are technical obstacles that make that difficult at the moment. A little background is necessary to explain this...
Degree Days.net calculates degree days live. You tell Degree Days.net what data you want, and, while you wait, Degree Days.net assembles the appropriate temperature data and uses it to calculate the degree days you requested. Live data calculation is the only way we can practically offer data with a wide range of customizable base temperatures and breakdowns.
But live data calculation is an intensive process, particularly when using the Integration Method. To calculate a typical set of degree days using the Integration Method our system has to access and churn through many thousands (often millions) of temperature readings.
When we first built Degree Days.net, in Spring 2008, it used an approximation method that worked on daily average/maximum/minimum data. We fetched the temperature data directly from Weather Underground's system, as and when it was needed to calculate a set of degree days. At the time, we didn't think it was really feasible to use the Integration Method on detailed temperature readings, not for live calculations anyway. And, given that the calculation method we were using was a good approximation of the Integration Method, we considered live calculations (and the extensive calculation options they enabled) to be more important than using the Integration Method itself.
However, towards the end of 2010 we came up with a new and improved system design. And we started work on building our own cache of detailed temperature data. We carefully designed and optimized this storage system to enable fast access to long periods of detailed temperature data. Slowly, station by station, we filled this cache with detailed temperature data from Weather Underground's system. And we put systems in place to keep the cache up to date with fresh detailed temperature data.
With this optimized cache of detailed temperature data it was finally practical for us calculate degree days live using the Integration Method. After much work, we launched this new calculation system in August 2011. Our server costs went up by an order of magnitude (even with the optimized cache, using the Integration Method is still a very intensive process), but we consider that a small price to pay for the knowledge that our calculation method is about as accurate as it could be!
The optimized cache currently holds detailed temperature data for all of the airport weather stations, and the higher-quality personal weather stations. If a weather station is listed with a bar and stars next to it (even if they're grayed out), then its degree days will be calculated using the Integration Method and detailed temperature data from the optimized cache. If it doesn't, then its degree days will be calculated using daily average/maximum/minimum data straight from Weather Underground's system.
At some point we'd like to fill the optimized cache with detailed temperature data from the remaining personal weather stations. But, due to the huge volume of data involved, that is not something that can happen overnight. It's also not a priority, as the vast majority of those stations have low-quality data that isn't much good for degree-day calculations. However, if you know of any high-quality personal weather stations that we're not already using the Integration Method for, let us know and we'll see if we can add their detailed temperature data into the optimized cache.
It depends on the weather station. We use the full detail of the temperature data available. For most airport weather stations, temperature readings are taken roughly* every 30 or 60 minutes. Some smaller airports record less frequently. For personal weather stations readings are typically taken more frequently - sometimes as often as every minute or two.
*Many weather-data providers show detailed temperature readings as perfectly-regular hourly figures. But such data is rarely an accurate representation of the temperature readings that were originally recorded by the weather station. For example, airport weather stations typically record a little before the hour rather than on the hour, and they often miss readings, submit erroneous readings, or take additional readings when conditions change quickly. Some airports record more or less frequently than hourly. Perfectly regular hourly or half-hourly temperature data has usually been interpolated into that format. Weather Underground stores the raw temperature readings exactly as they were recorded by the weather station, and those are the readings that we use for our Integration-Method calculations.
If temperature readings were perfect, then more frequent readings would always make for more accurate degree days. However, temperature readings are never that accurate. Automated weather-station thermometers often output data to the nearest 0.1 degree (whether in Fahrenheit or Celsius), but typical estimates put the accuracy of a thermometer reading at around ±0.5 C at best. ±0.5 C (one sigma) is the estimated precision that is published in the NWS guide for ASOS weather-station equipment (used by many of the high-quality airport weather stations in our system). You will also see similar values quoted in research papers and the manuals for other weather-station equipment.
If the ±0.5 C (or thereabouts) was all random error, then accuracy could be improved by averaging lots of temperature readings together (roughly similar to what degree-day calculations do). Good weather-station equipment (like the ASOS equipment) already works to reduce random errors as the published temperature readings are based on a rolling average of observations taken over the few minutes preceding. But much of the inaccuracy in published temperature readings comes from systematic errors, which don't cancel out on averaging. Systematic errors would affect the degree days even if weather stations took an infinite number of temperature readings.
Our testing shows that the inaccuracy introduced into degree days by having 60-minute temperature readings as opposed to much more frequent readings is very small compared to the inaccuracy introduced by the temperature readings themselves. Our tests put it at around ±0.05 F (1 sigma) i.e. pretty much irrelevant.
When there are larger gaps between temperature readings, Degree Days.net interpolates the temperature variation between and assigns the calculated degree days a "% estimated" figure indicating the approximate extent to which the interpolation affected accuracy. These "% estimated" figures are useful as a relative measure for choosing which weather stations to collect data from, but the figures themselves are subject to change and should not be considered a reliable indication of overall accuracy.
Although the Integration Method is the best calculation method for accuracy of the resulting data, and the one that we use for most of our calculations, the vast majority of other sources calculate degree days using an approximation method based on daily summary data (some or all of daily average, maximum, and minimum temperatures). When we can't use the Integration Method for a weather station, we try to use the method that best approximates the Integration Method's results.
There are three popular methods for approximating degree days from daily temperature data:
The first is the Met Office Method - the method that our calculations for the lower-quality personal weather stations are based on (although we use an enhanced version - more on this in a moment).
The other two are both known as the "Mean Temperature Method". They approximate the degree days for each day using the average temperature for the day. For HDD they subtract the average temperature from the base temperature (taking zero if the average temperature is greater than the base temperature on that day). For CDD they subtract the base temperature from the average temperature (taking zero if the base temperature is greater than the average temperature).
This sounds like one method, but it's actually two because there are two commonly-used ways to calculate the average temperature for each day, both of which give slightly different results:
The Mean Temperature Method is a popular one, but we suspect that this is primarily because it involves such simple calculations - it's simple to explain, simple to understand, and, given the necessary temperature readings, pretty much anyone could use it to calculate degree days.
Although the Met Office Method is relatively simple, it's not something that can be explained fully in a sentence or two as it involves several equations...
But the extra complexity is there for good reason: it gives the Met Office Method a big advantage over the Mean Temperature Method. What the Met Office Method can do that the Mean Temperature Method can't is approximate for variations in temperature that occur within those days when the heating or cooling is only needed for part of the day. The fundamental flaw with the Mean Temperature Method is that it assumes that, on any given day, the heating or cooling in a building is either switched on or off. This might have been a reasonable approximation years ago, when heating systems were controlled manually, but it's not appropriate now, when most buildings have thermostat-based control systems that monitor the indoor temperature and switch the heating and cooling on and off accordingly.
We think it makes a lot more sense for Degree Days.net to aim to generate the best results instead of aiming to use the simplest possible calculation process. After all, the point of the site is to generate degree days for you, making the simplicity and explainability of the calculation process irrelevant. So, when we can't use the Integration Method, we make sure to take advantage of the additional accuracy that the Met Office Method offers over the Mean Temperature Method.
The original Met Office Method approximates the daily average temperature by taking the point half way between the daily maximum and minimum. Since we have access to the real daily average temperature (calculated by Weather Underground from readings made throughout the day), we use it instead of this approximation.
On days when the outside air temperature doesn't cross the base temperature:
*We say "almost-identical" because to some extent it can depend on how the average temperature for each day is calculated. If it's a mean value calculated from good, regular readings, the resulting degree days (when the outside temperature doesn't cross the base temperature) will be identical to those calculated using the Integration Method. But the mean temperature can be distorted by erroneous readings that aren't correctly discarded before its calculation, and by irregular readings that represent one part of the day more densely than another (assuming the average isn't calculated as a weighted mean). These differences typically only have a small effect, but they do mean that data approximated using daily average temperatures often isn't quite as good as that calculated using the Integration Method, even when the outside temperature doesn't cross the base temperature.
The choice of calculation method becomes much more important on days when the outside air temperature does cross the base temperature. On such days the Met Office Methods tend to do a much better job of approximating the Integration Method than the Mean Temperature Methods do.
On days when the outside air temperature crosses the base temperature, the accuracy of the Mean Temperature Method is typically very poor. For locations with temperatures that hover around the base temperature, the Mean Temperature Method will typically underestimate degree days significantly. The impact of this inaccuracy depends on the climate and the choice of base temperature.
If you live in a climate where the temperature spends a lot of time hovering around the base temperature, we would advise you to be sceptical of degree days calculated using the Mean Temperature Method. But Degree Days.net doesn't use that method, so it's easy to avoid that particular source of inaccuracy.
Other than that, assuming you're using degree days for the same sorts of purposes as most people (analysis of your building's energy consumption in some shape or form), it's probably not worth worrying too much about the accuracy of the calculation method used.
If you're using data calculated with the Integration Method, then the calculation process is about as accurate as it could be. The Integration Method is the method that the other calculation methods try to emulate.
If you're using data calculated with the Enhanced Met Office Method and are concerned about inaccuracies introduced by that approximation method, we would suggest that you:
Doing these things won't make your degree-day data any more accurate, but it will make it clear that degree-day-based analysis of energy consumption is unavoidably approximate, and that the approximation method used to calculate the degree days is typically only one of many sources of inaccuracy. The significance of the method that your degree days are calculated with will probably pale in comparison to your choice of base temperature, for example.
Most likely you're seeing what we call "recalculation differences". They're a side effect of the way that Degree Days.net calculates its data.
Degree Days.net calculates its degree-day data live, at the moment that you request it. Live calculation is good - it's what makes it possible for us to offer all the options for base temperature etc. It also means that we can improve our calculation engine over time, safe in the knowledge that all data sets generated using that engine (whatever periods they may cover) will be calculated using a consistent process.
But a side-effect of live calculation is that an update to our calculation engine can result in differences between data that you generated before and after the update was made. So you might occasionally notice recalculation differences if you generate a set of degree days, save it somewhere, and then compare it with data that you regenerate at a later date.
There are two main types of update that can cause such differences:
We don't think it's worth worrying about small tweaks to the calculation process - they're very unlikely to make any meaningful difference to the data or to the calculations that you're using it for.
But upgrading a weather station from the Enhanced Met Office Method to the Integration Method is more than just a small tweak, and it can result in noticeable recalculation differences. If you have collected data for a weather station that has since been upgraded to the Integration Method, then it probably would make sense for you to re-generate and replace that previously-collected data if it is easy for you to do so. Data calculated using the Integration Method should be more accurate, and by re-generating the data you previously collected you can take advantage of that increased accuracy for your past data as well as your future data.
That said, we don't want to suggest that it's necessary to re-generate previously-collected data after a station's upgrade to the Integration Method. Degree Days.net has always used a robust, accurate calculation engine, so it's not as if your previously-collected figures aren't good, just that re-generated figures should be better. As we frequently point out, degree-day-based analysis is inherently approximate... It makes sense to use the most accurate data you can, but it's not worth obsessing over relatively small factors like recalculation differences when there are other sources of inaccuracy that are likely to be more significant in your analysis.
Yes, we've certainly thought about it.
Degree Days.net already offers heating degree days, cooling degree days, Celsius degree days, Fahrenheit degree days, and a huge range of possible base temperatures. It makes sense for us to offer all these options as there are strong practical reasons why people need to make use of them.
However, we've yet to be convinced that there would be any value in us offering a choice of calculation methods, especially since the alternatives would all be inferior to the methods that our site is using now (the Integration Method being the most accurate method that we are aware of for stations with detailed temperature records, and the Enhanced Met Office Method being the most accurate approximation method that we are aware of for calculating degree days from daily average/maximum/minimum data).
Plus we're reluctant to make degree days any more complicated for people than they are already...
That said, if there was an approximation method that improved upon the Enhanced Met Office Method, we'd certainly want to think about using it for those stations that aren't yet using the Integration Method. We are in contact with academics that are researching degree-day-calculation methods - if you are also doing such research, we'd love to hear from you too.
Also please do email us if you particularly would like to see a range of calculation methods offered. Although we've explained our rationale for not offering such options at the moment, we'd welcome any persuasive arguments that we might be unaware of.