Interface usability under heavy load

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.

Replies to This Discussion

Permalink Reply by Martin Siegrist on September 25, 2017 at 3:45pm

In the beginning, like 5 years ago, kangaroo required the use of a timer. There was a possibility to block the timer through the task bar.

Somehow Daniel Piker decided kangaroo works better without a timer.

I experience similar issues and wish there was a timer I could block.

Right now it's really annoying trying to double click on a Boolean toggle to pause the solver....

Permalink Reply by Bathsheba Grossman on October 5, 2017 at 9:27pm

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.

Permalink Reply by Cory on October 13, 2017 at 1:48pm

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.

Bugs

Probably! It's a dirty hack after all.

Relies on windows-specific functionality
May in certain cases forget about (and fail to close) old popup windows. You can just close them.
If you close a popup that isn't old, but the solver isn't iterating (e.g. it's converged), it will be interrupted next time it tries to run. Just turn it back on again.

Permalink Reply by Daniel Piker on October 15, 2017 at 9:09am

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.

Permalink Reply by Bathsheba Grossman on October 16, 2017 at 10:33am

That would be a huge improvement, thanks!

RSS