Massing studies with Honeybee - Speed of Zone and Window Creation

grasshopper honeybee-legacy
,
1

First off: huge thanks to the excellent development team of HB and LB! These are really amazing tools!

I am developing workflows for running schematic energy analysis on urban development massing studies. Specifically, I am looking at variations on a perimeter block that has small towers on top of it (image below). I create zones with ‘Honeybee_SplitBuildingMass’ and add glazing with ‘Honeybee_Glazing based on ratio’. In the model below there are 116 zones.

Here are some observations/questions:

  1. I am able to create these zones on one pass but Rhino/Grasshopper crashes immediately if I try to create windows on one pass. If, however, I separate the base from the towers before adding glazing, things work out fine. (Note: It has to be done in this specific way - splitting the zone list in some random way does not help). It would obviously be nice if it were possible to avoid the extra step of separating the zones (towers from podium) before window creation. I would like to be able to automatically generate zones for more complex geometries (still just boxes though).

  1. While testing different options for generating windows with ‘Honeybee_Glazing based on ratio’, I noticed that the component is really fast if I use it before applying ‘Honeybee_Solve Adjacencies’. I would guess about a thousand times faster. Why might this be? The downside is that I get windows on all the interior walls…

Any thoughts on how I could streamline these workflows? Any thoughts on further development of these components from the development team?

  1. Finally, a wish: it would be really great to have a fully fleshed out ‘Dump Honeybee Objects’ component. With large models there is a good chance that GH freezes or crashes and it would help a lot if I could save HB zones along the way.
2

Hi Ernst,

  1. Rhino crashes is almost always happening because of some split/intersection calculation. I think when you have the geometry as a single mass it fails to intersect them right at the connection when the change happens. If you move the plane a little bit higher I think it will solve the issue.

  2. It should not really happen. We will take a look into this and report back: https://github.com/mostaphaRoudsari/Honeybee/issues/499

  3. Totally agree. The reason that we don’t actively work on new features such as dumpHBZones is the fact that we’re re-writing honeybee (https://github.com/ladybug-analysis-tools/honeybeex) were many of the current wishes will be address in a much more elegant way.

The current development, as powerful as it is, is limited by geometry operations of Grasshopper (Number 1 in your least) and is not as flexible as it should be in specific cases (number 2 in your case) and the new library will address this by providing an API which can work on top of Grasshopper or Dynamo or neither of them. That will open up opportunities to develop more flexible, customized workflows for cases such as yours.

3

Hi Mostapha,

Thank you for the comments. I look forward to seeing the new version of HB!

Could you elaborate on 1. I am not sure I understand what you mean by “If you move the plane a little bit higher I think it will solve the issue.”

4

Ernst,

As for your point 2: Mostapha and I finally figured out what was causing it a couple of months ago. You should now find that the glazing ratio component runs just as fast before solve adjacency as it does afterwards. It was a big memory bug that has now been fixed.

-Chris