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

Tue Feb 28 10:52:00 PST 2017

David,

It's occurred to me that what you're suggesting in removing December 31st does not work 
for the following reasons:

1. DOE-2 "automatically" skips Feb. 29th because DOE-2 weather is stored in monthly "chunks".

2. Continuing the run beyond Feb. 28 means that the weather data are right, but the Days 
of Week are offset by 1.

Therefore, the "best" way to get this right (and it's extremely tedious) is:
     a.    Run the weather file as a Leap Year through Feb. 28th.
     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.
     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)

i.e., what you would be doing is

days in File1   Ian 1 ...   Feb27   Feb28  Feb29  Mar1  Mar2  Mar3
Run 1               yes    ...   yes        yes     skipped   no    no       no

days in FIle2   Jan 2 ..    Feb26  Feb27  Feb28  Mar1   Mar2 Mar3
Run2                no    ....    no  ....    no       yes yes     yes       yes

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"

On 2/23/2017 3:11 PM, David Eldridge wrote:
> 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 > 
[mailto:bldg-sim-bounces at lists.onebuilding.org] On Behalf Of Keith > Swartz via Bldg-sim 
Sent: Thursday, February 23, 2017 4:44 PM To: Joe > Huang 
<yjhuang at whiteboxtechnologies.com>; > bldg-sim at lists.onebuilding.org 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 > 
[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" > > > _______________________________________________ 
Bldg-sim mailing > list > 
http://lists.onebuilding.org/listinfo.cgi/bldg-sim-onebuilding.org To > unsubscribe from 
this mailing list send  a blank message to > BLDG-SIM-UNSUBSCRIBE at ONEBUILDING.ORG > >

un
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20170228/e97149b5/attachment-0001.html>