Clusters do not Recalculate in Rhino7

So the misery may continue for years because McNeel QA can’t be bothered to take seriously the eight months of reports (so far) and investigate the issue.

I believe these reports and saw the issue myself yesterday but can’t reproduce it at will. I have half a dozen separate GH models all sharing Data Input and Data Out components, far too complex to share, and when this bug strikes the GH is just broken for no good reason. Please stop the pain!

P.S. Apparently this bug was introduced in an effort to increase performance by minimizing recalculation of clusters. I assure you that the damage done by this bug is far worse than the issue it’s trying to solve. So can the so-called “improvement” be disabled or optional?

Are these valid examples of problems with the clusters?

GH File:
clusterhack.gh (8.8 KB)

Thanks, I’ll see if I can repeat this on my computer

Any updates on this?

cluster_not_working.gh (12.3 KB)

Here is another example file.

It appears the cluster updates when I really change grasshopper sliders/panels/numbers, but when I update a file (that is read to get some input) and press F5, a cluster is not updated.

This is really weird behaviour; pressing F5, which says ‘recalculate’ should just recalculate the whole document. Please fix this - or make the performance gain optional…

Please fix this cluster problem as soon as possible. It’s impossible to work with them at the moment.

Impossible is a strong word. Something is amiss but so far the conditions where it fails are elusive. I’m guessing it fails to detect external changes in certain cases. For me, it might be Data Input. Do you have something “unusual” feeding the cluster?

It is a strong word and I thought this problem deserves all the importance there is.

My cluster in question is having the following code in it:

The D input in the Contour component is coming from User Text Attributes from Rhino. Sometimes this cluster works, sometimes it does not update. However, due to it being unreliable I got rid of it.

That might be the key. It looks to me like another case where a changed input value from an unconventional source (not a slider, for example) is failing to trigger cluster recalc.

Yes, it does.

Can you share your definition and 3dm that does not update?

Here is a stripped-down version of it.

ClusterProblem.3dm (181.4 KB)
ClusterProblem.gh (18.2 KB)

In the original file, which I cannot share, there are multiple different input Breps and each have their own user-text attribute values.

In short, user-text attributes are modified by the user → Geometry Pipeline fetches that data to Grasshopper → Object Attributes (Human) gathers those attributes and I plug them into this cluster with Contour component. For some reason, this cluster occassionally fails to update itself. If that happens, I can go inside the cluster and see that it’s working, and after I return to the GH canvas the cluster has updated itself.

Another thing that might have something to do with the problem is that we use a custom-made Rhino-plugin to write those user-text attributes. It is a panel with drop-down menus etc. It is clear to us that it does not update Grasshopper canvas in the same way as the native user-text attributes panel does after pressing Enter (it requires some modification to trigger the recalculation of GH). But that is another story - just wanted to share that if it might cause the veins of the user-text attributes to get clogged somehow.

1 Like

It will likely fix itself if you simply reconnect any of the cluster’s input wires?

I have found the “trigger” component, in manual mode, to be a workaround for now.

I have a panel that contains a file path to some CSV file. I would like to be able to update this CSV via a text editor, then press F5 to recalculate. But in this case, clusters won’t update. But if I connect a trigger component to this panel with the file path, and press the play button, the CSV file is re-read and all downstream components, including clusters, will update.

Whatever the trigger does, it is precisely what F5 should do :slight_smile:

This might be another work-around to get clusters to recalculate? Silly idea but…

  1. Add a Data Recorder to the canvas and connect its input to anything that changes when the cluster recalc is supposed to happen.

  2. Add an input to the cluster to accept the Data Recorder output. It can probably be ignored inside the cluster but maybe its output will be enough to cause cluster recalc?

I suppose so, it’s just that I cannot reproduce the problem at the moment to actually test this.

The same happens to me as pointed out here earlier: pressing F5 does not recalculate the clusters from some reason when this problem occurs.

I’ve never used (or even heard of) F5 to recalc clusters. Reconnecting any upstream wire has always worked, though as you say, failure is inconsistent and for me, rare.

Recompute (F5) is not just for clusters, it’s for the whole canvas. I use it whenever something does not seem to be up-to-date and/or I want to make sure. It’s like a big reset-button for the whole canvas.

1 Like

I thought this issue that I face may be relevant to this thread. Not sure if it is the intention, but when the cluster input changes from one type to another, the input does not change outside of the cluster. F5 did not work for me in this case and I just had to add a new cluster input. If it is as intended, I guess I just have to reconnect all my existing inputs to the new one. Pardon the quick flowchart, did not have my video capture working on the laptop.


cluster_issue.gh (12.2 KB)

1 Like

I also had trouble with updating content within clusters.
Using a Python component from the following post seems to sort that out.
Check 201218_RecomputeSolution_slider.gh in https://discourse.mcneel.com/t/rhino-precompute-grasshopper-python-script/114713/5

It is not fully automatic but only a click away.
Please let me know if it helps.

Is this solved? we are experience this issue again.
It happens so randomly. Sometimes the scripts inside the cluster update, sometimes it is not.

In reference to your datatype / input issue. I believe the original datatype the input was connected to is applied the the input connector when the cluster is created. The datatype reference appears to not be referenced from inside the cluster anymore and is now the input connector’s datatype is static. Connector types should by dynamic based off what they are connected to inside the cluster… They are not.