Trick to simulate for a leap year with weather file for "normal" year

asked 2020-12-25 07:17:45 -0600

Adrien
404 ●4 ●8

updated 2021-04-05 09:47:42 -0600

__AmirRoth__

4436 ●5 ●17 http://bleedinggreenna...

(Related to https://unmethours.com/question/22577 where I initially posted, but this is actually a new question)

I was wondering how the CO2 concentration could raise in my classrooms during the weekends and realized that it is because I am simulating for 2020 which is a leap year, but my weather file is not describing a leap year. I use compact schedules with "Monday, Tuesdays..." or "Weekends" so from March everything got messed up.

I guess that to trick energyplus and making it believe that my weather file was written for 2020 does not make a lot of sense, it won't change the results... but I still want to do this. So I modified the weather file's header (to set the "Leap Year" flag to "Yes" and set the "Day of Week for Start Day" to the good value, for instance "Wednesday") and copied the data from February 28 to create some for February 29 because I had only 8760 entries in my weather file. Then I had to replace all the occurrences of the previous year with 2020.

This "procedure" is based on the referenced thread that is 3 years old, so my question is: is this still the right way to simulate for a leap year without having the appropriate weather file, or is there a better way?

answered 2020-12-26 09:14:44 -0600

Jason DeGraw

2208 ●6 ●10 https://github.com/jasondegraw

I'm not quite sure what all you changed, but it appears that you did the following things:

Set the leap year flag in the EPW header
Modify the start day of the week in the EPW header
Add data for February 29 in the EPW
Change the year field of each line in the EPW weather data to be 2020

Did I miss anything?

As of 9.4, you should not need the second and fourth items. The year handling of EnergyPlus was modified so that there's better tracking of the year that's being simulated. There was discussion of whether we should repeat the weather of February 28 (or something similar) if the 29th was not found, but in the end the feeling was that this was information that needed to be provided. The three things that need to happen now are:

Set the leap year flag in the EPW header
Add data for February 29 in the EPW
Set the "begin year" in the RunPeriod object to a leap year. Make sure the starting weekday is blank.

EnergyPlus ignores most of the start date information in the EPW because it is unreliable. There is a flag to treat the weather as actual weather, which causes more checking of the dates involved and will require that the year of the starting time be correctly set in the EPW. If you would like your simulation to fail if something is not quite right, then setting that flag (in the RunPeriod object) will be the way to go. I believe in that mode, EnergyPlus will require that a leap day be present for a leap year and will fail if there's no 2/29.

If you're using OpenStudio and want to avoid the warning about nonconsecutive data points, you will need to modify the year of each data point. As far as I know, that warning doesn't mean too much at this point, as OpenStudio does not give you access to the full RunPeriod object. The most reliable way around that will be to use an EnergyPlus measure to set the fields directly.

Apologies that there isn't a simple answer on this. The situation is a lot better than 3 years ago from the EnergyPlus standpoint, but the EPW part is complicated.