Memory Issue in Grasshopper: Rhino 6 vs. Rhino 7

I have the following issue with Rhino 7:

I’m running optimization with Ladybug 1.2.0 Incident Radiation and Direct Sun Hours simulations.
After around 1000 iterations, the optimization will crash due to my 32GB of memory being full.
While running the optimization, I can see the memory usage increasing linearly.

When running the same file without the LB simulations, memory usage remains stable.

However, on Rhino 6, this problem is much less pronounced and memory usage is increasing much more slowly. (Same version of Grasshopper, Ladybug and Radiance.)

Accordingly, this looks like a bug in Rhino 7 to me. (Or is it a feature?)

Any ideas, @DavidRutten?

I thought LadyBug’s daylight is solved by RADIANCE? Have you checked whether Rhino or Radiance eats up the memory?

I don’t know how to check (I can see only the total memory consumption for Rhino), but I don’t think Radiance is the culprit: I’m using the same version for Rhino 6 and 7.

If it’s rhino.exe that eats up the memory, I’d be suspicious about the display pipeline. Maybe temporary geometry aren’t cleaned up promptly.

There’re memory profiling tools… but maybe too overkill for this job.

I doubt it.

Have you run this by the folks who write LadyBug?

– Dale


– Dale

If indeed everything else is the same and Rhino.exe, instead of RADIANCE, eats up the memory, some major change of Rhino leads to the deterioration and the first thing coming to my mind is the improved display pipeline (not necessarily on the Rhino part).

@ParamDesSing however I’d recommend you to upload your GH definiton and related files if possible, so that we can better diagnose your issue.

Hi @ParamDesSing!

without being very knowledgeable, this might have to do with the mesh/ray intersection code changes in Rhino 7. They should provide more reliable outcomes, but might also give some grievances with some unthought incompatibilities. This is entirely speculation, though.

@chris12 might know something to help me out here.
I’d also like to investigate this directly, if you are able to provide a sample, Thomas?
Can you by any chance send something where I can test this?

I started adding a link (RH-63426) to our internal bugtracker, but we need more info for this to result in changes.



Giulio Piacentino
for Robert McNeel & Associates

Hi @piac,

Thanks for your comment!

The mesh/ray intersection code looks like a promising suspect.
I’ll share the definition with you and @gankeyu privately, since it relates to as yet unpublished research.

Here’s an update from my end, with tests on a different computer:

  • With Rhino 6, I managed to run 10.000 iterations in about 9 hours, without a crash.
  • Currently, I’m testing Rhino 7 again. So far, it’s done about 1.300 iterations in about 10 hours, and the memory is getting full, so I’m waiting for it to crash.
  • The versions for Grasshopper (1.0.0007), Ladybug (1.1.2) and Radiance (5.3) are identical.

Hi Thomas @ParamDesSing

sure, could you please make it as small as possible? It might prove impossible to debug it if the definition is too large!

OK, just sent you the original.
It’s not too complicated, but let me know if I should reduce it.


Yes I’d need some help reducing it. I answered the PM.

@piac , Here’s an example file I’ve simplified as much a possible.
It generates ten shapes and simulates their direct sun hours with Ladybug 1.1.0.

Without the simulations, there’s no memory increase for Rhino 6 and Rhino 7.
On Rhino 6, the simulations increase memory use by 2GB.
On Rhino 7, the simulations increase memory use by 6GB.

For my actual file, this means I get much faster results in Rhino 6.
With Rhino 7, it’s much slower and eventually crashes.
Probably there’s other things going on there as well, but this to me seems to be the key issue.

PS: You’ll need an *.epw file to run this. I used Houston Texas, but any location should do. (390.9 KB)

Now I think this might be related to this here: Visibility intersect py error - #13 by jaredf - ladybug-tools - Ladybug Tools | Forum and possibly IronPython exception handling. Does updating Ladybug fix this?

Maybe @Mostapha or @chris12 can help here. I see 1.2.0 on the food4rhino page. I know there was a required fix for V7 SR3 and above -linked to in the post above-, and I would like to just make sure you are equipped with it, so that we use all the same version.

Yes, that’s the version I have.
(Sorry, I confused myself about the numbering, but I should have the most recent version.)
Did you test the file I sent you? Do you see the same?

Hi Thomas, @ParamDesSing

Would you help me check more?

Here is what I get with LadyBug 1.2.0 and Rhino (7.5.21082.11001, 2021-03-23) (396.2 KB)

It could be that some versions behave slightly different. I’d need to know from you precisely what to look for, and which versions you are using, of:

  • Rhino
  • Ladybug

Thank you!

Hi @piac,

Did you actully run the DirectSunHours Analysis? I’m asking because it’s orange in the screenshot and should take way longer to computer.

My version are:

  • Rhino Version 6 SR34 (6.34.21034.7001)
  • Rhino Version 7(7.4.21078.1001)
  • Ladybug 1.2.0


Thomas, I only ran exactly what you sent. Please, again, simplify and specify what I have to do because I don’t know and cannot be expected to test every combination of inputs in the solution.

I need to set Run => True in the last component? What else?