[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[BLDG-SIM] Weather Normalization Question



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@xxxxxxxxx>
To: <BLDG-SIM@xxxxxxxx>
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@xxxxxxxxxxxx> 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@xxxxxxxx mailing list.  To
> > unsubscribe
> > from this mailing list send a blank message to
> > BLDG-SIM-UNSUBSCRIBE@xxxxxxxx
>
>
> =====
> 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@xxxxxxxx mailing list.  To unsubscribe
> from this mailing list send a blank message to
> BLDG-SIM-UNSUBSCRIBE@xxxxxxxx
>
>

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

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