(This is my first post in the new forum. Thank you very much, the LB+HB team!)
I got the following strange result for a simple rectangular zone when using the splitBuildingMass component to create perimeter zones:
Appreciate if guys here can advise what’s the source of issue here.
May I also ask if there are general suggestions for using the splitMass component which is unpredictable sometimes…
Thank you.
perimeter_zone_error_v002.gh (476.7 KB)
Hi @Grasshope,
Welcome to the Forum. Please observe the order of vertices using native GH DeBrep component. The vertices of the bottom surface of your brep are clockwise. However, the order of vertices of the top surface is irregular. I believe that is the cause for this issue. Creating a new box by tracing this geometry solves it.
Thanks, devang.
The rectangular zone is produced by extruding a rectangle brep upward.
However, I found that, using the same workflow as shown below, the outcomes of slipMass are quite different for two rectangles with the same order of points, though in different directions.
I’m not sure why there is the difference. If direction of the order of the corner points of a brep matters in this case, how to change the direction?
perimeter_zone_error_v003.gh (479.0 KB)
… and it doesn’t work for the 3rd brep shown below which has the same direction of corner points as the 2nd brep.
The error message from the splitMass component is:
Failed to generate the perimieter zones for one floor as the floor’s geometry is not accomodated by the script. The floor will be returned as a single zone.
perimeter_zone_error_v004.gh (480.6 KB)
… I tried a different way to extrude the brep surface by using the ExtrudeAlong component.
It works for the first 2 breps, but not for the 3rd one, strangely …
perimeter_zone_error_v005.gh (482.3 KB)
@Grasshope,
Tracing the surface using a box in rhino seems to fix the issue. But we should definitely find out the source of this behavior.
Yes, devang, I agree that the source of the issue for this component needs to be investigated carefully as this is such an important component to get a more realistic thermal zone subdivision.
The frustrating thing is that it works sometimes for relatively complex concave geometry but not for simple convex geometry …
@Grasshope @devang I tested all the failing breps with the new HB_SplitFloor2ThermalZones component, and they are splitting correctly:
You can find the new component in tab 13 | WIP. We used a more appropriate algorithm for identifying shapes and splitting thermal zones for this one, so it should be a lot more robust. It won’t fail due to unmatched top/bottom vertices because it just takes the vertices from the bottom surface, and cycles through them to identify the angle bisectors that intersect at the shortest distance from a parent edge to generate thermal zones. It will however fail if the vertices in the bottom surface aren’t ordered in sequential, counterclockwise order - as is convention - but I have yet to encounter this problem.
It’s still a WIP, so while it should deal with relatively complex convex shapes:
… I still have to implement (and borrow from Chris’s code) methods to deal with concave and courtyard shapes. So unfortunately, if you do need concave/courtyard geometries split up, you will have to use the old component for now.
ETA: FYI @Grasshope: before the latest HB legacy release, I went through all the various SplitBuildingMass errors you documented in the old grasshopper forum and tested them out. If I recall correctly they all worked with this new component… But I’m sure it’s only a matter of time before you figure out all the ways the new component fails as well 
Dear Saeran,
Thank you very much for the clarification.
I understand that the ideal scenario is difficult to achieve: a component which can deal with a single overall massing of a building in arbitrary form.
Even with the legacy splitMass component, we may still get a core zone in concave shape for a concave building which may cause trouble for EnergyPlus. So, I assume that you may agree that the desirable approach is the one which may involve a bit of manual work: prepare the massing of a building by dividing it into, as few as possible, individual convex volumes, each having a uniform height, before using the splitMass or split2Zone components (as shown below), although this may imply a sharp increase in simulation time due to significant increase in the number of thermal zones.
The visualization of Energy Use Intensity (EUI) for each zone is quite different between the models with and without perimeter zones, but the total building EUI values are quite close in this case (187kWh/m2 for the one with 140 zones, and 186kWh/m2 for the one with 16 zones). I may need to further check if this is the case for different buildings…
Eventually, it comes down to the level of accuracy and efficiency we’re expecting for energy modeling between the options of 1) just getting one single zone for the entire floor, 2) differentiating perimeter and core zones for each floor, or 3) creating detailed zone layout based on actual design for each floor.
Nevertheless, I really appreciate all the hard work you and the team are conducting in refining the functions of the LB+HB components. I hope you understand that I don’t mean to “pick bones”, and I look forward to the updating of the new split2Zone component to deal with concave and courtyard geometries.
I know that this issue has already resolved itself but I just wanted to make sure that you heard it from me: I recommend using @SaeranVasanthakumar 's component over the original splitBldgMass component. I was actually thinking of reversing the current placement of the components at the last stable release: the original component should be in WIP and @SaeranVasanthakumar 's component really should be the official one. As @Grasshope says, people can always subdivide a concave building mass into convex elements and, the more that I think about it, the more I feel that this subdivision should be done manually by the user. We just need to make sure that the component gives a warning anytime concave geometry is plugged in. @SaeranVasanthakumar , would you like to take a stab at this or like me to take a stab and then we can switch out the placement of the components for the github version?
Thank you, Chris.
I agree that a “concave geometry warning” will be helpful to remind the users to manually “clean up” the geometry, and this will benefit the downstream energy modeling workflow eventually.
@Grasshope,
I could not agree more. I am myself working towards developing a component to identify concave surfaces in geometry. https://twitter.com/DevangGC/status/898781235538829313 Hope to finish it soon.
Thanks @chris @Grasshope! That is a good point - it make sense to get a stable, convex geometry solution out as the ‘official’ version, and then keep the older component in WIP until we can get concave/courtyard geometry working consistently in the former.
I think I can take a stab at it @chris. @devang if you are working on concave checking already, perhaps we should collaborate? I’ll start a git issue on this so we can discuss further.
@Grasshope, to go back to your comment regarding the energy use impact of split zone - I agree it is very important. As you probably already know, the default model for air temperature in a thermal zone is “well-stirred”, meaning there is only one mean air temperature to represent a floor [1]. By splitting zones, we are instead treating a floor as a thermal network of nodes: each node being a zone of well-stirred air, and links between nodes defining the rate of heat transfer between them.
This means we can redefine the composition of air temperature, and thus overall energy loads, quite significantly (for certain building geometries and programs) if we split zones. I.e. high solar gains hitting only one side of a floor would be mixed, and moderated in a single-zone, but would be separated and more accurately captured in a perimeter-core model.
@SaeranVasanthakumar ,
The plan sounds good. I imagine that you could write a good concave-checking function by looking at the angle between the points:
Also, Honeybee already has some functions to test if the points of a surface are counter-clockwise:
@SaeranVasanthakumar,
Yes, I am already working on it and I would be happy to collaborate.
Yes. I would also prefer not using this topic to discuss development.
@chris,
Thank you! I have gone through a lot of posts on stackoverflow. The function you pointed to will certainly help. As determining the order of vertices is central to concave detection.
