[Bldg-sim] historic weather files for model calibration

[mark dewsbury]

Hi Guys,

 

YES - The thermal modelling of residential buildings is significantly
affected by the use of non site measured / synchronised weather
observations. 

 

In our empirical validation research we have found only the occasional day
where the air temperature may be the same but the Solar radiation values
(Global, Direct beam & Diffuse) are considerably different. But generally,
there were significant difference (between 4 & 7 Deg C) in the min & max
values on a daily basis. 

 

At a recent meeting with a government agencies in Australia, I raised
concern with regard to the general flattening of the min & max values that
appears to occur in the development of the TMY file. It is these times of
min & max when cooling or heating models are invoked & energy is used. 

 

Mark Dewsbury

Centre for Sustainable Architecture with Wood
School of Architecture
University of Tasmania
Locked Bag 1324
Launceston 7250
ph: 03 6324 4089
mob: 0417 290 807
fax: 03 6324 4088
e: mark.dewsbury at utas.edu.au

  _____  

From: Hwakong Cheng [mailto:hwakong at hotmail.com] 
Sent: Wednesday, 1 December 2010 9:08 AM
To: david.j.reddy1 at gmail.com; adahlstrom at in-posse.com;
bldg-sim at lists.onebuilding.org
Subject: Re: [Bldg-sim] historic weather files for model calibration

 

Hi Aaron,
 
Building your own weather file can be difficult and tedious, especially
gathering the appropriate solar data. Here are a couple alternatives that
may be appropriate depending on the specific context of your project:
 
1 - Compare the heating and cooling degree days between your performance
period and the TMY weather. If you have multiple years of utility data and
associated weather data, the weather variations each year might average out
to be very similar to the TMY. If they are moderately different, you could
attempt to adjust modeling results based on this difference?
2 - If you create a custom weather file for a short performance period (e.g.
one year or less) and tune your model to the utility data from that period,
then your results are only applicable to performance during that period.
Maybe that's what you want. A different way to look at it would be to
generalize the results to a typical year (i.e. the TMY weather). One method
is to develop regression fits of measured energy use as a function of
outside air temperature. For example, graph hourly hot water use against
measured hourly outside air temperature and do a curve fit. The relationship
is generally linear but perhaps with a change-point (where the slope
changes). With the regressions, you can apply these relationships to the
weather data in the TMY file to generalize the measured energy use to energy
use during a typical year. Thus, calibrating a TMY-based energy model to the
normalized baseline would be an apples to apples comparison and the results
would be generalized to typical conditions rather than just the specific
conditions during your performance period. There's more to it, but that's
the general gist. 

Also, there was a great spreadsheet tool that was shared on bldg-sim a
couple years ago that used macros to automatically gather and compile actual
(hourly or even sub-hourly) weather data from weather stations on
www.wunderground.com. But no solar data. I use this tool exclusively now for
gathering real weather data. 
 
Good luck,
Hwakong
 

  _____  

Date: Mon, 29 Nov 2010 22:09:48 -0800
From: david.j.reddy1 at gmail.com
To: ADahlstrom at in-posse.com; bldg-sim at lists.onebuilding.org
Subject: Re: [Bldg-sim] historic weather files for model calibration

Aaron- 

The question "are model results significantly impacted by the difference
between historic weather data and performance-period data" is a complex one,
however, here is an approach that may be helpful if you need to construct
your own custom weather file.

You can purchase historical weather data available from NOAA station data
from the NCDC <http://www.ncdc.noaa.gov/oa/ncdc.html> .  However, these data
sets do not include solar radiation data and often need some QC work (remove
extraneous observations, fill gaps, etc).  In the past, I have also
downloaded weather data from the EnergyPlus
<http://apps1.eere.energy.gov/buildings/energyplus/weatherdata_download.cfm>
site in IWEC format, and converted to .bin using a combination of the E+
weather data processor and EPW conversion tool available on the DOE-2
Website <http://doe2.com/index_Wth.html#eQ_WthProc> .  However, although a
great deal (a FREE service), in my experience, this data can have gaps that
are too large to fill with the algorithms NREL prescribes, which then leads
you to either piecing this together w/ some other data source, or, only
evaluating the model performance over the periods you have data for.  For
many of my projects, I need a complete year or more, so the E+ method was
not ideal.

I recently created some DOE-2 .bin weather files using the following
approach, using data formatting/calculation procedures automated in MATLAB,
and then the "DOEWth.exe" utility (an older, command line program also
available from DOE-2.com) to generate a .bin weather file.  Once automated,
this process can be completed in a relatively short period of time. The
following is a brief explanation of the process I used that may give you
some ideas:

1)  Downloaded NOAA data (Integrated Surface Data) for closest site.

2)  Cleaned data of extraneous points and filled gaps in data using NREL
<http://apps1.eere.energy.gov/buildings/energyplus/pdfs/weatherdata_guide_34
303.pdf>  filling routines.  There is usually always one or more
observations recorded for every hour, however, in many cases one or more of
the variables you need for the simulation weather file may not have been
reported.  

If you can obtain measured solar data for your location, skip steps 3-5

3)  Used the Zhang-Huang solar model (discussed in the E+ engineering
manual) to estimate total horizontal solar radiation with custom model
parameters developed using least-squares regression to TMY3 data.  In this
case, I assumed TMY data was more or less "true", however, for one station
data I worked with, I noticed some cloud cover observations did not appear
to be consistent the reported solar radiation data.  However, the custom
coefficients yeilded better results than the default coefficients reported
in the E+ literature when I compared the model output to a short sample of
actual measured solar radiation data I had.  

4)  Used another model to determine the diffuse solar radiation component
from the total global radiation.  In my case, I used a custom model
developed for the Pacific NW (published in a thesis) however, there are many
similar models developed from various datasets.  Orgill and Hollands is a
popular model, although they are all very similar.

5) Once you have the two solar components above, direct normal solar
radiation can be readily calculated.

6) With all of the necessary data now assembled, format into the TMY2 format
for processing into a .bin file using the DOEWth utility.  Using the DOEWth
output summary file and a weather file plotting program, like D-View, you
can "inspect" the measured data to make sure it matches what you expect and
aligns with daily or month averages more readily available.

A few notes:
- The DOEWth utilty does have format methods that will calculate solar data,
however, I choose to pre-process the solar data using the solar radiation
models I preferred, which leads you to using the TMY2 format method.
- I did not calculate illuminance data since my project did not include
daylighting controls.  There are models available for calculating
illuminance, and the DOE-2 program may use a model to estimate it from solar
radiation data (need to brush up on this section of the engineers manual to
confirm this). 
-  Related to the above comment, there are many different models out there
for calculating solar radiation/illuminance data from other measured
parameters. I choose the above because I felt like the models best captured
the variables that I thought were important, and to  lesser degree, I could
readily implement them in my programming.  Other than comparing these models
to actual TMY data, I have not rigorously compared these model to others
available, so you may want to explore others.  
- For any source of weather data you pursue, I would emphasize reviewing how
data is filled and non-measured variables are calculated (i.e. what models
were used).  

I just realized this post may use the word "model" a record number of times,
but hope you find it useful.



David Reddy
 
360 Analytics
Building Energy Analysis Consultants
mail:   12354 16th Ave NE, Seattle, WA 98125
office: 206.420.7918
mobile: 206.406.9856
web:    www.360-Analytics.com <http://www.360-analytics.com/> 




On 11/29/2010 11:54 AM, Dahlstrom, Aaron wrote: 

 

A recent LEED MV plan review comment asked "please indicate the proposed
calibration method to account for the local weather conditions during the
performance period."

 

This raises the question for me - are model results significantly impacted
by the difference between historic weather data and performance-period data?

 

When I'm engaged in Measurement and Verification, I can install a weather
station that records data for performance period to allow for calibration.
(http://www.gsd.harvard.edu/research/gsdsquare/Publications/BuildingSimulati
on2009.GundHallModel.pdf)

 

But for an investment-grade energy audit with historic bills, I'm not sure
where to turn for all the variables needed to construct a weather file.

 

Anyone on this list have a recommendation? 

 

(I'm specifically looking for NYC, 2009, weather data for an eQUEST model.)

 

Aaron Dahlstrom , PE, LEEDR AP

In Posse - A subsidiary of AKF| 1500 Walnut Street, Suite 1414,
Philadelphia, PA 19102 

d: 215-282-6753| m: 267-507-5470| In Posse: 215-282-6800| AKF: 215-735-7290

e: ADahlstrom at in-posse.com | in posse web: www.in-posse.com
<http://www.in-posse.com/>  | akf web: www.akfgroup.com
<http://www.akfgroup.com/> 

 

 

 


This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. If you are not an intended recipient of
this e-mail, do not duplicate or redistribute it by any means. Please delete
it and any attachments and notify the sender that you have received it in
error. Unintended recipients are prohibited from taking action on the basis
of information in this e-mail. E-mail messages may contain computer viruses
or other defects, may not be accurately replicated on other systems, or may
be intercepted, deleted or interfered without the knowledge of the sender or
the intended recipient. If you are not comfortable with the risks associated
with e-mail messages, you may decide not to use e-mail to communicate with
In Posse. 

 
_______________________________________________
Bldg-sim mailing list
http://lists.onebuilding.org/listinfo.cgi/bldg-sim-onebuilding.org
To unsubscribe from this mailing list send  a blank message to
BLDG-SIM-UNSUBSCRIBE at ONEBUILDING.ORG


_______________________________________________ Bldg-sim mailing list
http://lists.onebuilding.org/listinfo.cgi/bldg-sim-onebuilding.org To
unsubscribe from this mailing list send a blank message to
BLDG-SIM-UNSUBSCRIBE at ONEBUILDING.ORG 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20101202/55609d4d/attachment-0002.htm>