Hello there, I seem to have encountered a bug where a GH file works fine when called through GH Player but not when referenced by Hops on a canvas. Hops flips between “Object not referenced” and “Cyclical data” errors for seemingly random components inside the file and at seemingly random inputs. Even when no errors are thrown, the output does not match the correct result shown when run through GH Player. I haven’t hit the recursion limit of 10 yet. I’m not sure how to proceed!
I have attached the file and its dependencies. The problematic file in question is draw_web.gh. You will probably have to update the absolute paths used by Hops for it to work. I’ve also attached a .3dm file containing the input geometry.
In Hops the grasshopper definition runs without any connection to the rhino document. So document properties like tolerance, earth anchor point etc. are not beiing read. When using the grasshopperplayer, it reads the document properties from the rhino file you are giving the command from. Probably this is why your code runs fine in GHplayer but does not in Hops.
Hello Erik, thanks for the suggestion. I believe you’re referring to behaviour similar to what’s described in this post. I have checked that none of my GH files contain references to geometry or other document properties, so this doesn’t seem to be the issue. The only data I have are default values for numeric parameters.
After much experimenting, it seems like the errors have gone away after I change Tree Access to True for the Context Get components in all of my GH files. I’ll leave this thread open as I’m still interested in an explanation for this behaviour, in particular why this option causes Hops to fail but not GHPlayer (even when I’m passing in the same non-datatree inputs), and why it causes cyclical data stream errors.
Hello @AndyPayne sorry to bother but have you come across this behaviour before? Could you try and see if you can replicate the error on your end? The thing is I’d rather have the automatic data structure matching that comes with using item access, but now I’m forced to use tree access.
Hi @hkit.yong Sorry for the delay. I’ve downloaded your example files (there are a lot) and you are correct… you don’t look like you are using any sort of referenced geometry from the document, so I don’t think that’s the issue. However, I think I was able to get everything building correctly. Essentially, I went through all of your .gh files and added a curve parameter before your aerofoil Get Geometry component. Usually this is a no-no, but if you internalize the curve geometry so that compute isn’t trying to find the curve in a document that it doesn’t have, then it can work just fine. So, I added a curve parameter and the connected it to the input of the aerofoil Get Geometry component (making sure to internalize the curve). I did this for all of the files and then everything seemed to work. I did notice there was a missing input to the “C-input of the Length Domain component” in the draw_web.gh file… so I also made a connection from the aerofoil component to that input. After that, everything seemed to build just fine. I have no idea what I’m looking at or if it’s outputting the correct stuff… but maybe this is what you were looking for?
Hello @AndyPayne Sorry for getting back to you so late, unfortunately your suggestion did not work and I was trying a bunch of other approaches to no avail. Did you get the same cyclical data stream/recursive data errors that I show in my attached screenshots?
I’ve done some more digging around the forums and I suspect these errors are similar to the ones in this post. The root of these errors seem to be the Context Get components. Setting them to list access and calling them using Hops gives me the “[INPUT] requires at least 1 item” error:
Turning on tree access (mentioned above and also in the linked post) eliminates these errors but I would rather not have it on. Again, the same files work fine when called using GH Player.
I am using Hops version 0.15.4. I’ve attached the simple example above. Please let me know if you get the same errors.
Edit: For comparison I’ve attached the Rhino geometry and a screenshot of what the correct results (the points at the tail of each aerofoil curve) look like.
After some more thought I think the list access bug above is not related to the cyclical data stream errors. My hunch is that it is instead related to data matching behaviour (item access) propagating incorrectly across multiple nested Hops.
There seems to be all sorts of unexpected and undocumented behaviour when it comes to these types of nesting scenarios. For example, a Hops component that calls, inside itself, another Hops component that has asynchronous solving turned on will not return correct results.
Another example is updates to a definition will not propagate across multiple levels, e.g., if I have fileA.gh that calls fileB.gh, and fileB.gh calls fileC.gh, updates to fileC.gh do not seem to propagate to fileA.gh. In this case, I suspect the cache is the issue (see my other thread), where perhaps it causes fileA.gh to not re-run fileB.gh for the results in the cache eventhough those results were calculated using the old fileC.gh.
@AndyPayne It would be useful to have some clarity on these nesting behaviours. Perhaps you could describe its inner workings, or share some of your own tests that dispute/reinforce my findings above?
I’ve attached the files that I was using on my end where I was internalizing the input geometry as a “default” curve. Does this work on your end? Does it give you the result you’re expecting? aerofoil.zip (76.6 KB)
Hi @hkit.yong I wanted to come back to your question about how nested hops definitions works. I believe they should work as you would expect, but let me try to put together an example. Let’s say I had three base definitions which: 1) add two numbers together, 2) subtract two numbers together, or 3) multiply two numbers together. These definitions would look like this.
Now, let’s say I create a new definition which uses a Hops component to multiply two numbers together and returns the result. I add a second Hops component to then take that result and subtract a number from it. That definition would look something like this.
Finally, let’s say I create a new definition and I add another new Hops component to first add two numbers together and return a result. I then add a new Hops component and set the path to use the “MultiplyThenSubtract” definition (see above). I take the result from the addition component and feed it in to the second Hops component. It should look something like this
Now, let’s check out math to make sure we’re getting the correct result. The first component simply adds two numbers (2+3) and the result we get is 5. So far so good. The next component then first multiplies two numbers (5*3) so we get 15. It then takes that result and subtracts 4 which gives us 11.
So, the hops components can be nested within one another and the results of each can be fed into the next component. I hope this example helps clarify some things, but please let me know if you have any questions.
Hello @AndyPayne this is a good explanation of the basic workflow for nesting Hops, and lines up with my understanding, thank you. My questions are more related to how nesting can lead to unintuitive behaviour, and that some aspects of nesting are not user-friendly.
To keep the discussion simple, I’ll just ask one question for now. Using your example above, what happens if you make a change to SubtractTwoNumbers.gh and save it? Does AllTogether.gh give you the correct result?
For instance, I opened SubtractTwoNumbers.gh and made the following change:
The calculation that I expect this file to do now, after the change, is abs((2 + 3) * 3 - 20), which gives me 5, not -5.
It is not until I open MultiplyThenSubtract.gh, save it, then open AllTogether.gh, before I get the correct answer.
Is this behaviour by design, or is it a bug? If it’s by design it doesn’t seem very intuitive. Either the file changes have to be propagated automatically to the top level, or a warning message should be displayed telling the user something is outdated, like in clusters.
Thanks for your follow up question. This does seem somewhat repeatable on my end although I think the issue is happening because of the cache. If you right-click on each Hops component, you can tell it not to “Cache in Memory” or “Cache on Server”. You need to do this on the Hops components in the MultiplyThenSubtract.gh as well as the components in the PuttingItAllTogether.gh. You probably also need to go into your Hops preferences (File->Preferences->Solver) and then click the button to Clear Hops Memory Cache. After I do that, I do seem to get the correct results each time I use the ABS component or remove the ABS component. Can you try this and see if this helps?
Yes, I’ve observed that disabling the cache entirely is another option as well (described in another one of my threads).
Curiously, keeping “Cache in Memory” and “Cache in Server” on for all Hops components, but clearing the cache in Hops preferences, doesn’t do anything, i.e. AllTogether.gh still gives the outdated results. I wonder where Hops retrieves these old values from if the cache has supposedly been cleared?
