Choose the algorithm after you have seen the problem
Why I built SilverHawk, a multi-solver optimization plug-in for Grasshopper?
Optimization has become a routine step of parametric design. You wire a Grasshopper definition to an analysis engine, Karamba3D for structural response or Ladybug and Honeybee for daylight and energy, and let an algorithm drive the loop in place of your hand on the sliders. The catch is the budget. Every candidate costs a simulation, so a working session affords a few hundred to a few thousand evaluations, and with so few a solver that stalls does not recover.
The choice that is made too early
Open any optimization plug-in for Grasshopper and the algorithm is already decided. Galapagos is a genetic algorithm, SilverEye a particle swarm (I have always loved it), Opossum builds a radial-basis surrogate model, Optimus uses self-adaptive differential evolution, Wallacei runs NSGA-II, Octopus builds on SPEA-2 and HypE, Tunny exposes the samplers of the Optuna library. They are good tools, and each one commits you to a family of algorithms before you have seen how your problem behaves.
Changing family means changing tool, and none of them documents a protocol for comparing families fairly on your own model.
What the benchmarks say
I tried to measure how much this matters, in two studies. The single-objective study compared eleven solvers under a cap of 1,200 evaluations on rotated synthetic functions, travelling-salesman instances, a building-performance problem and an 85-variable free-form shell. The ranking changes with the structure of the problem and with the moment at which you stop.
The multi-objective study found that the same named algorithm can give different answers in different design tools, because of implementation details.
The travelling-salesman case shows the first effect well. With 20 cities, the surrogate-based RBFOpt of Opossum is ahead for roughly the first 450 evaluations: after 300 evaluations its median gap is 48 %, against 62 % for MERLIN, one of the solvers in SilverHawk. Then the curves cross. After 600 evaluations MERLIN is at 22 % and RBFOpt at 33 %, and after 1,200 evaluations MERLIN is at 15 % against 32 %, with CMA-ES at 12 %. A final ranking hides these crossings, and they matter when the budget is set by the time you have and not by a number you chose in advance.
One component, several families
SilverHawk is my answer to this. It is a C# plug-in that runs inside the Grasshopper process: number sliders are the variables, any numeric output of the definition is an objective, and one component, SH_Solver, opens a run window where you choose the solver, set the budget and watch the run. There are eleven single-objective solvers (MERLIN, CMA-ES, RAPTOR, three variants of L-SHADE, HHO, PFO, PSO, jEDE and the selector STRIKE) and nine multi-objective ones (OSPREY, EAGLE, TALON, GDE3, NSGA-II, NSGA-III, MOPSO, MOEA/D and the selector STRIKE-MO). The list shows only the solvers that fit the number of objectives you connect, so choosing an algorithm becomes a setting of the optimization and not a decision about software.
The two selectors spend part of the budget on a trial and then commit to the solver that behaved best on your problem. That cost is real: on a slow model the trial eats evaluations you would rather have spent on the final solver, and if you already know your problem you should pick the solver yourself.
Get Luciano Ambrosini’s stories in your inbox
Join Medium for free to get updates from this writer.
For multi-objective problems, the run window keeps an external archive and shows the Pareto front with the knee point marked, together with the hypervolume. A double-click on a solution applies it to the canvas.
Reproducible with a closed-source tool
SilverHawk is a compiled assembly, so you cannot read its code. What you can read is the record. Every run writes a CSV file with a header that lists the version, the algorithm, the seed, the population, the direction of each objective, the evaluation budget and, for multi-objective runs, the hypervolume reference, followed by the best solution of every iteration with its count of evaluations; a separate report summarizes the run. Any recorded solution can be reinstated on the canvas. Because the record keeps the evaluation count, runs from other tools can be compared along the same budget, which is how the figure above was drawn.
The guide that documents all of this, 32 pages, has a DOI on Zenodo and a CC BY 4.0 license.
What it does not do yet
This first release has no surrogate-based solver. In my benchmarks that family leads when you can afford only a few hundred evaluations, and on slow models it is the one to beat, so it is on the roadmap. I am not claiming that the solvers in SilverHawk outperform it: the comparisons are in the two studies, and the ranking depends on the problem and on the budget. It also runs only on Windows, in Rhino 8 (8.28 or later) and Rhino 9; a Mac version will be announced only after it has been tested on Rhino for Mac.
Try it
SilverHawk is free for personal, academic and commercial work. A personal key is requested once and checked offline on your computer, and the plug-in sends no usage data. It is on food4Rhino and in the Rhino Package Manager (run PackageManager and search for SilverHawk). If you try it on a real model, tell me what breaks: that is the feedback that moves the next version.
Official website and free license info: silverhawk.pages.dev
- User Guide v1.0: doi.org/10.5281/zenodo.23734488
- SilverHawk — a multi-solver optimization plug-in for
Grasshopper: SilverHawk project - Technical report with the complete benchmark results (Zenodo): https://doi.org/10.5281/zenodo.23768134
- Multi-objective benchmark study: arXiv:2610.22397
- Single-objective benchmark study: arXiv:2610.26202
