I’m rebuilding the below system for study purpose.
In general my system is working perfectly. But I found a strange situation. While the building I’m testing is a bit big (100m side and 300m height) I have made it just as a box and the simulation goes very fast and smooth.
But if I move tha box just 50m away, the calculations takes a lot longer. I can’t tell how long, because after 20min I stopped the calculation.
The resation to move the building/box 50m is just for testing and learning purpose. I could leave it where it is, but I’m sure in future projects I won’t be able to do it. So I better figurate out now what is going on.
I don’t know why is this difference on time to simulate. It quite surpriese me as it’s a single buidling in a void space, for which the change on location shouldn’t affect that much, I think.
Below picture of the “buildings” and the GH file.
EnergyPlus Simulation Rebuilt.gh (606.3 KB)
This issue is the legacy “Split floor to thermal zones” component. It just has some really poorly-written parts of it that were done by yours truly. If you were to connect the output of that component to the newer LBT plugin components for creating zones, you’ll see that the geometry is actually curved, resulting in some intense meshing when it goes off to EnergyPlus:
I suggest either not using the legacy “Split floor to thermal zones” component, or if you want core-perimeter offsetting that’s reliable, then use the dragonfly components in the new LBT 1.1 plugin. They are much more reliable thanks to some straight skeleton methods added by @SaeranVasanthakumar :
Thank you for your answer. Though I didn’t have clear something. The component “Split floor to thermal zones” has some coding issues? or it’s how I’m designing the building for testing?
I’ve been doing some more tests. I think I found a way around the issue; if I create the building with origin (0,0,0), connect it to “Split floor to thermal zones” and later move it to the location I want. Then the geometry remains flat and doesn’t bring issues on the calculation of OS.
I’m sure there are workarounds like the one you described but the core of the problem is definitely on our end and there’s no good reason why you should have to create it at the Rhino origin and move it except that our Legacy code is not very resilient. If I had to say what the heart of the issue likely is, we loft lines together under the hood of the Legacy Honeybee component and lofting has the potential to create curved surfaces. Conversely, the core/perimeter offset methods in the new LBT Dragonfly plugin do the whole core/perimeter calculation in the 2D floor plan and then simply extrude the result. Extrusions are always planar so nothing like the situation you’re experiencing here will happen in LBT Dragonfly.
Sure. I understand using the new Ladybug tools+ is recommended. The workaround I described is for anyone with similar problem, as currently the ladybug website holds many extremely useful example files as starting point, which are all done in Legendary.
Definitely, moving to the new LB+ will be the next step on the learning.