A Weird issue on the Grasshopper when it crashes!

[arc.mj92]

Hi
I have a Grasshopper file in which the Voronoi pattern has changed after a crash. I do not understand what happens during computing that it is representing the wrong pattern in the Rhino environment. It should be mentioned that I have not changed the effective parameters (slider numbers) for generating the Voronoi pattern. After crashing, I tried rerunning the Rhino-Grasshopper, restarting the computer, and deleting the /temp folder; however, the result was the same.
Also, I usually save the updated code as a new file. The point is that all previously saved works have changed and represented the wrong Voronoi pattern. It should be mentioned that the parameters (slider numbers) that affect the Voronoi pattern have been constant. Moreover, this issue had happened before and when the Grasshopper crashed again, the file returned to the correct version, WIERD! But, now this has not returned to the correct version!

What’s wrong with Grasshopper? How to solve the issue?
@DavidRutten

00.gh (99.3 KB)

[inno]

this is the “lost pattern” that you want to achieve

I have done the average of the cells vertexes to get a flavor of their center points: it’s not a very accurate thing, but it clearly gives you just the “flavor” of how points were distributed in space for the pattern that was lost:

as you can notice, there is an area of “lower distribution” that is the whole left part, circled in red, where the voronoi cells become larger because the distance between points is bigger:

now, going to the definition, it pulls your random points to some curves, and sorts the points by distance to the closest curve, where the closest points come first:

then the points are jittered “just a little bit”, and finally you pick the 140 farthest points, these ones in green:

as you can see from the final result (left) compared to the lost pattern you want to reproduce (right) the low-density area is on the very opposite direction

this can’t come out just from seed sliders, but it’s a change in the way the decisions are taken

for instance, if I invert the order by which points are sorted (so the farthest ones from the curves come first) you get something that is majestically more similar to your final pattern:

for this reason I believe it’s not a matter of the seed sliders (or at least not just those) but also something else that was changed in your definition

---

by the way, to make your definition work I have replaced inside the Cluster Sasquatch’s plugin (which I don’t have) “Sort Polar” component with sort along curve:

[arc.mj92]

Dear @inno
thanks for your detailed response. Reproducing the lost pattern by writing a new code block is not now my priority as this code block you worked on, is just a small part of a long definition. I call it MainCode. In MainCode, some branches have been manipulated so if I reproduce the pattern by writing a new code block, I must go through those branches to manipulate them manually which is exhausting.

This issue has happened once again before, when the Grasshopper crashed in calculating a component and I had to end the process of the Rhino-Grasshopper. Indeed, after restarting, I found out the Voronoi pattern completely changed. When the Grasshopper crashed for the second time, the issue had been resolved so there was no problem anymore.

Now it happened for the third time (a crash in Grasshopper). More interesting is that all previously saved files have changed, too. If I had one of those previously saved files on another computer, it would work correctly as long as it would not transfer to this computer. It sounds like the calculation in just this system has encountered a weird issue that I do not know literally, what this is and from where it comes.

[inno]

I agree on the fact that because more than one (or a couple of) component is involved, then it becomes more difficult (in particular time consuming) to backtrack which initial setup produced the final result you want

the main thing I’m thinking about is that Voronoi function produces a given solution for a given set of points, regardless of their order: same points produce the same result, there is no Seed for Voronoi

if the issue stems from the generation of a different Voronoi diagram (which goes through a set of components that alter it, but they also always produce a particular result for a particular initial setup) then the problem you are looking for is finding the correct same initial-points spatial configuration

and, just to give you a hint, that does not belong necessarily just to the sliders you have circled in red:

because you are dealing with a Surface that gets populated with points, the smallest change to the Surface will completely change the position of the points that it gets populated by

also, a very tiny change to even this slider here that defines the Domain of the pulling curve, now set to 0.050

will produce a huge difference on the final shape:

what I can suggest is to always keep active the auto-save feature for every action, and whenever it happens to you that GH crashes (we all make it crash it from time to time ) is to open Rhino, open GH, right click on GH and disable the solver, open the last file, at this point GH will ask you JUST ONCE if you want to load the temp file that crashed, and I always say YES and instantly save as a new version like adding a letter at the end of the file

only then you decide if it’s worth to re-enable the solver or not, but at least you are able to keep the very last data just before making it crash… and sometimes it can save you hours of work (expecially for who is not very used to save the work every 10 minutes, like me, but I’m slowly getting used to feel like if an operation is dangerous enough so it’s better to give it an intermediate save… )

good luck!

[arc.mj92]

Thanks you dear @inno