Start day of the week - Year specification Energy Sim Par

Hello,

Lately, I had to work with some old simulation results that were made with Honeybee version 0.0.64. Due to the changes in the components, I had to update to the latest version, with which I really struggled to get the same loads as in the original one.

Comparing the IDF files I realized that there was a change in the infiltration calculations, which I managed to correct easily. But, my main problem became the start day of the week. It looks like some part of the code has changed, and though I was using the same epw, the year started on a Thursday while the previous run started on a Sunday, making my cooling load and overheating period increase by close to 5%. I changed the “start day of the week” in the sim par, but it seems that the year takes precedence. I only managed to sort the problem by manually editing the idf to change from 2009 to 2017, to make the year start on a Sunday as in my original run, run the bat file and reload the results.

This part of the code makes me believe I am not currently able to instruct the simulation to start on the day I need it to from GH.

This time it was not a big deal, as I only had to tackle 5 iterations, but usually, I run 200-500. So, manually editing the idf, rerunning and reloading wouldn’t be feasible. Is there a better way to force the start day, preferably from GH?

Thanks,
Julia

Hi @JuliaT ,

Yes, this was all a part of a big change where EnergyPlus completely re-vamped the year description object so that they could simulate multi-year EPWs, which broke a lot of old workflows. If you ask me, it was a situation where people let the edge cases cause everyone else a huge headache. But it’s done and there’s nothing we can do now but adapt.

OpenStudio SDK finally added support for the start day of the week after thinking through how they should respond to the E+ change and the current method is called setDayofWeekforStartDay. I seem to remember the method only working in the OpenStudio Ruby bindings and not the C# bindings that honeybee-legacy was using (hence, why I was trying to get setString to work) but maybe that has changed. Here is what it looks like using OpenStudio Ruby bindings in the new LBT plugin:

And this brings up a good point that you might be better off just moving to the LBT plugin rather than trying to hack your way though the Legacy plugin. I don’t know if I can promise that you’ll totally obliterate the 5% change in cooling load since 5% is within the error that you might get from year-to-year of climate conditions (or, in some cases, from version-to-version of E+). But you’ll at least have much more control over all of the model input in the LBT plugin.