[BLDG-SIM] Matching utility meters

[Chassin, David P]

[Normally I snip most of the original message, but Paul's entire message is
important and I left it below]

It sounds like we agree and I'm really enjoying the discussion.  I didn't and
won't dismiss the use of energy calcs for estimating savings for the reason you
cite: it's the best we've got.  But as you suggest, I recognize their
limitations.  They've got to be used on the right jobs and in the right way to
be of real value.  As such, I do not expect to get the current generation of
simulations to match the utility meter.  We have access to extensive collections
of utility meter and submeter data and I have seen little evidence of progress
since the data seriously started to come in over 20 years ago.  We use these
engines (especially DOE-2 and BLAST) very extensively and we think we know their
strengths and weaknesses pretty well.  In the past year we have run and analyzed
the output of around 5000 parametrically generated models for various jobs and
in past years that number has reached the neighborhood of 20000 models per year.
We've learned where these models can go and where they can't go.  We're stilling
learning very significant lessons today.

In my humble opinion the crux of the matter for calculating savings is that even
if I could know when a 2x4 is stuck in a damper (which is hard enough to
predict) just about every energy calcs engine is unable to model the problem or
calculate its impact.  We have not been able to get most of the engines to
correctly model the impact of the most common problems (e.g., bad temperature
sensors, stuck dampers, improperly programmed controls, failed cooling
interlock) on economizer operation.  We learned this lesson when we tried to
generate the test data sets to verify that our diagnosticians could detect all
the problems we were looking to find. Yet as we field test the diagnosticians we
discover that these occurrences are prevalent and we are surprised how often
they go undetected by experienced operators.

Now consider the way we calculate savings (simplified of course):

	Savings = PredictedCost(Bad) - ActualCost(Good) - ActualCost(Fix)

where for good or bad operation

	Cost(X) = Rate * Simulated_Consumption(X)

In the good old days the difference between bad and good was mostly in the
basics: lights, insulation, efficiency of the HVAC, and windows and doors.
These are all things for which energy engines generally estimate impacts well,
whether for Cost(Bad) or Cost(Good0.  However, as more and more buildings get
the basic improvements made or are simply built to meet better standards, the
more difficult to model things become more significant relative to the basics.
Now the Cost(bad) part of the equation begins to break down because most energy
engines cannot even guess what might be the impact of improper sensor location,
manufacturing flaws, incorrect installation, setup/config oversights, or naïve
operation.  Unfortunately these are not the exception, rather they are the rule.
Moreover they are the targets of interest to those in the performance
contracting business because they can be very easy/inexpensive to fix and can
have dramatic cost impacts.  As a result modelers (particularly the more
virtuoso among us) find work-arounds for these conditions in order to match
actual metered data to predicted meter readings. I believe (based mostly on my
intuition) that these proxies push the models "out of bounds".  They were never
designed to model incorrect building design or operation and should not be used
that way.  The very impact an ESPC wishes to affect cannot be estimated
directly.

Bottom line for me: if I don't know the problem is there or I can't estimate the
impact of a problem, I certainly can't match the utility meter in a realistic
way, no matter how hard I try.  Like I said before, if I do match the meter,
it's by changing something else that probably has nothing to do with the problem
I intend to fix in order to obtain savings.

To go back to John Aulbach's pain, many people feel it and I don't think there's
much that can be done to alleviate it today.  Every time I consider using an
energy calcs engine to estimate savings I have to remind myself that everything
looks like a nail when I'm holding a hammer.  I know that in this case a hammer
is sometimes all I've got, but that does make using it always right.  If I've
got to use it, I need to swing very carefully.

One last point about the modeling language I feel the need to make because it's
a subject near and dear to me as I work the IAI on the Industry Foundation
Classes.  The problem is not only in the language, but in the basic
methodologies driven by the language.  Most engines generally do not separate
the control strategy simulation from the thermal and air-flow simulation of
models.  Because of this, they cannot consider the wide range of conditions that
can cause improper operation and can result in the models "going out of bounds".
There a lot of very good reasons for this.  But take a seemingly simple problem:
a bad temperature sensor.  It is extremely difficult (and I believe impossible
but I'm still waiting to be proven wrong) to simulate the impact of this problem
on the economizer control signals using the most popular energy savings
calculation tools.  Thus the bad behavior of the economizer cannot be replicated
correctly.  Therefore the savings obtained by correcting this problem cannot be
quantified well using such engines.  Once the problem with the methodology is
remedied, then we could be talk about whether and how the language needs to be
modified.

Cheer up.  We're still way ahead of the game.

Regards,
Dave,

David P. Chassin
Staff Scientist
Pacific Northwest National Laboratory
Richland, Washington
509-375-4369
david.chassin at pnl.gov <mailto:david.chassin at pnl.gov> 

Disclaimer: The facts above are based on memory proven faulty on numerous
occasions, and the opinions are not those of my employer or its clients even
though I sometimes wish they were.


	-----Original Message-----
	From:	Paul Reeves [SMTP:paulreeves at att.net]
	Sent:	Saturday, January 29, 2000 07:02
	To:	BLDG-SIM at gard.com
	Subject:	[BLDG-SIM] hornets nest? Stay the course !!

	I really must take some exception to your dismissal of using DOE2 to
calculate energy savings.  After all, what do you think people use DOE2, or any
other energy simulation program, for?
	 
	We have done far more projects using DOE2 to estimate energy savings
than I care to think about.  The answers produced by the analysis must be taken
with some caveats, but in general, they are the best available estimate of
savings reasonably attainable.  Part of what you are getting at, I believe, it
the fact that people's behavior on an individual scale is unknowable and that
generalized answers do not necessarily apply to specific cases.
	 
	In a commercial building this may manifest itself in the fact that part
of a building is unexpectedly unoccupied, or that the facilities guy stuck a 2x4
in the outside air damper to get rid of "that stink in suite 302".  If you did
not anticipate these factors, then of course the energy prediction will be less
accurate.  On the other hand, if you could predict these factors, then DOE2
would have no problem accounting for them.  If you want to conduct an energy
savings analysis for a specific building, an audit is really required.  If you
enter an accurate description of the building and its operation, then DOE2 does
an extremely good job of predicting its energy use.  And that is what DOE2 is
intended to do.  It, of course, cannot predict deviant and unexpected behavior
in the building operation on it's own ... the person modeling the building must
do this.
	 
	If you apply savings analysis for a "typical" small office to a specific
building operating under specific conditions, then yes, there is and should be
significantly less confidence in the answer.  This is an issue for the analysis
itself, and is not a limitation of the analysis tool.
	 
	In residential buildings, this phenomena is even more evident.  We have
used DOE2.2 to predict the energy flows of residential homes throughout the
U.S.. These houses were operated under test conditions, and actual energy flows
were measured using co-heating and co-cooling techniques.  The test protocol
included adding/removing window shades, decreasing/increasing duct loss,
increasing/decreasing ventilation rates, etc..  Time after time, the analysis
using DOE2 was able to predict the hourly energy flows of these houses within a
very small error band (on the order of 1 or 2 percent).  This required a
detailed model, including all the site and self shading for that individual
house.  But given detailed and correct inputs, DOE2 has no problem predicting
accurate hourly energy use.
	 
	Now, add real people to these houses and all bets are off!  It is
impossible to predict the individual behavior of people.  Just think, 20 years
ago there were two popular singers, the wholesome Michael Jackson and the
apparently perverse "Prince".  Who could have predicted that Prince would turn
out to be the straight family guy and the other one would become ... well,
"Michael Jackson".  Put both these guys in a house and try and predict the
energy use ... no way!  Luckily, group behavior is much easier to predict and
estimates of typical energy use are possible, even for residential buildings.
	 
	We've been using DOE2.2 for a couple years now, and I encourage anyone
using DOE2.1 on a regular basis to check it out.  The systems/plant is much more
flexible now and organized in a far more logical way.  On the loads side, the
use of polygons to describe spaces makes detailed models far easier (it took me
awhile to realize the advantages of this approach, but once I made the switch
the time savings became very evident). The addition of "expressions" to the BDL
language makes for the possibility of some extremely "smart" BDL code.  Okay
okay, the possibility still exists of producing BDL code that thinks it's really
smart, but really has a 2x4 stuck in the wrong place.
	 
	Paul Reeves
	The Partnership for Resource Conservation
	140 South 34th Street,  Boulder, CO 80303
	(303) 499-8611 
	 
	----- Original Message ----- 

		From: Chassin, David P <mailto:David.Chassin at pnl.gov>  
		To: BLDG-SIM at gard.com <mailto:BLDG-SIM at gard.com>  
		Sent: Friday, January 28, 2000 11:28 AM
		Subject: [BLDG-SIM] hornets nest? Stay the course !!

		"And for the retrofit industry, I STILL gotta match the utitliy
meters...."
		I don't think we have any hope of ever achieving that with
today's tools (or
		even those that are in the works).  Our simulation tools can't
simulate *all*
		the stupid mistakes and failures that are made in building
design, construction,
		and operation.  The only time you'll get your output to match
the utility meter
		is if you tweek something else that probably has nothing to do
with reality.
		This is just one of the things that give me pause when people
talk about using
		DOE-2 (or any other engine in existence) to simulate buildings
in order to
		estimate savings.  We *know* the model is wrong because it can't
simulate a 2x4
		stuck in the makeup vane of an economizer by a frustrated
operator trying to get
		some fresh air in a building with a messed up economizer control
he can't figure
		out.  These kind of things happen all the time.
		Dave
		
		David P. Chassin
		Staff Scientist
		Pacific Northwest National Laboratory
		Richland, Washington
		509-375-4369
		david.chassin at pnl.gov <mailto:david.chassin at pnl.gov>  <
mailto:david.chassin at pnl.gov <mailto:david.chassin at pnl.gov> > 
		
		Disclaimer: The facts above are based on memory proven faulty on
numerous
		occasions, and the opinions are not those of my employer or its
clients even
		though I sometimes wish they were.
		
		
		-----Original Message-----
		From: John Aulbach [ SMTP:jaulbach at sna.sempra-esco.com
<mailto:SMTP:jaulbach at sna.sempra-esco.com> ]
		Sent: Thursday, January 27, 2000 14:09
		To: BLDG-SIM at gard.com <mailto:BLDG-SIM at gard.com> 
		Subject: [BLDG-SIM] hornets nest? Stay the course !!
		
		[snip]
		
		And for the retrofit industry, I STILL gotta match the utitliy
		meters....
		
		
		
		======================================================
		You received this e-mail because you are subscribed 
		to the BLDG-SIM at GARD.COM <mailto:BLDG-SIM at GARD.COM>  mailing
list.  To unsubscribe 
		from this mailing list send a blank message to 
		BLDG-SIM-UNSUBSCRIBE at GARD.COM
<mailto: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