[BLDG-SIM] Weather Normalization Question

[Glenn Haynes]

Regarding the weather normalization issue...
A relatively simple way to do rough weather normalization when all you have 
are DB temperatures coincident with the billing periods is to convert to 
CDD and HDD and perform linear regressions to derive coefficients that 
represent kWh per degree-day.  It usually works best to use heating-only 
months and cooling-only months independently for HDD and CDD, and ignore 
the swing months.

The degree-days may be defined to coincide monthly with the billing cycle 
or the billings may be converted to calendar months.  In the  first case 
you also need degree-days that represent calendar months to subtract from 
degree-days you get from the TMY weather year.  Then you multiply the 
monthly differences between TMY and your calendar degree-days (some 
differences will be negative) by the regression coefficients and add these 
to the actual calendarized monthly utility bill kWh.  Thus you get billing 
data that mimic what would have been billed on a calendar month cycle 
during a TMY weather year to calibrate your model against.

If you don't already have a good handle on the best CDD and HDD base 
temperatures, try 72 for CDD and 65 for HDD, and you will be close in most 
cases.  Caution: if you prefer to use degree-hours in lieu of actual 
degree-days, you should also use different base temperatures, typically a 
few degrees higher for CDH and a little lower for HDH.  If the heating 
system doesn't depend heavily on electric equipment that respond to outdoor 
temperature, attempts to derive an HDD coefficient might be futile or 
misleading (a negative coefficient is a dead giveaway), and it might be 
better to just live with the unadjusted monthly kWh for the heating 
season.  If you can get two or three years of billing history and 
coincident temperatures, you can use all to derive better regression 
coefficients, but you have to calculate the average (of these years) 
calendarized monthly degree-days to subtract from the TMY degree-days to 
normalize.

I love to calibrate DOE2 models, but it can get sticky if you are shooting 
for really close agreement on both monthly kWh and kW.  If that's your 
goal, your greatest needs will be "mo data" and "mo time", and, sigh!, the 
method above might not be the best start.

Happy calibration!
Glenn Haynes,
RLW Analytics, Inc.


At 05:25 PM 3/11/2003 -0800, you wrote:
>The US and Canadian weather services have both gone from manual to automated
>observations (ASOS = Automated Surface Observing System or AWOS = Automated
>Weather Observing System) starting in 1991, but most since 1997.  At this
>point, I believe all stations have switched over to ASOS/AWOS.  The biggest
>problem with the ASOS/AWOS data for building simulations is the lack of
>observations from which solar irradiance can be estimated. There is reported
>cloud cover, but this a laser observation that "sees" clouds only up to
>12,000 feet.  Moreover, the correlation of this new data to the previous
>manually observed cloud cover data on which almost all solar models have
>been based is unknown.  Because of this problem, ASHRAE TC 4.2 (Weather
>Information) initiated last year a research project to develop a method or
>methods for estimating solar from either ASOS/AWOS data or from other
>sources, such as satellite observations.  This project (1226-RP "Integration
>of ASOS Weather Data into Building Energy Calculations with Emphasis on
>Model-Derived Solar Radiation" )  is expected to be completed early next
>year (2004).  Until then, people trying to do calibrated simulations using
>actual year weather data will likely encounter a big data hole starting from
>1997.
>
>Joe Huang
>Vice-chair of ASHRAE TC 4.2
>
>
>----- Original Message -----
>From: "Michael Wilson" <mwilsonbc at yahoo.com>
>To: <BLDG-SIM at gard.com>
>Sent: Tuesday, March 11, 2003 1:21 PM
>Subject: [BLDG-SIM] Weather Normalization Question
>
>
> > Regarding the first comment from Dave Robison, I've
> > received the weather data in WYEC2 format from
> > Environment Canada, including solar, wind, etc.
> > However, the last time I had to do this was for a 1999
> > weather year, and I understand that recent automation
> > of the weather stations may make this data harder
> > (impossible?) to come by. But without this data, how
> > are you making the calibration?
> >
> > And although I've only calibrated a few of these, not
> > hundreds, I'm not sure I'd agree that the model
> > doesn't need to be detailed and it's a low cost
> > simulation. If you don't put a fair bit of work into
> > making sure the simulation of systems is reasonably
> > similar to the operation of them, then you're not
> > calibrating, you're just matching the bills. And while
> > your model might line up nicely with the bills, if
> > your end-uses or hourly profiles are off its not going
> > to be so useful for running further simulations on.
> >
> > --- Dave Robison <drobison at teleport.com> wrote:
> > > for the most part, I have been lurking on this group
> > > because, unlike you
> > > designers, our specialty is calibrated models. We've
> > > done hundreds of them,
> > > and there are very few doing such.
> > >
> > > >I order up a years worth of weather
> > > >data for the most recent year and convert it to
> > > Doe2
> > > >format.
> > >
> > > I don't see how one can do that. At best, you can
> > > set the actual
> > > temperature data into a TMY file. But you still have
> > > the old solar,
> > > humidity, wind speed etc. Now those data are
> > > completely incompatible with
> > > the hourly set of temperatures. Or do you have
> > > source for those other
> > > weather data? I don't believe they are being
> > > measured anymore.
> > >
> > > >To calibrate models to reality, you must also watch
> > > out for what's
> > > >included in the utility bills.
> > >
> > > Yes, you have to include things like parking lot
> > > lights, if applicable.
> > >
> > >
> > > >And, of course, there's the difference between how
> > > equipment is supposed
> > > >to operate and how it actually operates
> > >
> > > As-built and as-operated. That's the whole point of
> > > a calibrated model. The
> > > process of calibration often reveals operational
> > > opportunities for further
> > > savings. As such, it is a low-cost commissioning
> > > tool.
> > >
> > > >Calibrating models entails either incredibly
> > > detailed investigation of
> > > >the actual building,
> > >
> > > nonsense. If you have only limited reference data
> > > (monthly bills), you
> > > don't need a detailed hourly model. A monthly
> > > simulation works fine and is
> > > a whole lot easier.
> > >
> > > >or else application of the black art of making
> > > >informed guesses ("engineering judgment").
> > >
> > > Any modeling involves informed guesses -- eg) how do
> > > you model passive
> > > infiltration? At least with the calibrated model,
> > > you have a reality check.
> > >
> > > >  In our experience, there's a
> > > >significant portion of models that just won't
> > > calibrate, because the
> > > >actual energy use is too strange and resources to
> > > investigate why are
> > > >not infinite.
> > >
> > > Not so. The monthly bills are a cheap resource and
> > > the simulation cost is
> > > minimal. The only ones we have had to reject were
> > > because the metering was
> > > at a different level of aggregation.
> > >
> > >
> > > >The real objective of generating reasonable energy
> > > savings estimates,
> > > >however, can still be met if the model is overall
> > > reasonable.
> > >
> > > How do you define reasonable? If fact, we have found
> > > that using actual
> > > weather, rather than TMY, may be necessary to
> > > resolve the model sufficiently.
> > >
> > > >  It's the
> > > >delta in energy use attributable to the efficiency
> > > measures of interests
> > > >that matter, not necessarily tracking down all the
> > > unusual quirks of
> > > >utility metering and billing systems.
> > >
> > > Yeah, but if you don't have the building defined,
> > > can you be sure of the
> > > calculated delta? At least if you start with a
> > > calibrated model, then move
> > > off it incrementally, you have some confidence that
> > > the deltas are reasonable.
> > >
> > >
> > > >Using a whole building simulation can be a big
> > > >improvement on that practice.
> > >
> > > Absolutely
> > >
> > >
> > > ====================
> > > David Robison
> > > Stellar Processes
> > > 1033 SW Yamhill Suite 405
> > > Portland, OR 97205
> > > (503) 827-8336
> > > www.ezsim.com
> > >
> > >
> > ======================================================
> > > You received this e-mail because you are subscribed
> > > to the BLDG-SIM at GARD.COM mailing list.  To
> > > unsubscribe
> > > from this mailing list send a blank message to
> > > BLDG-SIM-UNSUBSCRIBE at GARD.COM
> >
> >
> > =====
> > Michael Wilson
> > 455 Elphinstone Ave.
> > Gibsons, BC, V0N 1V1
> > 604-886-9864 phone
> > 604-676-2604 fax
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Web Hosting - establish your business online
> > http://webhosting.yahoo.com
> >
> > ======================================================
> > You received this e-mail because you are subscribed
> > to the BLDG-SIM at GARD.COM mailing list.  To unsubscribe
> > from this mailing list send a blank message to
> > BLDG-SIM-UNSUBSCRIBE at GARD.COM
> >
> >
>
>======================================================
>You received this e-mail because you are subscribed
>to the BLDG-SIM at GARD.COM mailing list.  To unsubscribe
>from this mailing list send a blank message to
>BLDG-SIM-UNSUBSCRIBE at GARD.COM

======================================================
You received this e-mail because you are subscribed 
to the BLDG-SIM at GARD.COM mailing list.  To unsubscribe 
from this mailing list send a blank message to 
BLDG-SIM-UNSUBSCRIBE at GARD.COM