algorithmic modeling for Rhino
I'm running complex simulations that take a great deal of cpu time per iteration. It seems the entire grasshopper (and rhino) interfaces are blocking, waiting for an update from kangaroo before processing any user input. Though it would be nice to have everything usable while running, just being able to stop the solver would be a big improvement. Currently if iterations take too long it's not possible to get a double-click on kangaroo's 'On' bool through the system, and it's effectively crashed.
I'm considering writing code to check some external condition (existence of a file or similar) and try to force the solver to break, but am wondering if anyone has suggestions for a better way to go about this.
Yes, this is a longstanding problem. It wastes a huge amount of everyone's time, and I would think that adding interruptibility to Grasshopper, or at least to Kangaroo, would be a high priority for someone somewhere. But apparently it isn't.
If you come up with a solution, you'll be a hero.
Meanwhile, save everything all the time, and get in the habit of turning off the solver every moment you don't need it. Because you never can tell when you'll make one false move and have to kill Rhino and start over from scratch.
I believe the fault here lies with Grasshopper, not Kangaroo, as each gh module can't be expected to be independently responsible for keeping the UI usable. My guess is this is something its developers are aware of and hopefully intend to address in the next major version. Keep in mind it's still in beta (0.9).
That said, right now we'll work with what we have.
Here's a hack:
Create a python script with input "On" and outputs "On" and "I". Wire it up to the solver as so:
Then download and paste the interrupter code into the module. Now use the new toggle to activate the solver, and when it runs there will be a cmd.exe popup window. Ignore or minimize the window and go about your work. Pressing a key (or closing the window) will indicate you want to interrupt kangaroo, which should happen at the next iteration. If iterations are extremely long, you might still have to wait a bit.
How it works
By using a custom goal, we insert ourself into the solver's main loop, and can execute code at each iteration. The first time, we popup the window. Each subsequent time, we poll the window to see if it's still there. If it isn't, we update the On toggle to False, then raise an exception. Kangaroo doesn't know what to do with the exception, so it enters an error state, which frees up the UI. Grasshopper immediately processes the updated bool, which returns the solver to a clear (paused) state.
Probably! It's a dirty hack after all.
Thanks Cory for this.
I've also added for the next version a check inside the solver loop for whether the Ctrl key is down, and stop the iterations if it is. Hopefully this will help.
That would be a huge improvement, thanks!