algorithmic modeling for Rhino
could I get some more insight from the developer team into how Wallacei executes the components on the canvas and what are the reasons behind it?
Compared to other EA opt. solvers out there (Galapagos, Octopus, Opossum), which update the values of any associated sliders/genes and then let Grasshopper handle the recalculation of only the components connected downstream (or at least mimic this behaviour), the Wallacei seems to somehow trigger the recalculation of any component on the canvas on each iteration.
This causes the known issue, which is mentioned in the Wallacei Primer, that even components which are not part of the optimization loop, and are not required to be updated, have to be disabled/internalised, otherwise they will just add to the calculation time without any effect. This behaviour seems unintuitive and kind of the against logic of standard GH workflow.
But also recently I run into an issue with a third-party compoment, 'Compose Drawing' from package 'Aviary' https://github.com/interopxyz/Aviary/blob/master/Hoopoe_GH/Build/Co...
When Wallacei tries to iterate, the component breaks with error message:
"The calling thread must be STA, because many UI components require this".
This happens only when using Wallacei, so it makes me wonder if there are any hacks to the way the threads are handled in the background?
According to the several in-house benchmarks, we found it beneficial to recompute the canvas for now, since we think it is the best practice not to leave unnecessary components on the canvas. However, I should mention, we are looking into updating the engine to only compute components relevant to the optimization problem in the near future.
And regarding the Aviary, I am not quite familiar with this package. I will look into the problem as soon as I get more time. If you have any file, feel free to share it here with us. It will help us in the troubleshooting process.