Hello all!
I would like to batch-run a number of simulations within Grasshopper. More specifically, I would like to: (a) automate a bunch of sliders, whose input values are fed directly from a CSV file, and (b) store the corresponding simulation output/s for each simulation run.
I have written a Python script in Rhino Python Editor that does the above and works like a charm. Now, my scope is to implement the same within a GH Python component where a user may indicate the sliders (to be automated) and simulation outputs (to be stored), by simply plugging both as inputs of the GH Python component. The batch simulation would then be activated via a boolean toggle.
When implementing the above logic within a GH Python component, I ran into the following problems:
-
The component seems to end up in a recursive loop
-
The values stored in the simulation output components (‘deflection’ and ‘weight’) seem to reflect only the last generated values (refer to attached image).
After reading other forum posts, I am aware of the issue with calling a new solution within another solution, however still feel uncertain about the way forward (especially since most posts discuss approaches in terms of C# not Python).
I would appreciate any form of help 
Cheers
Zack
It’s a bit difficult to understand what exactly the problem is. There seems to be several, likely unrelated, issues and questions going on at once. Perhaps you could separate these concerns into more clearly defined questions and also provide minimal definitions that demonstrate them. Or at least one definition to analyse and debug.
That said, I would recommend implementing/automating the Gene Pool (Genes) type as opposed to lists of sliders. In my experience this simplifies things quite a lot. Alternatively, I would probably operate on the names of the sliders when getting/setting their values. Finally, remember to expire the sliders/genepools once you fiddle with them through code. This might explain some of the behaviour you’re describing.
Best, Anders
Hi Anders!
Thanks for your reply. Apologies for the unclear description.
Thank you for your suggestions however I would like to avoid using gene pool or calling out sliders by name if possible. At most, I can call them by their GUID. In my current implementation, I make use of ExpireSolution(True) after setting the value of each slider.
I am attaching a simpler definition as you suggested. In brief, when flagging the toggle, the component reads a list of slider values from a text file (see attached .txt). One row of values in the text file corresponds to one combination of slider values, i.e. one (simulation) run. On each run, a simple addition is computed (acts as a replacement of a simulation analysis). Now, my scope is to store the simulation output computed on each run.
However, as you should observe, the issues are two:
-
The component computes recursively,
-
When printing the value stored inside ‘simulation output’ on each iteration, it seems that only the last computed ‘simulation output’ value is recorded (3 as a result of the last row of input values 1, 1, 1).
I have a feeling issue 2 might be a consequence of issue 1.
Hope the above clarifies and thanks for your time!
input_values_debug.txt (45 Bytes)
automate_sliders_example.gh (12.1 KB)
There’s an undefined variable in your code, the first one outputStrings being passed to the main function in the script. There’s also a bunch of other, less critical stuff, going on that I took the liberty to point out:
Edit: You may have experienced a “phantom variable”.
I suspect that the problem is that you’re running “inside” Grasshopper, and not on a background thread.
That’s why the component with the script keeps re-triggering itself, which gives strange results.
In C# I use a backgroundworker, no idea how to do this in IronPython. It might well be that that’s not possible (?).
I don’t think ghpythonlib.parallel is a solution, since I assume that it runs “inside” Grasshopper, too, but am happy to be proven wrong.
Do you agree, @stevebaer, @DavidRutten?
I am definately not a Python programmer but I may have an hint (without analysing your code in depth, please apologize if I am wrong): it looks like you are expiring your component during the solving. According to David’s explanations on a different thread, the expire ‘shockwave’ runs way before the actual calculation. So, the infinite loop you are experiencing may come from this : the component is expired, it expires all downstream components, the solving starts on a logical order, during the solution your component expires again the solution, and it loops!
