Can Two GrassHopper definitions communicate?

Can yes, but as always the question is what should happen if more than one file path is provided.

This is such a common problem that a consistent answer really is needed eventually. So many properties of things could be exposed as inputs, but would either not work or be undefined or convoluted if two or more inputs are provided. Slider and Graph mapper ranges have the exact same problem.

Well,
we could start by allow only one path for the time being. And if users come up with various needs we could address them in a more systematic way.

In my case, the use of Data Input and Data Output is an attempt to break my large definition into usable chunks, and reuse them in other projects as needed. A sort of “seed” file definition.

One other suggestion is to have the Data Output create automatically the file in the same folder where the gh definition is located and allow the Data Input to have string path input.

2 Likes

The Data input/output components are awesome, though I would agree with @robi the option to have a file path input would be super useful as I have to check the tiny writing on the output component to see what file it’s looking at. For now just having it the same as filters that break if you enter multiple file paths may be the data components can do the same.

It would also be great to have the option set file paths locally so if the file is opened on another machine it still works like textures and xrefs etc.

Also, @DavidRutten is it possible to use the Record data component to store the data in the file even after it been closed as currently when you close and open a file it clears all the recorders except the one in use. Even changing the record limit does not affect the loss of data.

It sounds like you might be better off simply writing/reading the data to/from a file. You can serialise arbitrary data to a file through one of the scripting components (I like to use the standard Python pickle module for this in GHPython), or using a plugin such as TreeSloth which had the Pack Data and Unpack Data component developed for this purpose.

Yes, that’s what the new Data input/output components David has written. The issue comes when you open the file the records except the the option selected are empty so it saves empty data over the old data saved in the output. I don’t think a data dam would work either as this clears after the file is closed also. I will have a look at the Python and the Tree Sloth options too.

Ah I didn’t realise those actually write to file, thought the data was just in memory (like the GHPython sticky solution above and the Data Recorder). That’s good to know.

Is it possible to set the destination through python component ?
i’m trying to do it, but i don’t know how to reference right click input in python to set the destination source?

import ghpythonlib.components as gh
gh.DataOutput(x)

it give me a warning:
“Data Output: solver component. warning: No destination file has been specified.”

1 Like

I’ve been using Data Output and Data Input for a week and believe it’s a huge step in the right direction for breaking up complex models into manageable pieces. It’s almost but not quite what has been common in the conventional programming world for ~50 years or so.

I’ll have more to say on this subject but for now will mention two quirks of the implementation and a very annoying yet obvious bug. I split a complex GH model into three pieces (files) that pass geometry from one to the next.

Quirk #1: If I change a parameter in Step 1 and then switch directly to Step 3, the results are a mix of Step 1 and Step 2 params, which is obviously wrong. So making a change in Step 1 requires a visit to the GH file for Step 2, which reads the data from Step 1 and outputs for Step 3, before moving to Step 3. This is a minor inconvenience given the benefits but ultimately would be nice to avoid.

Quirk #2: Much more serious and perhaps a fatal flaw for some models, it’s impossible in Step 3 to see (visualize and render) changes that are only possible in Step 1 or Step 2. In many cases, this doesn’t matter but for some things, it becomes literally impossible to produce a rendered animation of all the parts moving together because controls (parameter inputs) are in separate files. That’s a big problem.

=== BUG ===: This one suggests a flawed implementation to me, a mismatch of name/value pairs. I had eight “channels” on the Data Output component for Step 1 and decided to add three more. Instead of adding them all at the end, I used ‘+’ to insert each new one next to one of the eight existing inputs (outputs?). BEFORE (left) and AFTER (right) look like this:

data_output_before !data_output_after

In Step 2, Data Input shows three new “channels” as expected in the same sequence and relative positions as defined in Step 1. BUT HERE’S THE RUB: the wires in Step 2 remained attached at their old positions and didn’t shift for the new inputs, so all except the first one were connected to the wrong data and the model was corrupted. What a pain!!!

Name/value pairs are the backbone of web programming. They work very well when implemented correctly.

P.S. Step 2 uses a different file to pass different geometry to Step 3. It doesn’t modify or rewrite the data from Step 1. So both Step 2 and Step 3 (which reads Step 1 data) were messed up when the new “channels” were added in Step 1.

2 Likes

Yes, this is a “less than optimal” design. The input-output matching seems to be done by indices and not by name(s) which corrupts any subsequent GH definitions if modified upstreams. This has to be fixed.

// Rolf

Wow that makes the component unusable - hope it gets fixed soon!

No, it works and is very liberating in some respects. The bug is an unpleasant surprise but there are ways to work around it. When adding or changing the list of outputs, this procedure is recommended:

  1. Modify the Data Output ‘Destination’ file name - I use version numbers.
  2. Only then add or modify the list of data “channels”.
  3. In files that read this data, add a new Data Input component with ‘Source’ set to the new file name.
  4. Manually reconnect the wires from the old Data Input to the new one.

Not ideal but fortunately for me, the need to do this has been infrequent.

Hi everyone,

I am experiencing some minor bugs with the data input component.
I think there is a typo where it says uri instead of url.
image
The deserialisation doesn’t seem to be the issue, but serialising seems to be having issue with with the server link.


Once I change the file location on the component, the component works, but Rhino still pops up the invalid source file comment when I attempt to save as a .gh file.

Have you tried using a network drive instead of directly using the \\ServerSC\
That may be causing disconnects.

Unfortunately company policy is to not map the network drive to minimise server requests or something to do with server loads, hence the full url is used.

That’s a bad policy. You may not have a solution to your issue because of it.

The component works fine, I’m just wondering why it truncates the first part of the url though on load.

my guess is, someone is saving the file on that server, and there it’s just \F\.
Is this file used by another PC at the same time?

Unfortunately I am the only one using it.
The .ghdata component is being written to by a coworker and every time they open, they have to change the link from “C:\F…” to the server location"\ServerSC\F…"
I think the load is truncating \ServerSC\ and appends C:\ as the drive path since there is no drive path.

Wait, if you’re the only one using it why do you work through the network?

Why not use the file locally and update (copy to the server) at the end of the day, or if someone needs it?

I should clarify that I am the only person using the data input of the ghdata file. The coworker is the only person using data output to the same ghdata file.