<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
David,<br>
<br>
It's occurred to me that what you're suggesting in removing December
31st does not work for the following reasons:<br>
<br>
1. DOE-2 "automatically" skips Feb. 29th because DOE-2 weather is
stored in monthly "chunks".<br>
<br>
2. Continuing the run beyond Feb. 28 means that the weather data are
right, but the Days of Week are offset by 1.<br>
<br>
Therefore, the "best" way to get this right (and it's extremely
tedious) is:<br>
a. Run the weather file as a Leap Year through Feb. 28th.<br>
b. Create a new weather file where the dates are moved up by
one, i.e., Jan 2 is Jan 1, and so Feb. 29 is Feb. 28.<br>
c. Run this new weather file picking a year where the Day of
Week is the same as the Leap year, starting with Feb. 28 (actually
the 29th)<br>
<br>
i.e., what you would be doing is<br>
<br>
days in File1 Ian 1 ... Feb27 Feb28 Feb29 Mar1 Mar2 Mar3<br>
Run 1 yes ... yes yes skipped no
no no<br>
<br>
days in FIle2 Jan 2 .. Feb26 Feb27 Feb28 Mar1 Mar2
Mar3 <br>
Run2 no .... no .... no yes
yes yes yes<br>
<br>
Joe<br>
<br>
Joe Huang<br>
White Box Technologies, Inc.<br>
346 Rheem Blvd., Suite 205A<br>
Moraga CA 94556<br>
<a class="moz-txt-link-abbreviated" href="mailto:yjhuang@whiteboxtechnologies.com">yjhuang@whiteboxtechnologies.com</a><br>
<a class="moz-txt-link-freetext" href="http://weather.whiteboxtechnologies.com">http://weather.whiteboxtechnologies.com</a> for simulation-ready weather
data<br>
(o) (925)388-0265<br>
(c) (510)928-2683<br>
"building energy simulations at your fingertips"<br>
<br>
On 2/23/2017 3:11 PM, David Eldridge wrote:<br>
<span style="white-space: pre;">> To clarify on Keith's point, I would suggest removing December 31st
> instead of February 29th if you are doing this manually to maintain
> the days of the week particularly if you are calibrating hourly or
> daily data. If you have daily data to calibrate with that would be
> sufficient to generate the needed statistics or make further
> adjustments to the model and the extra day on the end doesn't really
> matter.
>
> Calibrating monthly data, you'd have to be the judge if a 1/30th
> difference will throw you too far out of the required statistics.
>
> If that didn't work or you thought missing one day would throw it off
> too far, then I believe most programs would make you split the year
> into two parts and run twice. I haven't ever had a 1/30th problem
> knock me out of calibration though :)
>
> Then when you re-run the model for future typical years, problem
> solved the typical weather will be 8,760 and not 8,784.
>
> David
>
>
> David S. Eldridge, Jr., P.E., LEED AP BD+C, BEMP, BEAP, HBDP
> Grumman/Butkus Associates
>
>
>
> -----Original Message----- From: Bldg-sim
> [<a class="moz-txt-link-freetext" href="mailto:bldg-sim-bounces@lists.onebuilding.org">mailto:bldg-sim-bounces@lists.onebuilding.org</a>] On Behalf Of Keith
> Swartz via Bldg-sim Sent: Thursday, February 23, 2017 4:44 PM To: Joe
> Huang <a class="moz-txt-link-rfc2396E" href="mailto:yjhuang@whiteboxtechnologies.com"><yjhuang@whiteboxtechnologies.com></a>;
> <a class="moz-txt-link-abbreviated" href="mailto:bldg-sim@lists.onebuilding.org">bldg-sim@lists.onebuilding.org</a> Subject: Re: [Bldg-sim] When a 2016
> weather file crashes your computer program, don't automatically blame
> the weather file!
>
> Joe,
>
> Thank you for bringing up the leap year issue! I have also been
> surprised how people don't seem to have a way to deal with it.
> Although I deal with new construction 99% of the time instead of
> existing buildings, I have thought about the topic and have talked to
> people at conferences about how they deal with modeling leap years. I
> never got a good answer.
>
> I figured that the program would have to somehow skip over February
> 29th. Like you mentioned, the program might ignore it in the weather
> file or you might have to manually delete the day from the weather
> file. But then the days of the week don't match for the rest of the
> year! The weekend weather happens in the model on days with Friday
> and Saturday occupancy schedules. (Or maybe it's Sunday and
> Monday...I don't feel like figuring that out right now.) If the model
> starts with January 1st on the correct day of the week, January and
> February would be right, but the rest of the year would be offset a
> day. It seems that it would be a bit better to have January 1st in
> the model be the day of the week before it really occurred so that 10
> months would be right and 2 months wrong instead of 2 months right
> and 10 months wrong.
>
> I would be interested in hearing how those of you who do calibrated
> models deal with leap year. Do some programs have a way to include
> leap day?
>
> Keith Swartz, PE | Senior Energy Engineer Seventhwave 608.210.7123
> seventhwave.org
>
> -----Original Message----- From: Joe Huang via Bldg-sim
> [<a class="moz-txt-link-freetext" href="mailto:bldg-sim@lists.onebuilding.org">mailto:bldg-sim@lists.onebuilding.org</a>] Sent: Wednesday, February 22,
> 2017 8:46 PM To: BLDG-SIM <a class="moz-txt-link-rfc2396E" href="mailto:bldg-sim@lists.onebuilding.org"><bldg-sim@lists.onebuilding.org></a> Subject:
> [Bldg-sim] When a 2016 weather file crashes your computer program,
> don't automatically blame the weather file!
>
> Now that we're solidly into 2017, the predominant historical year
> weather file of interest is 2016. However, over the past month I've
> had at least 5 complaints there's something wrong with my 2016
> weather files because it crashes their software, Helios and Climate
> Consultant being two such programs that I remember, and maybe Trane.
>
> In all four cases, the reason for the crashes lies not in the weather
> data, but the failure of those programs to accept a Leap Year with
> 366 days! I've communicated this glitch to the developers of Helios
> and CC, but until the programs are modified, the only thing to do is
> to manually delete Feb. 29 from the files in order for it to work.
>
> I'm surprised that so many people think of Leap Years as an
> irrelevant anomaly. It's not a rare astronomical phenomenon like the
> conjunction of three planets that occurs once in a century; it
> happens a quarter of the years! I mean, if I tell you I have an
> algorithm that works 75% of the time, would you want to use it? :-)
>
> Okay, so it's just an extra day in February that can be deleted for
> convenience. But isn't the purpose of using a historical weather
> file to compare to actual data, e.g., utility bills, so do we also
> prorate the energy consumption, HDD, etc., for February? And once
> Feb. 29th is deleted, won't the Day of Week be out of sequence for
> the rest of the year, e.g., with the actual weekends now falling on
> "Fridays" and "Saturdays" in the simulation? All these issues
> because somebody decided not to include the extra Leap Day.
>
> With the CSV, EPW, and other text files, you are free to hand edit
> out Feb. 29th if you choose, but what about the DOE-2 *.BIN (*.BINM)
> binary files? It might surprise a lot of even experienced DOE-2
> users, but the *.BIN/*.BINM files always include Feb. 29th. In fact,
> the DOE-2 weather file format has room for 384 days, since the binary
> data are stored in two arrays of 1560 (4 numbers for each hour, or 16
> days), with room for 32 days for each month! When people complain
> that DOE-2 doesn't handle Leap Days, the fault lies in the DOE-2
> code, not the weather data; DOE-2 simply always reads 28 days for
> February and then jumps automatically to March. In fact, the code
> actually has a variable for ILEAP (1= yes, 0=no), that is being used
> only to get the right DOW.
>
> For years, I've toyed around with the idea of testing the use of
> ILEAP and see how easy is it to get DOE-2 to read and simulate
> February 29th. I've braced myself this time because the last time I
> mentioned this problem someone recommended, "use EXXXXXXXXX" !
>
> Somewhat tangential to this is a warning to those many DOE-2 users
> who have asked for "composite weather files" that span two years,
> e.g., Jan 1- June 30, 2017, followed by July 1 - Dec 31 2016. Since
> DOE-2 accepts just one value for the keyword YEAR, make sure that the
> Day of Week doesn't get fouled up after the change-over day. You may
> need to redefine all the Days of Week to avoid the problem mentioned
> two paragraphs back. (Just a friendly suggestion...)
>
> Joe
>
> -- Joe Huang White Box Technologies, Inc. 346 Rheem Blvd., Suite
> 205A Moraga CA 94556 <a class="moz-txt-link-abbreviated" href="mailto:yjhuang@whiteboxtechnologies.com">yjhuang@whiteboxtechnologies.com</a>
> <a class="moz-txt-link-freetext" href="http://weather.whiteboxtechnologies.com">http://weather.whiteboxtechnologies.com</a> for simulation-ready weather
> data (o) (925)388-0265 (c) (510)928-2683 "building energy simulations
> at your fingertips"
>
>
> _______________________________________________ Bldg-sim mailing
> list
> <a class="moz-txt-link-freetext" href="http://lists.onebuilding.org/listinfo.cgi/bldg-sim-onebuilding.org">http://lists.onebuilding.org/listinfo.cgi/bldg-sim-onebuilding.org</a> To
> unsubscribe from this mailing list send a blank message to
> <a class="moz-txt-link-abbreviated" href="mailto:BLDG-SIM-UNSUBSCRIBE@ONEBUILDING.ORG">BLDG-SIM-UNSUBSCRIBE@ONEBUILDING.ORG</a>
>
> </span><br>
<br>
un <br>
</body>
</html>