Looping large quantity of load cases - Grasshopper Karamba3D Crash

Hi all,

I have a loop to run through and assess some 660 geometries (pre-generated) with 8 different load and support case combinations, amounting to >5000 different cases altogether to assess. Using the counter, I am iterating through each and appending the results to a csv file (via a simple python script). It seems to work for a number of cases but will invariably crash at higher iteration count, perhaps i>500. After iterating through a small subset around the crash points, the script is able to seamlessly run through these cases, so it appears to be a memory issue in rhino/ grasshopper for larger loops.

After outputting timestamps for each component, I don’t see an increase in the karamba components beyond expected variations correlating with increased mesh counts.

I’m scouring the SDK documentation, I’ve tried adding the ClearData() method at each iteration to the analyze component which did improve it originally but now crashing at a later iteration count.

Before it crashes, I’ve noticed I get no output from the analyze component and the crash dump file indicates a memory error;

  Message=Exception has been thrown by the target of an invocation.
  Source=<Cannot evaluate the exception source>
<Cannot evaluate the exception stack trace>

Inner Exception 1:
AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

I feel like this should be doable without a excessive amount of scripting , especially given the optimization precedents using karamba, so it seems karamba should be able to handle large number of loops.
Or does it require more scripting perhaps following this;
2.4.1: Cross section Optimization - Scripting Guide 2.2.0 and the cloning?

Any ideas or suggestions would be greatly appreciated!

Hi @Barney1,

sorry for the inconvenience. The cause of the problem could be a memory issue in Karamba3D. If it is is a conflict with the C# garbage collector the bug is hard to find since it can not be reliably reproduced. If however the crash can be reproduced please send me the model which crashes for debugging.

In case of a non-reproduceable crash: Try to remove components in the GH script (e.g. cross section optimization,…) until the crash does not occur any more. This would give a hint as to which component causes the issue.

What version of Karamba3D do you use?


Hi Clemens,

Thanks for taking the time to look at this.

Using Karamba3D

The crash re-occurs it just depends at which iteration, so it doesn’t seem constant hence why potentially a memory issue.

There’s nothing sophisticated like cross-section optimization, just a large set of pre-generated geometries and looping through these, solving using K3D and outputting results to a csv file in a little python script component.

Should Karamba + Grasshopper be able to handle iterating through thousands of load cases orwill the assemble component eventually crash?

Should i send my file through at info@karamba3d.com


Hi @Barney1,
please send the definition to info@karamba3d.com so that I can have a look. It would be ideal if the gh-definition can be crashed in a controlled way without having to wait too long for it to happen.
One question: did you check whether your machine runs out of memory?
– Clemens

Hi Clemens,

I will send the definition through. The definition does not crash in a controlled way unfortunately, it crashes after looping through for a few hours. I’m not entirely sure how to make this crash in a controlled way.

In terms of the machine running out of memory, one of my crash reports specifically identified the assemble component as being the culprit. In some of the simulations, it simply stopped outputting results before crashing for a few geometry sets. The computer has 32GB of ram.

Would there be something specific to the assemble component that would accumulate memory and potentially crash after a large number of loops/ iterations?


Hi @Barney1,
thanks for your definition. I will have a look.
It is probably a problem with premature C# garbage collection of C++ objects which are still in use.
– Clemens