Energy Simulation Result change based on how the building is Design


While testing energy simulation, I have seen that depending on which Honeybee components are used during the design of the building, the EnergyPlus component provides different results.

Here I attach an Example of 3 identical buildings, for each I used different ways to design the building.

But on one of them (the system in the middle) provides different results.

Is there any reason why this happens or it’s a mistake from my side while designing the building?
EnergyPlan (758.1 KB)
*before opening the file, put Rhino units in meters, otherwise windows won’t be visible.


hi @Barbarur,

I looked at your model but could not figure out what reason could be.
Perhaps @chris has some notion of what is hapening here.
Interesting problem!

I suggest to compare the IDFs created to see the differences. Those are the “real” files sent to simulation.
I use WinMerge, for instance, for such comparisons.


@Barbarur ,

I can say with certainty that it’s the top bar chart (middle option in your script) that is not correct. The other two are the right ones.

I can also say with near certainty is that the reason why the top bar char option is not correct is that you found a way to get past the Legacy honeybee geometry checks to ultimately to change the vertex ordering of the exported IDF surfaces for that option.

If I am being honest, we never got the Legacy Honeybee geometry exporters for EnergyPlus to be completely bug-free. Most of the Masses-2-Zones exports should be correct and, for this incorrect Surface-by-Surface case that you have here, you can usually get it to be correct by manually flipping the Rhino surfaces before passing them to Honeybee. But the heart of the issue is that the Legacy honeybee translators to EnergyPlus were just not designed to handle both the “wild west” of geometric freedom that Rhino lets you create and all of the idiosyncrasies about how EnergyPlus expects the geometry to be passed to it. And our legacy code is so poorly written and documented that there’s little hope of being able to fix it.

Thankfully, we designed the EnergyPlus geometry exporters of the LBT honeybee plugin correctly and, to prove it to you, I have recreated your file here with the LBT components and verified that we get the exact same results no matter how the Honeybee Room is built: (95.8 KB)

So I’m sorry that I don’t have a better answer for you other than “use the LBT plugin” but hopefully cases like this make it clear why we felt the need to rewrite the entire Legacy plugin and core libraries from scratch when we made the LBT plugin. Now, you can trust the EnergyPlus results no matter what the direction of your input Rhino Surfaces were facing or how you built the energy model using the honeybee components.


FYI, the sample .gh file there is using the latest development version of the LBT plugin. You’ll want to run the “LB Sync Grasshopper File” component on it if you are using the last stable release of LBT (version 1.1.0).


Thanks a lot for the clarifications.