Limit to Decomposing Zones

When I complete many Solve Adjacencies (solveAdjc), the program fails to “Decompose Based on Type” for some reason, getting hung up. Granted this could be my crappy computer, but it does seem there is some garbage accumulating in the honeybee behind the scenes stuff that is clogging up my ability to get at the solutions as I step through building the model.

This occurs only at the final “solve adjacencies”, where I join the previously solved sets of zones. There are 9 solves in all. In all I only have 32 zones, and I sequentially solve adjacencies so as to control the constructions joining sets of zones. Basically I was trying to have AIR WALLS connect floors and some adjacent zones similar to what was done in the YouTube tutorials created by Mr. Mackey.

I’ve tried joining them in numerous ways to no avail. The program seems to get hung up only when I try to display the results, as in the surface sorting and what not.

Perhaps there is a simpler way for me to stitch together my zones?

Any help would be appreciated! (559 KB)
thermal_model_geometry.3dm (2.64 MB)


This is the most detailed model of a house that I have seen with Honeybee. Thanks for taking the components to places where they have not gone before.

I opened your file and I was able to get the decompose based on type to run with your model, although, as you can see in the image below, it took 6 minutes:

I think that we will have to chalk this one up to the fact that you have 31 zones and at least 250 surfaces in your model, which is good if you are trying to study really detailed phenomena in this house but it probably more than you need to get decently accurate energy use profiles for the whole building.

It really boils down to what data you are trying to get out of the model. If you are trying to do detailed comfort map studies, I would recommend the level of detail that you have, although it might be better to split the house up into a few different GH files / energy models unless the phenomena that you are studying really needs to be informed by the energy flow through the whole structure. If you are just trying to get a good estimate for the energy use of the whole house, a lot of your zones can be combined into larger zones and surfaces combined into larger surfaces without affecting the results much.

Hope this helps,


I wonder if changing the access from item access to list access can help in this case for boosting up the performance. GHPython is not really efficient in branching data.


I was intrigued by your suggestion and so I tried switching it to list access with a for loop inside of the component. Unfortunately, it seems to have taken slightly more time (6.1 minutes), although I would call these runtimes pretty much equal:

(see attached GH file if you want to see for yourself)

Judging from what I know of the time-consuming functions in Honeybee, I am nearly positive that the long runtime of the component is the result of the recallFromHBHive() function. The fact that we make a deep copy of the zone and all of its properties really takes up the vast majority of time in many HB components.

It has occurred to me that, if we are not editing the zone, there is no need to make a deep copy of it. If you can confirm that this is true, we really should make a function that just returns the zones as they are. This would make this component and all of the result visualization components that I have written much, much faster.

-Chris (556 KB)

Ok, we are going to make a faster function:

I should have done this a long time ago.


Mostapha and Robert,

The “Decompose Based on Type” component now runs instantaneously with your 31-zone model (it’s now just 35 milliseconds!!!).

This change has also reduced the runtime of 10 Honeybee visualization components by a huge margin (many are less than 1% of the previous runtime). The improved components can be seen in this github commit:…

I can’t believe that I did not think of this earlier.

-Chris (527 KB)

Dude! I go away for the weekend and wham!

Thank you very much I will be testing this shortly.

FYI, the model is indeed for a comfort analysis as it relates to a small diameter duct system we are prototyping and testing in a laboratory. We are going to create a rather complex airflow network looking into air distribution over a wide range of climates and what not. I personally prefer to use Rhino and Python wherever possible and greatly appreciate your work.

Thanks and I will probably be posting other questions soon!


Honey bee is now a killer bee!

Thanks Chris! This is very helpful. I think there was another discussion that Grasshope posted while ago that can benefit so much from this change.

Thanks for the encouragement, Robert!Mostapha, yes, I remember Grasshoper working with a model that had over 50 zones which would also benefit from the changes. Anyone working with a model larger than 20 zones is likely to see some major improvements.