RunPeriod start_date must come before end_date

How do I only simulate winter months? For the northern hemisphere, this would mean choosing an analysis period that starts at the end of the year and ends at the beginning of the year, but Ladybug doesn’t allow you to do this:

For running a full winter simulation you have two options:

  • If you want to know how your building reacts to a specific winter (lets say the winter of 2004/2005) you wil have to run two simulations. EPW files cover just one year.

  • A lot of EPW files are put together with weather data from different years. In this case you can just run a whole year simulation, and filter out the winter data after the simulation is done.

Thanks @Erikbeeren, I have used your second methodology in the past and it works, but it does mean that the runtime is unnecessarily long. I have also split it into 2 simulations in the past (e.g. one for December and one for January-February) which simulated quicker but not in a linear way since there is some overhead. A third option I’ve been thinking about is to flip the data in the EPW, i.e. to manually cut the first 4380 lines and paste them at the end, but that sounds a bit hacky.

None of the above are ideal and I’m wondering if there is a way to get LBT to work with an ‘overlapping’ analysis period, or whether EnergyPlus is just not set up for this @chris?

@MaxMarschall I think your third option could work. By the way I you do not need HVAC systems you can also use the HB anual loads component. It realy works fast.

Thanks for bringing this to my attention and this one is actually my bad.

I had thought that EnergyPlus/OpenStudio had dropped support for this type of winter simulation using annual EPWs when the E+ developers decided to put “year” inputs on the EnergyPlus RunPeriod object a few versions ago. This decision somewhat broke a lot of the historic use-cases with annual TMY data but it seems that this change in E+ was actually compensated for by the OpenStudio SDK, which stuck to favoring annual simulations (and the looping of the year end to year start) over the multi-year simulations that E+ was trying to support.

Long story short, this check that I had for the Simulation Parameter RunPeriod was completely unnecessary and everything works when you plug in a run period that has a start date after the end date. I just removed the check from the core libraries:

And you should be able to get the fix on your end with the “LB Versioner” in an hour or so. Then, you’ll be able to run simulation like this:


Hi Chris, I’ve been seeing this problem occurring again in V1.3. Is this another easy fix?

It’s still need to fix, i think a new component with 4 different seasons will be better

@amynuccio ,

The comfort maps are a little different than straight-up energy simulation. Because the comfort maps do a lot of complex post-processing, I haven’t gotten the chance to write this postprocessing to handle all cases yet and one of those unsupported cases is when the start is before the end date.

I have plans to make a bunch of updates to the comfort maps and supporting reverse run periods is on the list after some better longwave MRT calculation and better parallelization of the comfort model step. So my recommendation is to just hang in there and, if you need a quick workaround, you can either run two comfort map simulations or run the full year and postprocess the output in Grasshopper.

1 Like