I can see that in version 24.3.0 some components have been modified, such as FEM-Design Connection, OpenModel, and SaveModel. These components work perfectly on my side, so I have no issues with their functionality.
However, I have a few questions and would really appreciate it if you could shed some light on them:
I noticed that the Run (True/False) condition has been removed. Personally, I found this feature very useful—especially for the SaveModel component—since it allowed me to build and iterate on models and only save them when explicitly needed.
I understand that similar behavior can be achieved by enabling/disabling the component, but I felt the previous approach was cleaner and more intuitive.
Is there any possibility that this Run condition could be reintroduced in a future update?
Additionally, I’ve noticed that when enabling a component (for example OpenModel), the Grasshopper canvas freezes until the component has finished executing.
In previous versions, when creating a model through Grasshopper, the connection could be established first and the model would continue building in the background. With the current behavior, however, Grasshopper becomes unresponsive until the entire model has been created. Can it be that in future updates this is changed back?
Correct. To enable iteration support in our LiveLink, we removed the asynchronous functionality. This decision was a tradeoff between adding more features and maintaining performance.
Previously, users who needed to run iterations were using a different component which had to open and close the software for each iteration, which was time-consuming. With the new approach, LiveLink may temporarily freeze Grasshopper while the process runs. The main components affected by this change are Run Analysis and Run Design. However, in a typical workflow, you would still need to wait for their results before continuing your work, so the overall impact should be limited.
We may reintroduce asynchronous behavior in the future, once the API supports all required functionality and we have time to focus on more “nice-to-have” improvements
I hope this clarifies the reasoning behind the change.
I think a Run-command for the FEM-Design.RunAnalysis would be great. If my understanding of the connection between Grasshopper and FEM Design is correct, one would then keep FEM Design opened, but the analysis could easily be run in a controlled way.
For the short time I have used FEM Design API, I have experienced several times that I make changes in the Grasshopper model, which then instantaneously results in a freeze of Grasshopper and reloads FEM Design. This is because I have forgot to disable the live link elements before performing changes in my Grasshopper model.
It can however be argued that the problem here is my workflow hehe..!
(Any recommendations of having a more structured workflow instead of disabling the live link components before making changes of the Grasshopper model are appreciated!)
1 I personally found the input very useful for OpenModel, SaveModel, RunAnalysis, and RunDesign, but also when reading results.
As an example, I have a script that reads results and exports them as .csv files. I noticed that when I had several CaseCombResults components on the canvas, they would sometimes fail when trying to read the results simultaneously.
To work around this, I implemented a sequential approach: I read one specific result type at a time, move the generated .csv file to a dedicated folder, and only once that step is completed do I proceed to the next result type—something along the lines of what is shown below:
2 In my workflow so far, I found it very useful to still have access to the script while an analysis was running or while results were being read (since the result-reading components are also affected). This allowed me to create multiple models and run several analyses in parallel. That said, I understand the reasoning behind the current behavior, and for the time being the only option is to adapt. I am looking forward to the reintroduction of asynchronous behavior in the future.
I agree! I have opened a ticket. We will release a beta version soon
with the new approach, the error should never happen as the results get access one at the time
Removing the Async really has a lot of benefit in the Grasshopper environment. Grasshopper does not support multi thread and Async was a great hack created by Speckle team
