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?)
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 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.
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.
Thanks,
Giulio
–
Giulio Piacentino
for Robert McNeel & Associates giulio@mcneel.com
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.
@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.
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?
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?
