Sometimes Wallecei does not show any progress (see violett bar) and runs forever. This problem is very hard to reproduce because it might happen, that you disconnect the fitness values from the Wallacei component, reconnect them and everything is running just fine.
I uploaded the .gh-file, however I can’t provide one missing plugin due to licensing. It is quite big with 5 Sliders and 4 Fitness values. It runs two time-consuming external console applications which return scalar fitness values. The simulations take 0.5 to 3 Minutes each, quite long, with files being written to disk, but each run is a clear squence of:
genomes manipulated → console applications fired → scalar values returned
Either the whole process runs successfully (e.g. 10/10 sutions/generations) or it never progresses. Sometimes I reconnect genomes/fitness values and it works/does not work. Can you provide me with a fix or some suggestions and workarounds? wallacei-does-not-progress.gh (688.3 KB)
I opened your file but I am missing quite a few plugins from my end. will try to give it a shot soon, however your problem sounds like an infinite loop. Is there any solution or scenario that your design problem even through the external application, gets stuck in an infinite loop or produce a null solution (null fitness values) but could not get out of it? the following video will explain the Null solution
thanks for your answer. Unfortunately one of the plugins is not distributable (licensing)…
There are null fitness values: Anytime the height is below 3 m, which is the case if genome/slider wlc1_Rows == 6. This is done on purpose, because height > 3m is a side condition. However, it should get out of it as soon as the slider is changed by Wallacei.
I already run simulations with 20/10 solutions/generations with this side condition, so this should not be the problem.
I’ve faced this issue several times, From my experience when facing this issue, the reason that Wallacei doesn’t progress is because you have a component in your definition that is creating an invalid geometry, one that rhino cannot compute, and so what’s happening is that Wallacei is creating a combination of sliders (randomly… that’s why it sometimes works and sometimes doesn’t) that’s creating a problematic geometry, and rhino is trying to compute it indefinitely (technically, its not crashed), and so stopping the progress of Wallacei. So to solve this problem, you need to find the solution (i.e. the combination of sliders) that is creating this invalid geometry, and then find the component that is causing this invalid geometry (it can be as simple as a offset curve, where the component its trying to offset is an invalid curve, thus crashing).
To do this, i suggest you follow the steps below:
To find the solution that is causing the invalid geometry:
when you run the simulation, please make sure that you have the ‘autosave’ feature turned on (its in tab1 of Wallacei).
run the simulation
what you are hoping for is for the simulation to crash… i.e. as you said for no progress to happen… wait until that happens, when it does, force quit grasshopper.
Open the same definition that you quit… when you do this, what should happen is that the definition will not open… grasshopper will be stuck in loading the definition. this is because when Wallacei crashed (with autosave on), when you reopen the definition the sliders in the definition should correspond to the last phenotype that Wallacei created, which in this case is the problematic one. if this happens that’s a good thing.
To fix the problem of the definition not opening, restart rhino/grasshopper, and lock the GH canvas first, then open the crashed file. if the canvas is locked, GH will not compute any components and so will allow you to open the file.
if you are able to replicate the above, then the definition you just opened is the one that is causing the crash (if you unlock the canvas it should crash).
To find the component that is causing the invalid geometry:
once you have the crashed definition open (and canvas locked), select all the components in your canvas and disable them all.
Unlock the canvas
start enabling each component in your canvas (from right to left) one by one. Keep doing this until you enable a component that causes rhino to crash. once you identified the component, restart rhino, repeat all the steps above and investigate why the component is causing a crash… in most cases you will need to replace the component with an alternative component (or series of components) that does the same thing.
Its a bit of a process to find the problem, but very rewarding once you do.
goodluck!
thank you for your comprehensive answer! However, I think this is not the cause for Wallecei not to run. The random nature of the initialization of genomes might explain the randomness of the occurence of the issue. But I think that it does not explain the following:
Either it get’s stuck in the very first run or it runs the whole optimization successfully - in this case 20/10 Solutions/Generation.
If the genomes potentially generate invalid geometry, then this should also happen during the optimization run e.g. in Solution 3/7. But this does not happen. Unfortunately it seems that if lots of simulations with high computational loads are involved, things are getting mad, and the cause of it - be it the involved plugins, the OS, Grasshopper, Rhino or whatsover - is hard to find.
Anyways, thanks a lot for your support!
BTW; Offtopic, but one minor issue I run into with Wallacei is, that with having 5 sliders, prefixed with “wlc_1”, “wlc_2” etc. it does not always select all sliders, when clicking this in the context menu.
