I've been silent on this issue for the past week because I was busy at ASHRAE, not because I had lost interest. Now that I'm back home, I'd like to add some following comments about Line 8 of the epw format that to me is the source of the problem. Line 8 states:
DATA PERIODS, 1,1,Data,Sunday, 1/ 1,12/31
If others are like me, you've probably completely ignored this line as superfluous or redundant documentation. However, its impact on any building energy simulation done using historical weather data, such as calibrating an existing building model to utility bills, will be quite significant since most buildings, especially commercial, have very different operational schedules and occupancies depending on the day of week. Therefore, it seems obvious to me that the current situation of always having the day of week beginning on a Sunday needs to be changed. I've been told that users have the option of specifying the starting day of week that would overwrite what's stated in the epw weather file, but that seems convoluted (since the epw overwrites the day of week calculated by EnergyPlus from the date stamp!) and dangerous since most users probably have no idea this is something they have to do whenever using an actual year weather file.
The Open Studio tactic of comparing the Day of Week (DOW) on the
epw (always Sunday till now) to what EnergyPlus calculates from
the date stamp to decide which to use is even more flawed. I've
written a small awk routine to calculate the DOW for Jan 1 from
1980 through 2030 (see attached). Note that out of those 50
years, there are 7 (1984, 1989, 1995, 2006, 2012, 2017, 2023) that
do begin on a Sunday! Therefore, this comparison is not reliable.
If one has a "typical year" weather file that happens to use
January from those years, Open Studio would think that's a
historical file and use the DOW as calculated by EnergyPlus from
the date stamp. On the other hand, it will interpret all the
historical files of the other 43 years as "typical year" data and
use Sunday as the starting DOW, which would completely mess up any
correlation with the actual DOW for that year.
If I were working with a blank slate, I would say the best thing to do with Line 8 is to get rid of it, or at least the DOW specification that now always appears as Sunday. However, I am very much aware of the need to maintain data compatibility and avoid version clash between different epws, so I would not advocate such a course of action, i.e., change the epw. A couple of solutions I've thought of, neither of which is very difficult, are:
(1) modify EnergyPlus to ignore Line 8 of the epw, and expand the RUN-PERIOD object to include the year. The slight disadvantage of this solution is that if users want Jan 1 of a typical year file to begin at a particular DOW, they would have to consult something like the attached table to get the appropriate year while avoiding any leap years, e.g., 1989 for Jan 1 to start on a Sunday but not 1984 that's a leap year with 366 days.
(2) <simplest solution in my opinion> Just add another value for "Actual" to the DOW specification in Line 8, and then have EnergyPlus interpret that to mean use the DOW as calculated from the date stamp, in other words, on all historical weather files Line 8 would say:
DATA PERIODS, 1,1,Data,Actual, 1/ 1,12/31
(3) <this is not a solution but rather a fix that perpetuates the problem). Post-process any historical epw weather file (of which I have in the neighborhood of 150,000) to insert the correct DOW for Jan. 1 in Line 8. Well, I exagerrated my task, because out of the 16 years I've processed (2001-2016), two (2006, 2012) actually do begin on a Sunday, so those should be okay, although 2012 is a leap year which makes me wonder if EnergyPlus will take into account.
I'm also posting this to Unmet Hours as a way to bring more attention to what I see as a significant problem.
Joe
White Box Technologies, Inc. 346 Rheem Blvd., Suite 205A Moraga CA 94556 yjhuang@xxxxxxxxxxxxxxxxxxxxxxxx http://weather.whiteboxtechnologies.com for simulation-ready weather data (o) (925)388-0265 (c) (510)928-2683 "building energy simulations at your fingertips"
I'm not sure what OpenStudio does differently when reading a typical vs actual year, but my guess is that it is driven by using standard date/time functions and wanting to validate the dates in the epw. For a typical year file, the software has to ignore the years in the time stamps, because they bounce around from month-to-month. But for an actual year, it should be safe to assume that the years are meaningful, so it's not unreasonable to expect that an actual year file will have a start day that is consistent with the day/month/year in the first hour of data. But given the Sunday default, the referenced test isn't adequate to make a judgement on the type of weather file.
OpenStudio support is handled on unmethours.com, but this is probably a topic better discussed directly with one of the developers. I will forward this to the OS team.
Mike
On 1/27/2017 2:56 AM, Joe Huang YJHuang@xxxxxxxxxxxxxxxxxxxxxxxx [EnergyPlus_Support] wrote:
(I've heard there's an Open Studio bulletin board, but since I don't know where it is, and maybe other EnergyPlus-related software might be doing the same thing, I thought I would just post this comment here)I've just been told by a client that Open Studio checks the DayofWeek for the start date on the EPW to the DayofWeek calculated from the date itself to determine whether the weather file is of a historical year or a "typical year" (see here) and thus would I mind changing that parameter on my EPWs which right now always sets the start date as a Sunday (I think it's hardwired in the WeatherConverter since I don't see anything in the DEF that allows that to be changed).
I find this request more than a little bizarre, because (1) whether a file is run as a "real year"or a "typical year" is a simulation option and NOT a condition of the weather file! (2) even if we accept this logic of comparing the start date DayofWeek to what it is actually to tell whether the file is a historical file or a "typical year" file, this seems like a very convoluted and error-prone way since someone (me ?) would have to calculate or look up on the Web the actual day of week for Jan 1 of that weather file, put that into the EPW, just so EnergyPlus will know "aha, this is a historical year weather file!".
This step is also completely unnecessary because EnergyPlus (as well as any other decent simulation program) has a Julian Calendar in its code to determine the day of week for any day, so why do we have to input that manually once again just to "prove" that this is a historical year run?
Let's see how another program (DOE-2) addresses this problem, which I never thought was a problem until now... In DOE-2, one enters the RUN-PERIOD is its entirety, i.e., Jan 1, 1999 through Dec. 31, 1999. If it's a "typical year" weather file that you want to start on a Sunday, then you pick a year where that happens - problem solved, no need to modify the weather file, of all things.
Joe
-- Joe Huang White Box Technologies, Inc. 346 Rheem Blvd., Suite 205A Moraga CA 94556 yjhuang@xxxxxxxxxxxxxxxxxxxxxxxx http://weather.whiteboxtechnologies.com for simulation-ready weather data (o) (925)388-0265 (c) (510)928-2683 "building energy simulations at your fingertips"
__._,_.___ View attachments on the web
Posted by: Joe Huang <yjhuang@xxxxxxxxxxxxxxxxxxxxxxxx>
EnergyPlus support is found at:
http://energyplus.helpserve.com or send a message to energyplus-support@xxxxxxxx
The EnergyPlus web site is found at:
http://www.energyplus.net/
The group web site is:
http://groups.yahoo.com/group/EnergyPlus_Support/
Attachments are currently allowed but be mindful that not everyone has a high speed connection. Limit attachments to small files.
EnergyPlus Documentation is searchable. Open EPlusMainMenu.pdf under the Documentation link and press the "search" button.
__,_._,___