can the SolveInstance method register new input or output parameters?

So that data coming in could affect the number/type of output parameters?

Replies to This Discussion

Permalink Reply by David Rutten on October 19, 2010 at 7:31am

Technically yes, but it's a really bad idea. Can you tell me more about what you want to achieve exactly?

If you want different types of output, just register Generic parameters and you assign whatever data type you want. Changing the *number* of outputs from within solveinstance can have all kinds of really awkward side-effects.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Benjamin Golder on October 19, 2010 at 7:37am

the number of outputs is really what I am most interested in. What are the awkward side-effects?

Permalink Reply by David Rutten on October 19, 2010 at 9:28am

Problem #1. Let's imagine someone hooking up wires to 6 output params. Then due to some computational fluke or human error* the solution gets short-circuited and you remove 5 of these outputs. Boom. All the wires gone. Now you'll have to hook them up again. This is the sort of thing that gets annoying after the third time.

Problem #2. The solution in Grasshopper iterates over all objects and solves each one in turn. Of course a lot of objects depend on other objects, so it usually becomes a cascade of objects solving themselves for the benefit of other objects. It is therefore very difficult to predict the order in which objects are solved.
The root iteration is the same as the display order (back to front), but the topology of the network complicates matters greatly. If you change the topology of the network during a solution, you might end up with whole portions of the network not being solved at all, or, worse, a conflict in the topology checker that makes Grasshopper think a network is self-referencing.

Problem #3. Grasshopper caches all manner of things about a network that can be recomputed from basic principles, but take a long** time to do so. If you start to expire caches where I don't expect you to, we'll either run into null reference errors, or stale cache data, or invalid cache data. Problems like these are very difficult to track down.

Problem #4. File IO. Components get deserialized from ghx files based on their default layout. In your case, we need to solve a component before we know how many outputs it needs. This cannot be done until the file has been completely deserialized. It's a chicken and egg problem, which will result in missing wires every time you open a file.

If you want to have a flexible number of outputs on your component, I'd suggest you add a menu item to your component that will change the output list when clicked, then causes a recompute. This way you won't mess with the network topology during solutions and people don't get their connections pulled out from under them. You'll need to do quite a few things to make this work, but I'll be happy to help you out there:

- Adding menu items and menu click handlers
- Properly removing parameters from a component
- Properly adding parameters to a component
- Recording undo for parameter changes
- Writing custom settings to a ghx archive
- Reading custom settings from a ghx archive and making sure your component is compatible with the ghx layout before it tries to deserialize itself.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

* This sort of thing has cropped up before and it has always been due to human error.
** 2ms or more

Permalink Reply by kyle steinfeld on December 7, 2012 at 2:44pm

David, Ben,

It seems I'm following Ben down the path of this bad idea, and just wanted to check if anything might have changed on this thread.

What I'm working on is basically a fancy parser. I'd like to monitor a folder location, parse all the files in that location, and generate a variable number of output params accordingly. Having read the thread above detailing the dangers of fussing around with the number of params, I'm prepared to accept the potential annoyances associated with problem #1, and will update only on a menu-item click and not from within solveinstance (which i think addresses the remainder of the issues).

Any advice along these lines? I'm currently trying to work out how to politely add or remove parameters from a component in my click handler. Any help or advice would be most appreciated.

-Kyle

Permalink Reply by David Rutten on December 7, 2012 at 5:29pm

Hi Kyle,

nothing has changed, however I think your case is mildly different. You want to adjust output parameters not based on a GH solution, but based on a File System event. This event can be handled outside of a Solution, which means that problems #2 & #3 don't really apply.

Do note that file system events are notoriously unpredictable so problem #1 is very much still there.

I think in your case the biggest problem is making sure your connections aren't wiped. I'm not really sure what the best solution to this is.

I attached a source file which kinda sorta synchs files in a folder with output parameters, but it would be so much easier if you could trigger this from a menu item rather than a File System event.

David Rutten

david@mcneel.com

Poprad, Slovakia

Attachments:

_TestFile.vb, 8 KB

Permalink Reply by kyle steinfeld on December 10, 2012 at 7:53pm

Yowza, thanks David!

It's my birthday today, so I've only just started to dig into this file... but a first glance suggests that this little gem of a birthday gift just narrowed the scope of the task in front of me significantly.

I'll be sure to post my modifications / results here once appropriate.

Kyle

Permalink Reply by kyle steinfeld on December 12, 2012 at 6:11pm

Hi David,

Thanks again for your birthday gift. For anyone else hunting down a similar problem, attached is my implementation based on your example. This version is working to parse single files that are updated only with mouseclicks, not monitored for changes (which is fine by me).

Some wierdness that I can't work out:

1. The referenced files remain locked for some reason, even though I'm reading them within a "using" construct, which I thought automatically closed the file once exiting the code block.

2. Serialization seems to work for the most part, but when I modify the referenced CSV (delete a column, for example) and then re-open the GH definition things aren't refreshing they way I thought they would. A manual refresh corrects this.

Any thoughts on these (admittedly minor) problems?

Thanks again,

Kyle

Attachments:

ParseEPL.zip, 71 KB

Permalink Reply by Benjamin Golder on December 9, 2012 at 12:18am

Wow, I never replied to this. But it was a great response David. I remember that the primary thing I was trying to solve was that I would often use the explode tree component to split off branches and would have to explicitly add outputs for every branch. This is not a problem with a few branches, but gets very tedious with 10+ branches if you're doing it repeatedly (which I was).

I think the Merge component handles this well in its inputs: if you fill up the inputs, it adds another. It would be amazing if the outputs of the explode tree component were handled in a similar way to the Merge inputs. Maybe if it's a purely additive process, it wouldn't be as problematic (outputs are removed manually and can be added automatically - if you plug in 20 branches, you get 20 outputs).

Thanks for replying to me over a year ago.

Permalink Reply by Vicente Soler on December 9, 2012 at 10:18am