'Honeybee_Glazing based on ratio' crashes Grasshopper/Rhino

[saeranv]

When I add glazing to my HBZone using the Glazing based on ratio component - Rhino is immediately crashing. It will work if I'm generating a 1-5 floors (with 5 zones each) but if I try to generate glazing for an entire tower (as I am in the sample gh file) - I'm getting an immediate crash.
Here's a link to my forum post with a gh file reproducing the problem.

http://www.grasshopper3d.com/group/ladybug/forum/topics/honeybee-glazing-based-on-ratio-crashes-rhino-for-large-amount-1

[chriswmackey]

@saeranv ,
I have noticed that this tends to happen more often when people use the splitbldgMass component before the glazing ratio component. My inclination is to say that the code that needs improvement is there rather than in the glazing ratio component.
Also, it's important to realize that the underlying reason is an instability within Rhino/GH and, while there may be better ways of organizing the code so that this does not happen, I don't know if we will be able to fix it completely.
-Chris

[saeranv]

@chriswmackey that's surprising, do you have any idea what it could be in the splitBldgMass component that would be causing the issue (i.e. is it to do with the floor height splitting or to do with the perimeter core split? I'm a little wary about trying to debug this component since debugging code that crashes Rhino/GH is a nightmare, but I can try and keep an eye out while dealing with the splitBldgMass components for issues.

[antonszilasi]

@chriswmackey @saeranv @mostaphaRoudsari

I did some investigation with the profiler, what ever is happening it is increasing the processing time in a strange fashion.

With 10 honeybee zones:

With 20 honeybee zones

With 30 honeybee zones

with 50 honeybee zones

with 60 honeybee zones

It crashes at around 90 zones, I am going to dig into the code next week with the python profiler tool to try and see where the hold up is occurring, Chris or Mostapha have you seen something like this before?

[antonszilasi]

The plot thickens I re opened the file and now the process time in both the 20 hb zone case

and the 50 hb zone case has halved!

I think this a deeper issue to do with deep copys of zones, @mostaphaRoudsari what are your thoughts on this? I'd like to get to the bottom of this if it can be fixed/ improved upon

[TheodoreGalanos]

Hi everyone,

I'm not sure this is completely relevant but I am also facing some problems with the combination of split building mass and glazing based on ratio components. I keep getting that annoying "outward facing angle of subsurface differs more than 90 degrees" error that crashes my E+ simulation. Passing the same zones without adding glazing seems to work.

I hope there's some work around for this.

Edit: Not sure this is at all relevant but it seems to be the ground zones failing the E+.

Regards,
Theodore

[mostaphaRoudsari]

@antonszilasi profiling is a different issue and you should open a new issue for that one. My suggestion is to do the same study on Rhino WIP and Grasshopper I. I suspect that GHPython component itself has a lot to do with this issue. Check this post.

[chriswmackey]

@antonszilasi ,
The decrease in runtime can be explained by the fact that the code was already compiled the second time that you opened the file. Compiling code after an edit can add to the runtime a lot. As @mostaphaRoudsari suggests, a lot of these issues likely have to do with idiosyncrasies of GHPython and Rhino Common of Rhino 5. We should start looking to the next release of Rhino for the best fix to many of these issues.
-Chris

[antonszilasi]

@chriswmackey

Ah so each time you run a Gh component the code is compiled? so if you change the code it has to compile again?

[chriswmackey]

@antonszilasi ,
Yes, that's how the GHPython compiling usually works. Part of the increased speed with the new Ladybug is that there should be less compiling time overall as the library gets loaded once.
-Chris

[chriswmackey]

@saeranv and @antonszilasi ,

@mostaphaRoudsari and I finally figured out what was causing this (and other issues with large Honeybee models) a few weeks ago. It was the result of a runaway memory process that was happening after you tried to edit/copy zones that had solved adjacencies.

Specifically, after solved adjacencies, each subsequent component would copy all adjacent boundary surfaces when it copied the zones. This on its own would be fine but, because each adjacent surface also has a parent zone, a parent zone would be copied for each adjacent surface. And those parent zones would have other child surfaces and the whole thing just blew up your memory when you have more than a few zones

Needles to say, we have fixed this now and all problems associated with this issue should go away:
806188a

Thanks for pointing us towards this and you've helped solve a problem for a lot of people.
-Chris

[mostaphaRoudsari]

We were using copy.deepcopy and in this case it was copying more than what was needed because of what @chriswmackey mentioned. The solution was to customize the copying process.