<div>Hi Nick,</div><div> </div><div>Interesting findings on your part. I can offer some info regarding the integrity of the weather files that might be useful for understanding.</div><div> </div><div>My experience shows that the majority of the weather files that are still being referenced by default in eQuest are typically a TMY file ( for the North American locations). TMY files were the fist set of bin files available for use with DOE-2. The data sets in these files include weather data collected from 1952-1975. Which makes the weather info in the pretty old by comparason to the weather phenomena that we have experienced in the present (..at least going back to the mid 1990s.)</div>
<div> </div><div>The next version (or updated weather data sets) are referred to as TMY2 files, and this data was collected from 1961-1990. The latest version of data sets is referrenced as TMY3 files which was collected from 1991-2005 (note*** a consideralbly short set of data complied into bins for us --14 years compared to 29 years for TMY2 and 23 years for TMY.)</div>
<div> </div><div>Also, when the TMY3 versions became available they were available for hundreds more cities in North America than before. For example, the small town that I live in (population less than 10,000) actually has a TMY3 data set available because we have an airport here with collectable weather data. Without the TMY3 file being available if I were to simulate the energy usage on my house or business building I would have to reference a TMY file for either Omaha or Denver, but either of these weather choices is not even close to being like the weather micro-climate characteristics that we have in our rural area. The TMY2 version of data does bring another option for a city about 60-90 miles away from my town. This is doable, but with the new technology and the amount of data that is available via internet resources and a multitude of weather stations, I was delighted to see that a TMY3 existed for such a small place 'in the middle of nowhere' which is how we are considered by so many people/visitors to our town.</div>
<div> </div><div>The statement to take away from this knowledge is two-fold: a) the majority of weather files still being referrenced by default in eQuest is mostly TMY and/or TMY2 files; and b) the older sets of weather data were more limited on the type of climate data that was collected during the specific time periods noted. THEREFORE; in some cases you might be experiencing a weather file/data set that is absent of the clear-ness factors that you might be looking for & trying to reference in your model(s). It is also known that some weather files completely lack any solar-type data, ground water temp data, daylighting variable factors and such, simply due to the fact that it wasn't available in the area that weather info was being collected for some cities. </div>
<div> </div><div>Now recognizing that TMY-type files are only for North American locations and more specifically USA locations, there are other types of weather files available for other Non-USA locations. For example; the CWEC type files are noting Canadian locations; WYEC files which is an acronym for "weather year for energy calculations" are representative of many other international locations, but are typically based on the collection years anywhere between the TMY and TMY2 eras.</div>
<div> </div><div>Once energy-plus came about in its development it was also a new opportunity in time to reference more updated weather files especially since we (the world) started experienencing more significant weather phenomena in the past 20 years. The EPW weather files are data sets collected more recently (I can't verify the time period from the DOE website though), and this is what was stated about these sets of weather data:</div>
<div> </div><div><p>Weather data for more than 2100 locations are now available in EnergyPlus weather format — 1042 locations in the USA, 71 locations in Canada, and more than 1000 locations in 100 other countries throughout the world. The weather data are arranged by World Meteorological Organization region and Country.</p>
<ul><li><a href="http://apps1.eere.energy.gov/buildings/energyplus/cfm/weather_data2.cfm/region=1_africa_wmo_region_1">Africa</a> (WMO Region 1)</li><li><a href="http://apps1.eere.energy.gov/buildings/energyplus/cfm/weather_data2.cfm/region=2_asia_wmo_region_2">Asia</a> (WMO Region 2)</li>
<li><a href="http://apps1.eere.energy.gov/buildings/energyplus/cfm/weather_data2.cfm/region=3_south_america_wmo_region_3">South America</a> (WMO Region 3)</li><li><a href="http://apps1.eere.energy.gov/buildings/energyplus/cfm/weather_data2.cfm/region=4_north_and_central_america_wmo_region_4">North and Central America</a> (WMO Region 4)</li>
<li><a href="http://apps1.eere.energy.gov/buildings/energyplus/cfm/weather_data2.cfm/region=5_southwest_pacific_wmo_region_5">Southwest Pacific</a> (WMO Region 5)</li><li><a href="http://apps1.eere.energy.gov/buildings/energyplus/cfm/weather_data2.cfm/region=6_europe_wmo_region_6">Europe</a> (WMO Region 6)</li>
<li><a href="http://apps1.eere.energy.gov/buildings/energyplus/cfm/weather_data2.cfm/region=7_antarctica_wmo_region_7">Antarctica</a> (WMO Region 7)<br></li></ul></div><div class="gmail_quote">This is probably WAY more information than you hoped to consider, but it is imperative to be aware of the integrity of your weather data in your models, because sometimes we can observe interesting anomolies in our energy models due to the lack of incorrect or missing weather information from which we base our energy calculations on.</div>
<div class="gmail_quote"> </div><div class="gmail_quote">ALSO--on a side note, other energy modelers might be thinking----" that doesn't seem right, when I select my location in eQuest wizard I can select my specific city in the Wizard screens." Yes, you can select your specific city/town in the wizard screens of eQuest, but it may actually be referrencing a more 'regional' weather file for the largest city/airport location near your actual project site. Don't be fooled by what you see in the user interface, you will have to dig into files deeper to specifically confirm the default weather file that is being used in your models. You can do this by going into DDedit mode and clicking on your Project Name at the top of the navigation tree and then referencing the actual .bin file name that is being used in your energy calculations.</div>
<div class="gmail_quote"> </div><div class="gmail_quote">Don't believe everything you see in your user interfaces---always go into DOE-2 itself to confirm what is actually being used. An additional example of this would be using TRACE700 for Underfloor air system simulations---I actually had a Mech Designer tell me, "TRACE can simulated UFA systems! I can choose the system type in the program." I told them no it can't specifically model these systems, they are applying work-arounds and modified algorithms to "Represent" the sytem operation, but TRACE700 and other sim programs including eQuest/DOE-2 do not specifically stratify loads in the conditioned spaces to actually represent these types of systems. I believe that EnergyPlus is the closest simulation software that can most accurately represent UFA & TDV systems, and all others are fooling us by using work-a-round strategies.</div>
<div class="gmail_quote"> </div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Pasha</div><div class="gmail_quote"> </div><div class="gmail_quote">On Tue, Jan 24, 2012 at 11:24 AM, Nick Caton <span dir="ltr"><<a href="mailto:ncaton@smithboucher.com">ncaton@smithboucher.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div lang="EN-US" vlink="purple" link="blue"><div><p class="MsoNormal">
Hey all!<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Something new occurred to me recently triggered by a photocell scheduling question. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">To ground and set up this idea – first check out this interesting online visual explaining how annual day/night hours vary based on latitude… play around a bit with the bars to see how daylight hours vary based on latitude and time of year: <a href="http://astro.unl.edu/classaction/animations/coordsmotion/daylighthoursexplorer.html" target="_blank">http://astro.unl.edu/classaction/animations/coordsmotion/daylighthoursexplorer.html</a><u></u><u></u></p>
<p class="MsoNormal">Note that regardless of location, the yearly average on a daily basis always works out to 12 hours.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Now take the typical case of a simple ON/OFF photocell control for exterior lighting. From an exterior lighting control standpoint, the model linked above is simplified from reality in that the effects of cloud cover/weather are not accounted for. While the sun on a given day may officially set at 6PM, for example, overcast cloud cover, rain, smog, fog and similar conditions may cause a photocell to turn on the exterior lights hours earlier, by reducing the daylight illumination reaching the photocell/ground. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Based on some explorations – the current PHOTOCELL-CTRL schedule appears to demonstrate something like a “simplified” model per the above link, assuming clear skies. I’m observing approximately 12 hrs of photocell operation per day averaged over the year for different locations’ TMY weather files (slightly less, actually… ~11.95). I would assume by extension it’s using a function based on the location’s latitude or perhaps referencing something like the “sun up flag” in the weather files. Does this jive with what anyone knows to be going on under the hood?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">If my understanding is correct, I would like to suggest a few improvements for present discussion and future development:<u></u><u></u></p><p><u></u><span>1)<span style="font:7pt/normal "Times New Roman";font-size-adjust:none;font-stretch:normal"> </span></span><u></u>First I think it’s worthwhile to retain the “clear sky” PHOTOCELL-CTRL function as it currently exists – I can conceive applications where a simplified “on when the sun sets” model could be both desirable & useful, such as in comparing output with simple daylight simulation models. It could also perhaps be more specifically named “ASTRONOMICAL-CTRL” in reference to mechanical/digital astronomical timeclocks which calculate daily on/off times very much like the animated model linked above.<u></u><u></u></p>
<p><u></u><span>2)<span style="font:7pt/normal "Times New Roman";font-size-adjust:none;font-stretch:normal"> </span></span><u></u>An improved PHOTOCELL-CTRL scheduling function could be defined working around the following:<u></u><u></u></p>
<p style="margin-left:1in"><u></u><span>a.<span style="font:7pt/normal "Times New Roman";font-size-adjust:none;font-stretch:normal"> </span></span><u></u>It’s my understanding that weather files may contain hourly measured illuminance readings that inherently account for cloud cover and other weather conditions. <u></u><u></u></p>
<p style="margin-left:1in"><u></u><span>b.<span style="font:7pt/normal "Times New Roman";font-size-adjust:none;font-stretch:normal"> </span></span><u></u>Actual photocell systems will turn on and off at prescribed, sometimes different levels. For example, here’s a link to a product which turns fixtures on at 3fc and off at 8fc, with a nominal delay to minimize nuisance cycling: <a href="http://www.cooperindustries.com/content/dam/public/crousehinds/Industrial%20EX%20Products/Catalog%20PDFs/Lighting/Photocells%20for%20Champ%20HID%20Luminaires.pdf" target="_blank">LINK</a>. The equipment literature I’ve checked cite values from 1fc to 10fc. <u></u><u></u></p>
<p style="margin-left:1in"><u></u><span>c.<span style="font:7pt/normal "Times New Roman";font-size-adjust:none;font-stretch:normal"> </span></span><u></u>Per the above, an improved PHOTOCELL-CTRL scheduling option could accept inputs for one (possibly two) exterior footcandle levels to define on/off behavior. Hourly ON/OFF behavior could then be determined directly referencing the exterior hourly horizontal ground illuminance measurement from the weather file used, switching lights when the appropriate threshold is crossed.<u></u><u></u></p>
<p style="margin-left:1in"><u></u><span>d.<span style="font:7pt/normal "Times New Roman";font-size-adjust:none;font-stretch:normal"> </span></span><u></u>Such a scheduling option could more accurately gauge the full impact of exterior lighting retrofit and controls upgrades. This is often relatively low-hanging fruit, in my experience.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">A related query for the weather gurus: I’m uncertain whether TMY weather files, representing averaged data over many years, would be particularly constructive or not for representing the effects of cloud cover and so forth… Growing up in FL, I recall a definite “rain-season” mid-summer which I expect would be captured in the daylight measurements of any FL weather station… but where weather/cloud cover is much less regular (such as here in KS), perhaps the effects would be lost in averaging?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thoughts?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">~Nick<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">
<img border="0" alt="cid:489575314@22072009-0ABB" width="119" height="37"><b><span style="color:rgb(45,77,94);font-family:"Stylus BT","sans-serif""><u></u><u></u></span></b></p><p class="MsoNormal"><b><span style="color:rgb(45,77,94);font-family:"Stylus BT","sans-serif""><u></u> <u></u></span></b></p>
<p class="MsoNormal"><b><span style="color:rgb(45,77,94);font-family:"Stylus BT","sans-serif";font-size:12pt">NICK CATON, P.E.</span></b><b><span style="color:rgb(45,77,94);font-family:"Stylus BT","sans-serif";font-size:12pt"><u></u><u></u></span></b></p>
<p class="MsoNormal"><span style="color:rgb(204,153,0);font-size:7.5pt">SENIOR ENGINEER<u></u><u></u></span></p><p class="MsoNormal"><span style="color:rgb(204,153,0);font-size:7.5pt"><u></u> <u></u></span></p><p class="MsoNormal">
<span style="color:rgb(45,77,94);font-size:10pt">Smith & Boucher Engineers</span><span style="color:rgb(204,153,0);font-family:"Times New Roman","serif";font-size:7.5pt"><u></u><u></u></span></p><p class="MsoNormal">
<span style="color:rgb(45,77,94);font-size:10pt">25501 west valley parkway, suite 200<u></u><u></u></span></p><p class="MsoNormal"><span style="color:rgb(45,77,94);font-size:10pt">olathe, ks 66061<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(45,77,94);font-size:10pt">direct <a href="tel:913.344.0036" target="_blank" value="+19133440036">913.344.0036</a><u></u><u></u></span></p><p class="MsoNormal"><span style="color:rgb(45,77,94);font-size:10pt">fax <a href="tel:913.345.0617" target="_blank" value="+19133450617">913.345.0617</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><a title="blocked::www.smithboucher.com" href="http://www.smithboucher.com" target="_blank"><span style="color:blue;font-size:10pt">www.smithboucher.com</span></a></span><u><span style="color:blue;font-size:10pt"> </span></u><span style="color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p></div></div><br>_______________________________________________<br>
Equest-users mailing list<br>
<a href="http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org" target="_blank">http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org</a><br>
To unsubscribe from this mailing list send a blank message to <a href="mailto:EQUEST-USERS-UNSUBSCRIBE@ONEBUILDING.ORG">EQUEST-USERS-UNSUBSCRIBE@ONEBUILDING.ORG</a><br>
<br></blockquote></div><br>