Emergency Stop for solution calculation

Replies to This Discussion

Permalink Reply by Ching on August 31, 2012 at 6:45pm

I think the escape button already does that, although it can still be unresponsive with large definitions.

The new component Data Dam is pretty useful for keeping large definitions under control. A few Data Dam at key locations can turn a potentially BSODing large calculation into several smaller managable ones, and for calculations that does not change often you can have the data buffered at the dam (by disabling the stuff before it) to save CPU time. I'm liking this component a lot atm.

Permalink Reply by Mike Calvino on August 31, 2012 at 6:50pm

Yea, I just saw that DataDam component.  I tried Esc, but it didn't stop anything.  had to EndTask.  I'll play around with the DataDam, thanks.

Cheers!

Permalink Reply by Michael Pryor on August 31, 2012 at 7:49pm

Also I find it beneficial to lock the solver when changing a lot of stuff, then unlock when done. In .9006 esc is alot more responsive then before but still can hang up. 

Permalink Reply by David Rutten on September 1, 2012 at 4:03am

When the Grasshopper solver runs it will make the Rhino+Grasshopper process unresponsive. Basically it hogs all processor cycles allotted to the Rhino application. This means that things like mouse-clicks and key-presses are no longer handled (as that would require processor cycles). I specifically check the state of the Escape key* at relevant points in the solver process. In 0.9 I also periodically check during data conversions (for example when you plug a Text parameter with 50,000 bits of text into an Integer parameter, I need to evaluate 50,000 bits of text to see if they describe valid integers). This has improved the responsiveness of Escape behaviour on files with lots of data inside individual parameters. However, it's still possible that large chunks of code run without any escape checking. Especially individual operations that take a lot of time (like massive solid booleans) can still 'lock' the application. There's very little I can do about this without rewriting giant portions of the Grasshopper core, it's a long term project at best.

In the meantime, locking the solver and DataDams are your best option when your file becomes too big to handle.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

* Technically I check whether the Escape key has been pressed since last I checked. 

Permalink Reply by Tyler Selby on October 15, 2012 at 4:07pm

Late in developing a definitions I often might need to make a few changes when there are a lot of items already flowing along each of the connection lines.  Sometimes I need to experiment around a bit, which sometimes leads to long wait times when I adjacently connect something that shouldn't be intersecting with another.

Would it ever make sense to have a component that specifically checked for the escape press more often?

OR

Perhaps a "clinch pin" that temporarily cuts down the flow from a all the items in a data tree to a single item that can be used for testing with the component   It would be easy enough to add an list item component  but adding and then deleting all the extra components can become messy in itself.  

Visual reference of what the wire might look like in a mode where flow is restricted;

 

Permalink Reply by pjbazel on October 2, 2013 at 5:41pm

How exactly do you 'lock the solver' ?

Permalink Reply by David Rutten on October 3, 2013 at 3:25am

Middle Mouse button, Lock icon:

It's also in the Solution menu under "Disable Solver".

--

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by Nik Willmore on May 10, 2015 at 1:41pm

FRUSTRATION LEVEL 9.99:

Have you considered therapy to break through your passive-aggressive refusal to allow users to have real control over Grasshopper behavior and flow, and your refusal to actually check for the escape key to stop *all* scripts and *everything* NO MATTER WHAT like the brakes of a car?

I lack even a button component to retrigger a Grasshopper program that AUTOMATICALLY STOPS *AND* USEFULLY PAUSES WITH PREVIEW BUT ALSO *TOTALLY* RELEASES RHINO FROM GRASSHOPPER CRAP until the button is again clicked, then the solution will update. Otherwise, as you are fully aware, slow creepy Grasshopper will basically just shut down Rhino use as a talented designer moves objects around in Rhino that Grasshopper is set to Pipeline import and act upon, even with a Data Dam in place. But *no* I do not want to up and out cancel and thus erase the last invoked Grasshopper solution and useful preview that the designer damn well needs to see in order to work on stuff.

It's the little stuff like this that ruins the advanced problem solving issues for us developers of real uses of Grasshopper. Python can't even command Grasshopper workflow for real, so it's always a hack or a kludge or you just find a C# script that works instead that you can't even edit as a black box with no open source.

Please three years after this thread comment, GIVE US TOOLS TO MAKE GRASSHOPPER PROGRAMS WORK AS LAYER WATCHING RHINO PLUGINS/SCRIPTS THAT THE CASUAL DESIGNER HAS CONTROL OVER *NOT* AUTOMATICALLY KICKING IN EVERY TIME HE MERELY MOVES AN OBJECT IN RHINO! I need to offer that designer a BUTTON that just updates the Grasshopper result without having to ERASE the old result as a useful preview when he just moves an object, because the solver is disabled and Grasshopper freaks out.

Grasshopper reminds me of why Steve Jobs went to war with Adobe and Flash.

After so many years, why is there no Grasshopper 102 manual for this sort of basic flow control?! I'm having to use Python scripts with system timers in order to merely catch long loops and thus stop execution. Unreal. If Windows Task Manager can nuke Rhino, why can't you give us a button to just STOP instead of having us lose our work in Grasshopper and Rhino? This is insane.

What every normal Rhino user wants from us Grasshopper kids is just a BUTTON to eventually update the solution, while holding the old solution preview *intact* before that. I can't offer them that button?! This takes me a whole weekend to even begin to figure out?! Rent in NYC is expensive. Such time wasted is money lost. Everything I try is a damn Catch-22 and I'm about to be homeless because Grasshopper is stuck in Nerdville.

Permalink Reply by David Rutten on May 10, 2015 at 3:12pm

Hi Nick,

"and your refusal to actually check for the escape key to stop *all* scripts and *everything* NO MATTER WHAT like the brakes of a car?"

if it was doable, I'd do it, but Grasshopper runs on the main UI thread which means that no key presses come through until the process is done. Right now I check for escape key state (circumventing the key-press events) at certain points during the solution, but the more I check the more I slow down the solution, and there are large areas where I can't check because it's not my code that is taking up all the processor power in the UI thread.

"Python can't even command Grasshopper workflow for real, [...]"

Sorry I do not know what that means.

"[...] you just find a C# script that works instead that you can't even edit as a black box with no open source."

Again I do not know what that means. C# script components are always open source because they carry their code with them.

"I need to offer that designer a BUTTON that just updates the Grasshopper result without having to ERASE the old result as a useful preview when he just moves an object, because the solver is disabled and Grasshopper freaks out."

That's probably something I can add. If the solver is disabled, I can make it so that you can run a new solution without expiring everything that was not affected in the mean time. 

"If Windows Task Manager can nuke Rhino, why can't you give us a button to just STOP instead of having us lose our work in Grasshopper and Rhino?"

Windows can do it because it sits on top of the programs it runs, and it can take however many processor cycles it feels it needs. This is not possible from within a program. It basically requires that the solution runs on one or more threads that do not block the UI message queue, so mouse and keyboard events still come through. However GH1 simply wasn't designed to be a multi-threaded program (in fact back when I started the Rhino SDK was not remotely threadsafe) and this is not something I can just enable overnight.

"[...] while holding the old solution preview *intact* before that. I can't offer them that button?!"

That is not entirely possible. When a component is expired because it depends on a Rhino object that gets changed, it will destroy all its local data and also cause the components that depend on it to clear out. So keeping the solution intact while you change inputs is not something that is possible without breaking and rebuilding the program. 

"Rent in NYC is expensive."

As indeed is the price of cheese. 

"Everything I try is a damn Catch-22 and I'm about to be homeless because Grasshopper is stuck in Nerdville."

Look, if there's a specific problem you have that I can help with, I'd love to help, even on my Sunday off. If the problem you have requires a rewrite of the software, then expect it to take a while. I know there are major shortcomings and problems in GH1, but not all of them can be realistically dealt with, maybe not even in GH2. As with you, I also have limited resources and I'm now at the point where it makes more sense to invest those resources in developing GH2 from the ground up (with multithreading in mind), rather than ineffectually patching up the nightmare that is GH1 code.

Permalink Reply by David Rutten on May 10, 2015 at 3:37pm

I just made it so that when F5 is pressed while the Solver is disabled, only those objects that were expired are recomputed. This is a breaking behavioral change, so if people complain this is worse than before I'll have to add a second menu (Ctrl+F5 ?) that does a soft-recompute.

This change will be available in the next Rhino WIP release.

Permalink Reply by Nik Willmore on May 10, 2015 at 10:47pm

I understand a bit better now. If I leave the solver disabled, the current F5 will do a single full program run for me, which is exactly what I want, though indeed it would be better if only updated parts in fact ran.

I'll have to just ignore Grasshopper preview and create my own previews via a Python baking script. Otherwise I'll lose my preview when disabled Grasshopper removes it after I play around in Rhino, though it retains it before that even though the solver is disabled. Too bad about that sad behavior. Alas to use F5 the Rhino user has to switch to Grasshopper. Maybe a control panel button could invoke a Python script to invoke the F5?

Permalink Reply by Nik Willmore on May 11, 2015 at 4:47am

Here is my Python script that gets around losing Grasshopper preview when the solver is disabled and you change something in Rhino that the script is attached to via Pipeline or I assume any old geometry assignment. It first deletes anything in my assigned Output layer in Rhino, then finds that layer's index number and bakes my calculated mesh into the layer and locks it so it acts as just a preview instead of a selectable object. Further, I use rendered mode to control how that layer appears via Layer Material settings.

KEYWORDS: Python, baking, script, layer, layers, AddMesh, AddBrep.

import rhinoscriptsyntax
import Rhino
import scriptcontext

scriptcontext.doc = Rhino.RhinoDoc.ActiveDoc # Speak to Rhino instead of Grasshopper.

rhinoscriptsyntax.Command('selNone') # Select none.
rhinoscriptsyntax.Command('unlock') # Let me nuke 'em.
rhinoscriptsyntax.ObjectsByLayer('Nik Mesh Cocoon Output',True) # Select all objects in the output layer.
rhinoscriptsyntax.Command('delete') # Nuke 'em.

attributes = Rhino.DocObjects.ObjectAttributes() # Get generic object attributes.

attributes.LayerIndex = Rhino.RhinoDoc.ActiveDoc.Layers.Find("Nik Mesh Cocoon Output", False); # Get layer number from Rhino and assign it to our object.

Rhino.RhinoDoc.ActiveDoc.Objects.AddMesh(Mesh, attributes) # Bake the Mesh input to this Python script.

rhinoscriptsyntax.ObjectsByLayer('Nik Mesh Cocoon Output',True) # Select all objects in the output layer.
rhinoscriptsyntax.Command('lock') # Lock mesh in Rhino to allow further NURBS editing on top of it.

scriptcontext.doc = ghdoc # Restore script ability to speak to Grasshopper.

• ‹ Previous
• 1
• 2
• Next ›
• Page