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

Keith Swartz via Bldg-sim bldg-sim at lists.onebuilding.org
Thu Feb 23 14:44:12 PST 2017


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 [mailto:bldg-sim at lists.onebuilding.org] 
Sent: Wednesday, February 22, 2017 8:46 PM
To: BLDG-SIM <bldg-sim at lists.onebuilding.org>
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
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"




More information about the Bldg-sim mailing list