I am doing a project where i want to do an optimization (with octopus) in which I want to optimize on a form generated by a Kangarro2 solver. However when the geometry is changed before the Kangaroo2 solver, the solver has to be reset by a buttom or similar component, which cannot be done when the optimization is running. So my question is whether or not it is possible to do an optimization which are changing the geometry before the Kangaroo2 solver, and resulting in an usable solution.
This is where the ‘ZombieSolver’ component is useful.
Instead of showing the iterations live, this just solves the system internally, and outputs the result when either an energy threshold or maximum iteration count has been reached. This makes it behave like a standard grasshopper component in the graph, not needing to be reset, and only updating the output once for each time the input is updated, allowing it to be used inside other optimization loops such as those created with Octopus or Galapagos. Here is an example definition showing how to use this.
I am doing something similar to Philip but i need that my Zombie Solver process an iteration at a time. But when i try that it seems that the Zombie Solver can only process at steps of 10 iterations at a time.
It’s true that the Zombie Solver performs 10 iterations at a time. Here’s an example of calling the solver from a script, using the ‘SimpleStep’ method, which performs only 1 iteration: SimpleStep.gh (52.1 KB)
Hello! We have been trying to do an optimization with octopus and two zombie solvers! In our case the zombie solver do not run simultaneously, but the results of the 1st zombie solver are used for the second one! For that we build a small code to ensure that only when we have results from the two simulations, only then data can pass along to the optimization…then we realized that after iteration 0, while the first zombie solver is computing, the results of iteration zero are still held in the code, so data always pass along. for that we used a brief code with a data dam to ensure that only after we have retrieved the new first form, the code can’t continue. but since we introduced the data dam, octopus stopped displaying solutions in the interface…what we would basically need, would be a zombie solver , which while is computing the next iteration, outputs a null and not the previous results…do you have any suggestions on how to achieve that? Thank you🙃
I’m afraid I don’t understand. Unlike the main Kangaroo solver, the Zombie solver component should work like any other standard Grasshopper component - if the input changes, the output will not update until the component has finished solving.
Try with any other GH component that takes a few seconds to calculate (say a Voronoi3d with 1000 points), change the input and you’ll see the output stays as the previous value while the component calculates, then changes to the new value, without ever outputting null in between.
So I think the issue might be coming from the way Octopus handles solution updates. I see what sounds like a similar issue happening here even without Kangaroo: