Galapagos: UI priority

When using Galapagos, the UI elements seem to be in a very low priority. The effect is, that is barely possible to change galapagos viewport settings or press other buttons. Even the Stop Solver cant be properly pressed (?!). If it is clicked, the response is usually a multiple of the individual iteration computation time. With computations ranging in around 1s per iteration, stopping the solver takes minutes or even more…

The fix seems to be just to give UI elements a higher priority. In theory this should not cause any performance losses for galapagos itself and would make the solver much more usable.

@DavidRutten
@curtisw

Furthermore, the Only display better genomes in the Rhino Viewport is also currently not working.

Hey @rudolf.neumerkel,

I’m not seeing the UI hanging issues with Rhino 8.15 or 9 WIP. Do you have an example that exhibits this issue? It could be due to the complexity of the computation or a particular component, which during a GH compute doesn’t give any time to the UI because it does all of this on the UI thread. This is what I’m seeing currently:

I see this issue, thanks for reporting! RH-85893

1 Like

Dear Curtis,

thanks for the response. Yes I forgot to mention that this is only happening with harder problems. However even a 20 -50 ms iteration time is already noticeable in the abort delay.

Currently I am running an optimization that takes 1000ms per iteration. There the delay is crazy. I should note, that this is also happening on the windows side, but it seems a bit less strong.

Here is the smaller script, where the UI issue is already visible. It requires Karamba 2.2, which can be installed from the package manager. It should run without a license, as there are only 20 beam elements.

250127_collumnOpti.gh (50.0 KB)

Note that Rhino has to be launched with Rosetta for the Karamba plugin

While the bugs are being discussed: Are there in general any planned upgrades to Galapagos? Some obvious ones would be better display of the different fitness results, somehow a display of the multidimensional fitness landscape (not sure yet how exactly that can be projected) and more detailed settings for the individual genome combination settings and mutation settings. Some of these things have been mentioned by @DavidRutten a long time ago, but I guess he is very busy developing GH2.

Also, he mentioned sth super nice: That a good solution would be to use the simulated annealing solver for local optima exploration and the evolutionary solver for further refinements of those local optima. A native implementation of this combination would be amazing.

Just some ideas…

1 Like

Hey Rudi, thanks for the example. After figuring out Karamba still doesn’t run on Apple Silicon, flipping it over to Rosetta mode got it loaded :upside_down_face:. However, I’m still missing one plugin to get that sample working:

As for the other planned updates, there is nothing in the pipeline that I’m aware of but I’ll let @DavidRutten chime in on that.

1 Like

The HUD Legend component is a custom script of mine and not necessary for reproducing the bug, as it is not connected to the logic other than providing custom gradients (I can provide though if needed).

Thank you!

Thanks, Rudi.

You’re right, I can still reproduce the lag on my machine without that component, though it isn’t nearly as terrible as what you’re seeing as it takes at most a second or two for the stop button to press.

I’ve filed it as RH-85908 so we can investigate how to make that work better.

Thanks again for bringing it to our attention!

Thanks! The terrible version is with a larger script, where one iteration takes 1sec. Stopping the solver takes a much longer time then.
I can also send that one if needed.

1 Like