It’s a general question, not for a specific problem.
I try to use Grasshopper optimisation tools (galapagos, opossum, nelder-mead,…) along with external software in a process like:
Slider (Genome) > Geometry creation + Export > CFD Calculations (external) writes results in a text file > Read text file (Fitness)
I tried the 3 guys mentionned above trying to trick grasshopper into waiting for the fitness:
• Galapagos doesn’t care and change genome like crazy whatever I do
• Nelder-Mead kinda works (but not really) when I provide him while waiting for result.txt
• Opossum complains about the objectiveValues form if I try to trick it.
I think there must be a “common way” to go accross this problem that tells Grasshopper to just wait and see until further notice, but google did not help but not so much in the end.
I made a simple .gh file to get the problem and try some solutions. The result file is edited by hand:
I have never used some kind of external ready of a score as part of an optimization. I have always had the entire calculation happen inside grasshopper. So everything I’m saying is my best guess having worked with all the optimizers you listed.
How exactly do you interface with the external program? Is there any way to make the fitness value an output of your cluster? From my experience that would be the best way to synchronize your script.
If your calculations always take the same amount of time, you could potentially use a data dam to synchronize your script, but I would call that more a work around than a solution.
I communicate with the external program in a very archaic way.
I have a ghPython writing “true” in a “do_i_run.txt” when it detects a change in sliders.
The external bash script constantly reads that file and start running. It also overwrites that “do_i_run.txt” file to “false”. Then OpenFOAM runs and writes my result in a text file, read by grasshopper.
I tried blocking grasshopper using an infinite loop in a GhPython component doing something like:
Once I’m out of the inifinite loop, grasshopper runs.
I re-enter the infinite loop at any change in “x” is when the stl files have been exported (this part I probably get it wrong so far, but anyway I think my whole approach is wrong)
I saw some comments on the forum saying that octopus was designed for these type of cases, but I did not yet try to understand octopus.
Sorry for the double-post, but here is a ductape solution.
It works “properly” with Galapagos, fails with NelderMead and kinda fails with Opposum.
My mistake was that I had parallel lines, when it needs to go in a single direction in grasshopper.
So the Loop is as such:
1- Change sliders, feed them to cluster
2- Cluster creates geometry and export STLs. The STLs are created, but I need need to give that information downstream the line. So I take all outputs from the STL export and generate a random number as Cluster Output. Giving a fixed value doesn’t work, it needs to be a different one each loop:
3- This cluster output (random number) triggers the python component which runs AFTER all STLs have been exported properly. Now we get into the infinite loop, we read the result file every 1.0s.
4- When we read it, we print the result and feed it to out variable to optimize
5- Galapos works
1bis - Change of sliders…
I am not sure why it fails with Opposum because I read it should work the same as Galapagos. It feels like it sometimes doesn’t read the output (and so doesn’t change the sliders) blabla… Changing manually the result file make it start again.
I have had issues with nelder Meads not working correctly in the past as well involving the fitness score not being correctly correlated with the input parameters that generated it (and that was for stuff 100% inside grasshopper). I bet that your in and out situation only compounds this problem. If you can trigger OpenFoam inside a rhino python script, that might be the best way to do it.
Another option would be to have a script that works roughly like this.
ghPython writes "1" to "do_I_run.txt"
while = 1, ghpython wait
while = 1, open foam process
when openfoam finish, publish score, writes "2" to "do_I_run.txt"
when = 2, ghpython retrieve score, published score out of ghpython, writes "0" to "do_I_run.txt"
This sets up a unique marker for start processing (1), finish processing (2), and no processing (0). This might get around your time delay issues with those other optimizers.
Hello, thanks for the answer. This is pretty much exactly exactly what I did now. I didn’t dig deeper as it’s fun project.
My understanding of things is that Opposum sits ‘‘on top’’ of grasshopper (same as Galapagos), but for some reason is stuck at some point. I don’t know if it fails because it doesn’t to get the new_fitness or if it doesn’t update the sliders (which are triggering the ghpython loop). Anyhow it sometimes work for a few iterations (around 10 on the good days) and then gets stuck. I have no clue why it doesn’t behave exactly the same as Galapagos.
All in all I still think using these optimizers with other softwares is bad practice (with this method atleast)
