[Bldg-sim] When a 2016 weather file crashes your computer program, don't automatically blame the weather file!

[Joe Huang via Bldg-sim]

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"