Feature suggestion: large calculation warning

Something I'd been thinking might be useful is a warning/confirmation pop-up box when making a connection that is about to trigger a very heavy computation.

For example, if you have 1000 points and you want to find their closest points on 1000 corresponding curves, but in a lapse of concentration you forget that one wire contains a list and the other is grafted. So instead of 1000 closest point calculations, suddenly in one slip of the mouse you have accidentally asked for 1000000 calculations (and often many more as the changes propagate downstream), you press escape and nothing happens, and you are left looking at task manager trying to figure out whether Grasshopper has crashed and wondering whether to force quit Rhino or wait it out.

What would be nice is a dialogue box with a

'this connection is about to create x zillion data items, are you sure ? - ok/cancel'

There could be a user setting for the threshold number of calculations. Ideally this would be weighted roughly according to how long different operations take, but even just a single number would be good, because a lot of the time I think it will be possible to know that any request for over 1 million, say, or 50 billion calculations was probably a mistake, or at least worth confirming.

Would anyone else find this useful ?

Replies to This Discussion

Permalink Reply by Luis Fraguada on February 26, 2012 at 11:04am

It would be nice to have. Maybe another way to implement it would be something like the profiler? This is kind of like a governor. Maybe if you have it on, every component where this limit is detected is disabled, if it is off, maybe it throws a warning to let you know of the big calculation ocurring...

Permalink Reply by Danny Boyes on February 26, 2012 at 11:22am

i think the foolish graft multiplier slip that Daniel is talking about would be the situation that I am mostly trying to avoid. The problem I see is that grasshopper does not know how long it will take before comencing a solution but it must be able to calculate how many times it will have to repeat it before commencing. And thus silly numbers throws a flag.

Permalink Reply by Danny Boyes on February 26, 2012 at 11:06am

Yes definitely!

Permalink Reply by Christian Schmidts on February 26, 2012 at 11:09am

would definitely save some time and nervs..

Permalink Reply by Eli Meltzer on February 26, 2012 at 11:55am

All for it!

Permalink Reply by Jacek Jaskólski on February 27, 2012 at 10:17am

My GH is performing a huge accidentaly triggered computation at the moment, so I thought why not +1 this wish while I wait...

Permalink Reply by Mateusz Zwierzycki on February 27, 2012 at 3:06pm

mom! please!

Permalink Reply by David Rutten on April 15, 2012 at 1:50pm

Hi Daniel,

I really dislike popping up dialog boxes that must be dealt with before anything else can happen*. I'd rather try and improve the Escape=Abort logic, since that is already supposed to deal with the case you described. The Escape key state is checked on every component iteration (unless those iterations are really close together in time) and therefore it should abort a long running process that is caused by accidentally grafting some of the data.

Would you agree that making sure the Escape key can be reliably used to abort a solution would be a better goal than popping up windows telling you how stupid you are?

The escape key will not work if a lot of time is spend inside a single component iteration, but then, those cases will require a per-component approach anyway since you need intimate knowledge of what a component does and how it does it in order to roughly predict the time it is about to take...

David Rutten

david@mcneel.com

Poprad, Slovakia

* it's also a problematic approach, as it is not obvious at all how this would be dealt with if a warning pops up during a Galapagos run or a Slider animation.

Permalink Reply by Oliver Sjöberg on April 15, 2012 at 3:25pm

I agree that the escape key could and should be used as an abort key but not being able to cancel a single resource-heavy iteration is maybe not as big issue as the waiting. My personal opinion is that the time waiting for a component to finish must be considered as well. As Daniel mentioned, sometimes you're in between the choice of a force shutdown or just waiting it out - but if there is nothing telling you there is actual progress many times you end up killing the task in the believe that you hit a bug or an infinite loop of iterations.

Would it be possible to add a progress bar and let the Grasshopper GUI still be fluid while calculating?

Permalink Reply by David Rutten on April 16, 2012 at 1:33pm

Hi Oliver,

Would it be possible to add a progress bar...

Unfortunately no. I have no idea how long any solution is going to take and thereford I also cannot know how far along we are at any given time. A progress bar that counts solved objects instead would not tell you anything you don't already know as it too would be stuck on a component that takes a long time to solve.

...and let the Grasshopper GUI still be fluid while calculating?

Again, no. At least as long as Grasshopper runs on Rhino4, the SDK functions I rely on cannot be trusted to be thread-safe. In short, that means that running a Rhino function on any thread that is not the main UI thread may result in unreliable data and severe crashes.

The Rhino core programmers put a lot of effort into making Rhino5 thread-safe, so this could theoretically be done in the future when I can drop support for Rhino4. But I'm sure there will be myriad problems along the way even then.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Daniel Piker on April 15, 2012 at 4:42pm

Thanks David,

Yes - a better Escape abort would certainly do the trick, and if reliable enough would mean no need for this sort of dialogue box (and I see what you mean about the problems this could cause).

I've attached an example that fairly reliably crashes rhino for me.

If I switch the toggle to start the huge calculation, but then abort within the first couple of seconds, everything is fine. However, if I let it run for a minute before aborting, the abort icon sometimes shows up, but then grasshopper becomes non-responsive, and I have to force close Rhino.

Am I correct in thinking that even when I press escape it still tries to draw as much of the solution results as it has calculated so far ?

Attachments:

abort_test.gh, 4 KB

Permalink Reply by David Rutten on April 16, 2012 at 3:03am

Am I correct in thinking that even when I press escape it still tries to draw as much of the solution results as it has calculated so far ?

Yes, that may well be a problem. Escape only aborts the solution, but all the data that has been calculated is just like regular data. Maybe I should at least clean the component that was busy while Escape was pressed.

David Rutten

david@mcneel.com

Poprad, Slovakia