Dear community,
Using HB EUI and HB Normalize by Floor Area components, the normalised value from HB EUI is 2x the output from HB Normalize by Floor Area and it seems to be the correct one. Can it be that there is factor of 2 applied to the floor area by mistake in HB Normalize by Floor Area?
Best,
Farhang
Found the issue myself:
HB EUI considers the floor surface as it makes sense for a box-shape room, but HB Normalize by Floor Area (similar to HB Thermal Load Balance) considers any surface with downward facing normal vector in the floor area calculation.
I believe these components must work consistently. Or, at least, HB Room component must give a warning if the normal vectors of surfaces are not as expected to enclose the room.
Hello @farhang.tahmasebi can you share your model for troubleshooting?
best
-trevor
You are correct that there can be discrepancies between the floor area that E+ uses (which comes out of the HB End Use Intensity component) and the floor area of your Honeybee Model (which is what’s used by the HB Normalize by Floor Area component and is defined by the area of Honeybee Faces in the Room with the Floor face type).
However, this is not really true:
A discrepancy results from the fact that it is possible to create floor Faces in honeybee that do NOT have downward pointing normals. These floors that point upwards from the room volume are still included when a honeybee component like HB Normalize by Floor Area computes the floor area.
However, E+ does not support these types of floor Faces and automatically flips them when it finds them, resulting in an incorrect simulation. For this reason, we have to translate these types of floors that point upwards to walls when we translate it to E+ in order to ensure that the simulation still runs correctly:
So these floors get removed from the floor area when E+ calculates the EUI.
In summary, if you want to avoid this discrepancy, just make sure that all of the floors in your Honeybee model have floors that point downwards.
Thanks @chris and @TrevorFedyna.
I attach a simple model to illustrate the issue, if it is still of any use.
@chris I fully understand your point. I just wonder if HB Room can give us a warning in such cases? For example, when all boundary surfaces are not facing outwards.
ZoneFloorAreaTest.gh (94.5 KB)
Hey @farhang.tahmasebi ,
There are many ways to avoid the situation shown in your sample file.
Adding a warning is doable but I’m not sure that it’s really the most practical, particularly because these warnings might not have any meaning for people using Honeybee solely for Radiance simulation.
Also, if you just use the HB Visualize by Type component with your model and you’ll clearly see that you have made a floor where a roof should be and this is probably more immediately useful than the text in a warning:
To fix your script, you can just specify the _type_ of Honeybee Face when you create it, which I see you were already starting to do in your file:
Alternatively, if you just create your honeybee rooms using the HB Room from Solid component, you will have a Grasshopper definition with fewer components and (more importantly), you will never have to worry about this problem of your roof facing the wring direction. This workflow is probably what I would most recommend for cases of simple shoe boxes like your model here.
