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;
System.Reflection.TargetInvocationException
HResult=0x80131604
Message=Exception has been thrown by the target of an invocation.
Source=<Cannot evaluate the exception source>
StackTrace:
<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!
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.
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?
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
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
Hi @Barney1 did you manage to find a way to solve this?
I’m having the same problem while looping through around 1000 geometries. It just stopped outputting results before rhino crashes and runs out of memory.
Hi Clemens,
Thank you for reaching me out and sorry for the late reply!
Yes, I’m actually having this problem using the latest version (3.1.4051).
A little bit of context. I am creating and storing the results of different structural topologies (iterating shape, distance between beams, size, number of floors, and a few more variables).
At first, I ran out of memory in 200 iterations but I managed to increase this to 1000 by putting together the assembly, analysis, and optimize components in one c# script component. However, now I had to increase the number of floors and the script stopped outputting results after 400 iterations. I ran the iteration with the Karamba3D components disabled and had no problems.
