[Bldg-sim] What do people do about Leap Years? was Re: Energy model calibration - normalizing the utility bills to month start-end

Tue Jun 23 13:54:46 PDT 2015

I guess the better, more direct answer, from my perspective is:
No, I don't think this is that important compared to some of the other
modeling problems out there in the world.

On Tue, Jun 23, 2015 at 2:43 PM, Joe Huang <yjhuang at whiteboxtechnologies.com
> wrote:

>  The responses so far are not what I expected and, in my view, miss the
> point.
> I was not talking about workarounds or ignoring the missing day in DOE-2,
> which is what I presume everyone has been doing up until now.  I'm frankly
> tired of that, because adding the fixes to DOE-2 seems to be quite easy to
> do.
>
> I also find the responses of "just use EnergyPlus" to be disingenuous and
> condescending.  It's like trying to fix a scratch on your car, and then
> somebody comes by and says, "oh, just go and buy this new better one".
>
> Joe
>
> Joe Huang
> White Box Technologies, Inc.
> 346 Rheem Blvd., Suite 205A
> Moraga CA 94556yjhuang at whiteboxtechnologies.comhttp://weather.whiteboxtechnologies.com for simulation-ready weather data
> (o) (925)388-0265
> (c) (510)928-2683
> "building energy simulations at your fingertips"
>
> On 6/23/2015 1:21 PM, Justin Spencer wrote:
>
> I think the cleanest is you just pretend every day is off by one. Ignore
> all of the month garbage (yes you'll be off by a day at times). Just think
> about it as days 1-365, with the right day of the week assigned. You can
> reassign your holidays if you want. You wind up dropping the real 12/31.
>
>  But I like the "just use EnergyPlus" option.
>
> On Tue, Jun 23, 2015 at 12:57 PM, Jim Dirkes <
> jim at buildingperformanceteam.com> wrote:
>
>>
>>    1. Use EnergyPlus :), which allows >365 days.  This is also helpful
>>    when the combined two-fuel billing cycle is 13-14 months.
>>    2. Ignore the 1/365 difference.  Do you really think it will matter
>>    much?
>>
>>
>> On Tue, Jun 23, 2015 at 2:48 PM, Joe Huang <
>> yjhuang at whiteboxtechnologies.com> wrote:
>>
>>>  This is a little off-topic, but something I've pondered for some time...
>>>
>>> The question is when people are using eQUEST/DOE-2 with historical year
>>> weather, what do you do when it's a leap year?  Since DOE-2
>>> always simulates a 365-day year,  do you just ignore the missing leap
>>> day, but then don't the Days of Week also get screwed up starting in March?
>>>
>>> Since a quarter of the years are leap years, I've never understood why
>>> accounting for them has been considered an insignificant detail.
>>> I mean, if I told you that a quarter of the time your simulation results
>>> would be a little wrong, isn't that a pretty high frequency?
>>>
>>> Many eQUEST/DOE-2 users also have the mistaken impression that the fault
>>> lies in the DOE-2 weather files, which is not true.
>>> Believe it or not, but the packed DOE-2 weather file format actually
>>> contains 384 days (32 days per month), and all the DOE-2 weather files I
>>> produce always contains Feb. 29 for the leap years (as well as other
>>> enhancements like greater precision in the data).
>>>
>>> So, where does the problem lie?  It's in the clock within DOE-2 that
>>> always sets February to be 28 days.  In other words, DOE-2 will read the
>>> weather file and do the simulation only through February 28th, even though
>>> the weather file contains data through February 32nd (:-)), although
>>> everything beyond the 28th would be blank on non-leap years, and beyond the
>>> 29th on leap years.
>>>
>>> When I've looked through the DOE-2.1E code, there are even flags setting
>>> the leap years but these are never used. I've thought many times of toying
>>> around with the code to see how difficult it would be to implement leap
>>> years, but just haven't gotten around to it.  As far as I can see, the
>>> biggest difficulty might might have to do not with the simulation itself,
>>> but with the reporting.
>>>
>>> I'd like to know if others think this is something of sufficient
>>> importance to merit further investigation.
>>>
>>> Joe
>>>
>>> Joe Huang
>>> White Box Technologies, Inc.
>>> 346 Rheem Blvd., Suite 205A
>>> Moraga CA 94556yjhuang at whiteboxtechnologies.comhttp://weather.whiteboxtechnologies.com for simulation-ready weather data
>>> (o) (925)388-0265
>>> (c) (510)928-2683
>>> "building energy simulations at your fingertips"
>>>
>>> On 6/23/2015 10:27 AM, Collinge, William Overton wrote:
>>>
>>>  All,
>>>
>>>
>>>
>>> This is a fantastic thread, and I am wondering if it could be taken one
>>> step further to query if anyone has experience with methods to attempt
>>> calibrating models of energy savings attributable to retrofits of multiple
>>> systems simultaneously (plant, envelope, HVAC etc. – as most real-world
>>> retrofits likely are), going past the 4- or 5-parameter breakpoint
>>> regression models to incorporate inverse modeling of specific load types
>>> and their space- or time-variable characteristics. This would fit under
>>> multivariate methods in the last line of Table 2 in the older version of
>>> ASHRAE Guideline 14 that Jeff Haberl has posted on his website, and would
>>> attempt to standardize Maria’s Step 5 below without (possibly) the need to
>>> conduct as much in-depth field verification as might otherwise be required.
>>> I’ve dabbled in this a little bit…without extensive discussions with others…
>>>
>>>
>>>
>>> Example: changing the OA ventilation rate is going to have a specific
>>> load profile versus some retrofit that affects the solar gain rate. Of
>>> course, much easier in theory to do calibrations of this sort with hourly
>>> meter data versus monthly utility bills…
>>>
>>>
>>>
>>> Bill Collinge
>>>
>>> Postdoctoral Scholar
>>>
>>> University of Pittsburgh
>>>
>>> Department of Civil and Environmental Engineering
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Bldg-sim [mailto:bldg-sim-bounces at lists.onebuilding.org
>>> <bldg-sim-bounces at lists.onebuilding.org>] *On Behalf Of *Maria Karpman
>>> *Sent:* Tuesday, June 23, 2015 12:02 PM
>>> *To:* 'Jeff Haberl'; 'Joe Huang'; bldg-sim at lists.onebuilding.org
>>> *Subject:* Re: [Bldg-sim] Energy model calibration - normalizing the
>>> utility bills to month start-end
>>>
>>>
>>>
>>> Hello all,
>>>
>>>
>>>
>>> We usually do the following to calibrate model to monthly utility bills:
>>>
>>> 1)      Create or purchase weather file corresponding to pre-retrofit
>>> period for which we have billing data. Lately we’ve been using
>>> WeatherAnalytics files, which we found to be more cost effective than
>>> creating our own (they charge $40 for an annual file).
>>>
>>> 2)      Run simulation using this weather file instead of TMY.
>>>
>>> 3)      Standard simulation reports (we typically use eQUEST) show
>>> usage by calendar month (e.g. January, February, etc.) which is usually not
>>> aligned with dates of utility bills, as noted in the question that started
>>> this thread. As Brian mentioned in one of the earlier posts, this may be
>>> circumvented by entering the actual meter read dates into eQUEST as shown
>>> in the screenshot below. This will align usages shown in eQUEST’s “E*”
>>> reports such as ES-E with the actual utility bills.  The approach does not
>>> allow entering more than one read date per month (e.g. we can’t capture
>>> April 3 – 28 bill). For projects where this limitation is an issue we
>>> generate hourly reports that show consumption by end use for each meter in
>>> the project, and aggregate it into periods that are aligned with utility
>>> bills.
>>>
>>>
>>>
>>> 4)      We then copy simulation outputs (either from ES-E or hourly
>>> reports, depending on the method used) into a standard spreadsheet with
>>> utility data. The spreadsheet is set up to plot side by side monthly
>>> utility bills and simulated usage, and also calculates normalized mean bias
>>> error (NMBE) and variance CV(RMSE).
>>>
>>> 5)      If we did not to where we want to be with NMBE and CV(RMSE) we
>>> adjust and re-run the model, and re-paste results into the same
>>> spreadsheet.
>>>
>>>
>>>
>>> In my experience regression analysis using weather as independent
>>> variable (i.e. running model with TMY file and normalizing for difference
>>> in weather) or relying on HDD to allocate usage to billing periods can be
>>> very misleading, mainly because on many projects weather is not the main
>>> driver of consumption. For example energy usage of a school during a given
>>> time period depends much more on vacation schedule than outdoor dry bulb
>>> temperatures.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> --
>>>
>>> *Maria Karpman *LEED AP, BEMP, CEM
>>>
>>> ________________
>>>
>>> Karpman Consulting
>>>
>>> www.karpmanconsulting.net
>>>
>>> Phone 860.430.1909
>>>
>>> 41C New London Turnpike
>>>
>>> Glastonbury, CT 06033
>>>
>>>
>>>
>>> *From:* Bldg-sim [mailto:bldg-sim-bounces at lists.onebuilding.org
>>> <bldg-sim-bounces at lists.onebuilding.org>] *On Behalf Of *Jeff Haberl
>>> *Sent:* Tuesday, June 23, 2015 10:16 AM
>>> *To:* Joe Huang; bldg-sim at lists.onebuilding.org
>>> *Subject:* Re: [Bldg-sim] Energy model calibration - normalizing the
>>> utility bills to month start-end
>>>
>>>
>>>
>>> Hello Joe,
>>>
>>>
>>>
>>> Yes, you can count the degree days and regress against that to show a
>>> correlation. However, one will get a better "fit" to the weather data if
>>> you regress to the degree day that is calculated for the balance point
>>> temperature of the building -- hence the inverse model toolkit or the
>>> variable based degree day method.
>>>
>>>
>>>
>>> PRISM actually calculates the degree days to a variety of change points
>>> and actually provides a table for each location that you use as a look up.
>>> The IMT will actually perform a variable based degree day calculation that
>>> agrees well with PRISM. IMT will also provide you with the average daily
>>> temperature for the billing period.
>>>
>>>
>>>
>>> When using DOE-2 for actual billing periods, one will have to extract
>>> the appropriate hourly variable, sum it to daily and then regroup to align
>>> with the billing periods. Here's a chunk of code that will create a dummy
>>> plant, display PV-A, PS-A, PS-E and BEPS, and extract the relevant hourly
>>> variables to normalize the BEPS to the utility bills:
>>>
>>>
>>>
>>> INPUT PLANT ..
>>>
>>>
>>>
>>> PLANT-REPORT VERIFICATION = (PV-A)
>>>
>>> $ PV-A, EQUIPMENT SIZES
>>>
>>>
>>>
>>> SUMMARY = (PS-A,PS-E,BEPS)
>>>
>>>
>>>
>>> $ PS-A, PLANT ENERGY UTILIZATION SUMMARY
>>>
>>> $ PS-E, MONTHLY ENERGY END USE SUMMARY
>>>
>>> $ BEPS, BUILDING ENERGY PERFORMANCE SUMMARY
>>>
>>>
>>>
>>> HVAC=PLANT-ASSIGNMENT ..
>>>
>>>
>>>
>>> $ EQUIPMENT DESCRIPTION
>>>
>>> $ ELECTRIC DOMESTIC WATER HEATER
>>>
>>>
>>>
>>> BOIL-1 =PLANT-EQUIPMENT TYPE=ELEC-DHW-HEATER SIZE=-999 ..
>>>
>>>
>>>
>>> $ ELECTRIC HOT-WATER BOILER
>>>
>>>
>>>
>>> BOIL-2 =PLANT-EQUIPMENT TYPE=ELEC-HW-BOILER SIZE=-999 ..
>>>
>>>
>>>
>>> $ HERMETICALLY SEALED CENT CHILLER
>>>
>>>
>>>
>>> CHIL-1 =PLANT-EQUIPMENT TYPE=HERM-CENT-CHLR SIZE=-999 ..
>>>
>>>
>>>
>>> $ Graphics block for Data Processing ***
>>>
>>>
>>>
>>> RP-3 = SCHEDULE THRU DEC 31 (ALL) (1,24) (1) ..
>>>
>>>
>>>
>>> $ 8 = Total PLANT heating load (Btu/h)
>>>
>>> $ 9 = Total PLANT cooling load (Btu/h)
>>>
>>> $ 10 = Total PLANT electric load (Btu/h)
>>>
>>>
>>>
>>> BLOCK-3-1 = REPORT-BLOCK
>>>
>>> VARIABLE-TYPE = PLANT
>>>
>>> VARIABLE-LIST = (8,9,10) ..
>>>
>>> BLOCK-3-2 = REPORT-BLOCK
>>>
>>> VARIABLE-TYPE = GLOBAL
>>>
>>> VARIABLE-LIST = (1) ..
>>>
>>> HR-3 = HOURLY-REPORT
>>>
>>> REPORT-SCHEDULE = RP-3
>>>
>>> REPORT-BLOCK = (BLOCK-3-1,BLOCK-3-2) ..
>>>
>>>
>>>
>>> END ..
>>>
>>>
>>>
>>> COMPUTE PLANT ..
>>>
>>>
>>>
>>> STOP ..
>>>
>>>
>>>
>>> 8=!  8=)  :=)  8=)  ;=)  8=)  8=(  8=)  8=()  8=)  8=|  8=)  :=')  8=)
>>> 8=?
>>> Jeff S. Haberl, Ph.D.,P.E.inactive,FASHRAE,FIBPSA,......jhaberl at tamu.edu
>>> <........jhaberl at tamu.edu>
>>> Professor........................................................................Office
>>> Ph: 979-845-6507
>>> Department of
>>> Architecture............................................Lab Ph:
>>> 979-845-6065
>>> Energy Systems Laboratory...........................................FAX:
>>> 979-862-2457
>>> Texas A&M
>>> University...................................................77843-3581
>>> College Station, Texas, USA, 77843.............................
>>> http://esl.tamu.edu
>>> 8=/  8=)  :=)  8=)  ;=)  8=)  8=()  8=)  :=)  8=)  8=!  8=)  8=? 8=) 8=0
>>>    ------------------------------
>>>
>>> *From:* Bldg-sim [bldg-sim-bounces at lists.onebuilding.org] on behalf of
>>> Joe Huang [yjhuang at whiteboxtechnologies.com]
>>> *Sent:* Monday, June 22, 2015 9:17 PM
>>> *To:* bldg-sim at lists.onebuilding.org
>>> *Subject:* Re: [Bldg-sim] Energy model calibration - normalizing the
>>> utility bills to month start-end
>>>
>>> Maybe I'm missing something here, but why can't you just count up the
>>> degree days for the utility period?
>>> I hope you're not working with average or "typical year" degree days,
>>> but the degree days from the same time period.
>>>
>>> I also recall that the old Princeton Scorekeeping Method (PRISM) back in
>>> the 1980's allows the user to enter the degree days for that time period,
>>> so it's not a new problem.
>>>
>>> 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 6/22/2015 6:09 AM, Jones, Christopher wrote:
>>>
>>>  When calibrating an energy model to utility bills the utility bills
>>> often don’t align with the month start and end.  I have reviewed a couple
>>> methods to calendar normalize the utility bills but find them somewhat
>>> unsatisfactory.
>>>
>>>
>>>
>>> For example the method I am looking at does the following:
>>>
>>> The April gas bill runs from March 25 – April 24.  The algorithm takes
>>> the average number of m3 per day from that bill, applies it to the days in
>>> April.  Then it takes the average number of days from the May bill which
>>> runs from April 24 – May 25 and applies that average to the remaining days
>>> in April.
>>>
>>>
>>>
>>> The issue is that the March-April period has much higher HDD than the
>>> April-May period and the “normalized” gas usage is significantly lower than
>>> the simulation data for April.
>>>
>>>
>>>
>>> I am wondering if there are any papers or other sources of information
>>> as to how others approach this problem.
>>>
>>>
>>>
>>>
>>>
>>> [image: cid:image003.png at 01D09C46.E75BA0D0]
>>>
>>> *Christopher Jones,*P.Eng.
>>> Senior Engineer
>>>
>>>
>>>
>>> *WSP Canada Inc.*
>>>
>>> 2300 Yonge Street, Suite 2300
>>>
>>> Toronto, ON M4P 1E4
>>> T +1 416-644-4226 <%2B1%20416-644-4226>
>>>
>>> F +1 416-487-9766 <%2B1%20416-487-9766>
>>>
>>> C +1 416-697-0065 <%2B1%20416-697-0065>
>>>
>>>
>>>
>>> www.wspgroup.com
>>>
>>>
>>>  ------------------------------
>>>
>>>
>>> You are receiving this communication because you are listed as a current
>>> WSP contact. Should you have any questions regarding WSP’s electronic
>>> communications policy, please consult our Anti-Spam Commitment
>>> www.wspgroup.com/casl
>>> <https://teesmail.tees.tamus.edu/owa/UrlBlockedError.aspx>. For any
>>> concern or if you believe you should not be receiving this message, please
>>> forward this message to us at caslcompliance at wspgroup.com so that we
>>> can promptly address your request. This message is intended only for the
>>> use of the individual or entity to which it is addressed, and may contain
>>> information which is privileged, confidential, proprietary or exempt from
>>> disclosure under applicable law. If you are not the intended recipient or
>>> the person responsible for delivering the message to the intended
>>> recipient, you are strictly prohibited from disclosing, distributing,
>>> copying or in any way using this message. If you have received this
>>> communication in error, please notify the sender, and destroy and delete
>>> any copies you may have received.
>>>
>>> WSP provides professional land surveying services through the following
>>> entities: WSP Surveys (AB) Limited Partnership and WSP Surveys (BC) Limited
>>> Partnership
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> 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
>>>
>>>
>>>   ------------------------------
>>>
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2014.0.4800 / Virus Database: 4365/10055 - Release Date:
>>> 06/19/15
>>>
>>>
>>> _______________________________________________
>>> Bldg-sim mailing listhttp://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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>>   --
>>
>> James V Dirkes II, PE, BEMP, LEED AP
>> CEO/President
>> The Building Performance Team Inc.
>> 1631 Acacia Dr, GR, Mi 49504
>>
>> Direct: 616.450.8653
>> jim at buildingperformanceteam.com
>>
>> Website <http://buildingperformanceteamcom>l  LinkedIn
>> <https://www.linkedin.com/pub/jim-dirkes/7/444/413>
>>
>>   Studies show that four out of every three people have a hard time with
>> math.
>>
>> _______________________________________________
>> 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20150623/f0415113/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 58565 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20150623/f0415113/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 6574 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20150623/f0415113/attachment-0007.png>