Revision history [back]

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.<="" p="">

I'm also posting this to Unmet Hours as a way to bring more attention to what I see as a significant problem.

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.<="" p=""> (note: 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 exaggerated 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.

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=""> (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) (note: 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 exaggerated 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.

Table of January 1 DOW 1980-2030 Jan 1 1980 is a TUE

Jan 1 1981 is a THU

Jan 1 1982 is a FRI

Jan 1 1983 is a SAT Jan 1 1984 is a SUN Jan 1 1985 is a TUE Jan 1 1981 1986 is a WED Jan 1 1987 is a THU Jan 1 1982 1988 is a FRI Jan 1 1983 1989 is a SUN Jan 1 1990 is a MON Jan 1 1991 is a TUE Jan 1 1992 is a WED Jan 1 1993 is a FRI Jan 1 1994 is a SAT Jan 1 1984 1995 is a SUN Jan 1 1985 1996 is a MON Jan 1 1997 is a WED Jan 1 1998 is a THU Jan 1 1999 is a FRI Jan 1 2000 is a SAT Jan 1 2001 is a MON Jan 1 2002 is a TUE Jan 1 1986 2003 is a WED Jan 1 1987 2004 is a THU Jan 1 1988 2005 is a SAT Jan 1 2006 is a SUN Jan 1 2007 is a MON Jan 1 2008 is a TUE Jan 1 2009 is a THU Jan 1 2010 is a FRI Jan 1 1989 2011 is a SAT Jan 1 2012 is a SUN Jan 1 1990 2013 is a TUE Jan 1 2014 is a WED Jan 1 2015 is a THU Jan 1 2016 is a FRI Jan 1 2017 is a SUN Jan 1 2018 is a MON Jan 1 1991 2019 is a TUE Jan 1 1992 2020 is a WED Jan 1 1993 2021 is a FRI Jan 1 1994 2022 is a SAT Jan 1 1995 2023 is a SUN Jan 1 1996 2024 is a MON Jan 1 1997 2025 is a WED Jan 1 1998 2026 is a THU Jan 1 1999 2027 is a FRI Jan 1 2000 2028 is a SAT Jan 1 2001 2029 is a MON Jan 1 2002 is a TUE Jan 1 2003 is a WED Jan 1 2004 is a THU Jan 1 2005 is a SAT Jan 1 2006 is a SUN Jan 1 2007 is a MON Jan 1 2008 is a TUE Jan 1 2009 is a THU Jan 1 2010 is a FRI Jan 1 2011 is a SAT Jan 1 2012 is a SUN Jan 1 2013 is a TUE Jan 1 2014 is a WED Jan 1 2015 is a THU Jan 1 2016 is a FRI Jan 1 2017 is a SUN Jan 1 2018 is a MON Jan 1 2019 is a TUE Jan 1 2020 is a WED Jan 1 2021 is a FRI Jan 1 2022 is a SAT Jan 1 2023 is a SUN Jan 1 2024 is a MON Jan 1 2025 is a WED Jan 1 2026 is a THU Jan 1 2027 is a FRI Jan 1 2028 is a SAT Jan 1 2029 is a MON Jan 1 2030 is a TUE

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) (note: 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 exaggerated 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.

Table of January 1 DOW 1980-2030 (don't know why this table is wrapping - would appreciate anybody's help in fixing... YJH)

Jan 1 1980 is a TUE Jan 1 1981 is a THU Jan 1 1982 is a FRI Jan 1 1983 is a SAT Jan 1 1984 is a SUN Jan 1 1985 is a TUE Jan 1 1986 is a WED Jan 1 1987 is a THU Jan 1 1988 is a FRI Jan 1 1989 is a SUN Jan 1 1990 is a MON Jan 1 1991 is a TUE Jan 1 1992 is a WED Jan 1 1993 is a FRI Jan 1 1994 is a SAT Jan 1 1995 is a SUN Jan 1 1996 is a MON Jan 1 1997 is a WED Jan 1 1998 is a THU Jan 1 1999 is a FRI Jan 1 2000 is a SAT Jan 1 2001 is a MON Jan 1 2002 is a TUE Jan 1 2003 is a WED Jan 1 2004 is a THU Jan 1 2005 is a SAT Jan 1 2006 is a SUN Jan 1 2007 is a MON Jan 1 2008 is a TUE Jan 1 2009 is a THU Jan 1 2010 is a FRI Jan 1 2011 is a SAT Jan 1 2012 is a SUN Jan 1 2013 is a TUE Jan 1 2014 is a WED Jan 1 2015 is a THU Jan 1 2016 is a FRI Jan 1 2017 is a SUN Jan 1 2018 is a MON Jan 1 2019 is a TUE Jan 1 2020 is a WED Jan 1 2021 is a FRI Jan 1 2022 is a SAT Jan 1 2023 is a SUN Jan 1 2024 is a MON Jan 1 2025 is a WED Jan 1 2026 is a THU Jan 1 2027 is a FRI Jan 1 2028 is a SAT Jan 1 2029 is a MON Jan 1 2030 is a TUE

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
1,12/31

DATA PERIODS, 1,1,Data,Actual, 1/  1,12/31
1,12/31

Jan 1 1980 is a TUE
Jan 1 1981 is a THU
Jan 1 1982 is a FRI
Jan 1 1983 is a SAT
Jan 1 1984 is a SUN
Jan 1 1985 is a TUE
Jan 1 1986 is a WED
Jan 1 1987 is a THU
Jan 1 1988 is a FRI
Jan 1 1989 is a SUN
Jan 1 1990 is a MON
Jan 1 1991 is a TUE
Jan 1 1992 is a WED
Jan 1 1993 is a FRI
Jan 1 1994 is a SAT
Jan 1 1995 is a SUN
Jan 1 1996 is a MON
Jan 1 1997 is a WED
Jan 1 1998 is a THU
Jan 1 1999 is a FRI
Jan 1 2000 is a SAT
Jan 1 2001 is a MON
Jan 1 2002 is a TUE
Jan 1 2003 is a WED
Jan 1 2004 is a THU
Jan 1 2005 is a SAT
Jan 1 2006 is a SUN
Jan 1 2007 is a MON
Jan 1 2008 is a TUE
Jan 1 2009 is a THU
Jan 1 2010 is a FRI
Jan 1 2011 is a SAT
Jan 1 2012 is a SUN
Jan 1 2013 is a TUE
Jan 1 2014 is a WED
Jan 1 2015 is a THU
Jan 1 2016 is a FRI
Jan 1 2017 is a SUN
Jan 1 2018 is a MON
Jan 1 2019 is a TUE
Jan 1 2020 is a WED
Jan 1 2021 is a FRI
Jan 1 2022 is a SAT
Jan 1 2023 is a SUN
Jan 1 2024 is a MON
Jan 1 2025 is a WED
Jan 1 2026 is a THU
Jan 1 2027 is a FRI
Jan 1 2028 is a SAT
Jan 1 2029 is a MON
Jan 1 2030 is a TUE
 TUE