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
yjhuang at whiteboxtechnologies.com
http://weather.whiteboxtechnologies.com for simulation-ready weather data
(o) (925)388-0265
(c) (510)928-2683
"building energy simulations at your fingertips"