Revision history [back]

(I've moved this post from EnergyPlus_Support to Unmet Hours because it deals with some inner workings of EnergyPlus, EPW weather format, and Open Studio.. Although the opening question asks about how Open Studio uses a certain feature in the EPW format to distinguish between a "typical year" and a historical year weather file, I believe the underlying problem rests in the EPW format and EnergyPlus)

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 https://github.com/NREL/OpenStudio/blob/72e4961a2d6547dcb40be48f722345b5691e3a74/openstudiocore/src/utilities/filetypes/EpwFile.cp ) 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.

(I've moved this post from EnergyPlus_Support to Unmet Hours because it deals with some inner workings of EnergyPlus, EPW weather format, and Open Studio.. Although the opening question asks about how Open Studio uses a certain feature in the EPW format to distinguish between a "typical year" and a historical year weather file, I believe the underlying problem rests in the EPW format and EnergyPlus)

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 https://github.com/NREL/OpenStudio/blob/72e4961a2d6547dcb40be48f722345b5691e3a74/openstudiocore/src/utilities/filetypes/EpwFile.cp EpwFile.cpp) 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.

(I've moved this post from EnergyPlus_Support to Unmet Hours because it deals with some inner workings of EnergyPlus, EPW weather format, and Open Studio.. Although the opening question asks about how Open Studio uses a certain feature in the EPW format to distinguish between a "typical year" and a historical year weather file, I believe the underlying problem rests in the EPW format and EnergyPlus)

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 EpwFile.cpp) 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.

(I've moved this post from EnergyPlus_Support to Unmet Hours because it deals with some inner workings of EnergyPlus, EPW weather format, and Open Studio.. Although the opening question asks about how Open Studio uses a certain feature in the EPW format to distinguish between a "typical year" and a historical year weather file, I believe the underlying problem rests in the EPW format and EnergyPlus)

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 EpwFile.cpp) 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.