Integrating Evolutionary Optimization (Wallacei) with Flexhopper Particle Simulation

Hi guys

For the moment I am running an experiment that attempts to integrate Wallcei (an evolutionary optimization plug-in) with a timed Flexhopper component. The objective of this script is to establish a simulation loop in which Wallace takes results from the particle simulations as fitness objectives, and produces new geometries for a new round of simulation/evaluation.

(my ideal process flow diagram)

(as you can see here whenever a geometry input is adjusted, a new round of particle simulation will be triggered and keep running until the counter reaches a pre-determined value)

Right now it appears that Wallace does not wait for the fitness objectives to update and simply goes ahead generating the genetic inputs.
This does not give Flexhopper any time for simulation. Could you guys take a look at the script and point out when I might’ve got things wrong?

Best Wishes

20201011_test 1.3dm (63.8 KB) 20201011_test (49.4 KB)

Hi William,

interesting topic - I will definitely follow the thread and help where I can … I think the potential for combining flexhopper and wallacei is quite big … :slightly_smiling_face:

Regarding your problem:

Did you try using a GH file where the flexhopper simulation is NOT clustered in one larger component? Because to start with, I checked if the flexhopper simulation would run the same way in clustered vs. a non-clustered setup … and it seems to make a difference.

Flexhopper without clusterting works as desired:

Flexhopper with clusterting lead to some strange behavoiur … if i use simple boolean toogles, the simulation would not start (GO) or it would only make one step…

Another aspect when opening the GH file is that I did not have all the required components:

Can you post a screenshot of your GH canvas?

Maybe there is also another way to solve this problem without using the Counter component from Kangaroo … Also maybe you can remove unncessary components like PolylineBoolean from the GH which makes it easier to do debugging …


1 Like

Hello Manuel
Thank you very much for responding. Yes you are totally right. Somehow Flexhopper performance is visibly impacted when clustered together.

Unfortunately my Wallacei issue still persists while the flexhopper module is exploded. The Flexhopper module is pulled straight out of their example file so should be the cleanest it can be…

I have also replaced Kangaroo counter with a python counter and poly boolean is no longer part of the script.

20201011_test (117.8 KB)

Hi William,

my feeling is that Wallacei is changing the input parameters and then evaluating the GH canvas for a single time (standard behaviour). After this single step evaluation, it initiates the evaluation for the next set of input parameters. Flexhopper on the other hand seems to update the GH canvas multiple times when a simulation is initiated for a certain input paramter set and the particle position are being updated.This could be the reason why Wallacei only updates the rectangular area and directly jumps to the next input parameter set.

You can see this behaviour if you initate a simulation and look at some GH components, which seem to update although they are not related to Flexhopper … for instance, the rectangular component is updating although input parameters are not being changed …

I tried implementing the counter in a different way using a C# compenent and a static variable. You can have a look at it - but unfortunately it did not solve the problem … 20201011_test (73.2 KB)


private void RunScript(object trigger, bool reset, ref object counter)
  c = 0;
counter = c;
public static int c;

Besides Wallacei I also tried using other optimization components like Galapagos. However, the problem is the same …

@William_Q: Did you have a look at some Wallcei examples that integrate Kangaroo? Maybe that gives some clues how we could do it with Flexhopper … For instance, Kangaroo offers the option to use the goat solver option, which only outputs the last iteration …

Another approach could be to use one main GH file where Wallacei is running with the optimization … and from their automatically open up secondary GH files where the Flexhopper simulation is running and evaluated … kind of a sandbox approach … maybe metahopper can be of help for this approach …



1 Like

@Benjamin1 :wave: One question regarding Flexhopper: Is Flexhopper updating or re-evaluating the GH canvas and components multiple times during a particle simulation? Is there any option to just output a specific time step after a certain time period / number of iterations? :slightly_smiling_face:

Hey guys!

Thanks @manuel.biedermann for pointing me here
So in FlexHopper you can also adjust the solver to run for a given number of steps before returning the solution. So instead of a continuous simulation (which returns lots of intermediate steps for visualisation) you can set the fIter value in the solver options to some number larger 0

(btw this solver mode also runs MUCH faster as the entire “displaying geometry in between solver iterations” - procedure is skipped)

I made this mode specifically for scenarios where you want to automate the solver and not bother with intermediate steps…
You could set it to something very high (e.g. 2000) where you’re sure that the simulation has come to a rest.

Also you could check the latest version of FlexHopper (that’s not on food4rhino yet) on github…

There are two “Telepathy” components in the Util category to make simple loops in the GH graph. Maybe that could be useful too?

Cheers :slight_smile:


@manuel.biedermann @Benjamin1 Thank you guys for the pointer.
During the weekend I have also came across the “fiter” option in the FH component. With that option enabled I was able to remove the timer component. Now the C# script simply sends a Boolean upon comparing the new data with the recorded data.

It seems to be working with Wallacei however there is always (100%) a rapid memory usage spike with each new generation followed by immediate crash :robot:. (when total population >800, which is really not that big of a sample size)

Script link here

At first I thought maybe it is a Wallacei issue, but I do not see this problem when running the example file @manuel.biedermann mentioned in your previous comment (the one with the zombie solver component) so perhaps it could a Flexhopper thing? @Benjamin1 does flexhopper save some kind of data internally when looping through simulations ? Please enlighten me. :bowing_man: :bowing_man: :bowing_man:

Meanwhile I am very excited to try out the latest version of Flexhopper (its so damn fast…). I will adjust my script accordingly and update you guys about the results.

Best Wishes

I had a look at the latest GH file. Why do use data recorder boxes? It think it should also work without them as shown in the following picture as flexhopper is outputing only the result of the the final iteration. This avoids tracking uncessary data.

I have not solved the problem yet - but here are two ideas:

  1. To test the workflow, it could help to try out also other plugins for automation besides wallacei. For instance, testing the automated testing of differrent inputs parameters can also be tested with Galapagos or Colibri. This makes sure that the problem is not just specific to the flexhopper+wallacei combination…

  2. Another idea could be to try out a different approach to initiate / reset the flexhopper simulation and find a different solution for the following part … So, instead of using ghenv.Component.ExpireSolution(True) another approach could be to generate a boolean true singal (button like behavior), for instance using a different script implementation.


Sorry for the late reply!
Yes @William_Q, that’s a FlexHopper issue! There are memory leaks that definitely need to be addressed in a future release. My (terrible) solution was often to just restart Rhino when the RAM fills up.

I’m aware of this bug and its on top of the list of things to fix…
That’s why FH needs a major update. I just don’t have enough time these days.

My apologies! I hope you can still somehow make your script work!