Galapagos Was Never Magic: Build the Evolutionary Solver Yourself
David Rutten's Galapagos was never magic. Rebuild the same evolutionary solver in open-source DEAP — a hands-on Python tutorial for AEC optimisation.
Before it was a slider in your Grasshopper canvas, it was a paper. In the early 1960s Lawrence J. Fogel published On the Organization of Intellect and lit the fuse on evolutionary computing. Ingo Rechenberg and John Henry Holland carried it through the early 1970s. Richard Dawkins put it on ordinary desks in 1986 with The Blind Watchmaker and its endless stream of little Biomorphs bred by hand. Fifteen years ago David Rutten took that whole lineage, compressed it into a green component called Galapagos, and demoed it at the AAG10 conference in Vienna on 21 September 2010. His write-up landed three days later. Read it and one thing is obvious: nothing about this was ever magic.
Rutten is refreshingly honest about the deal you are signing. Evolutionary solvers are, in his words, slow — dead slow. A single light/shadow or acoustic evaluation can eat a minute per iteration, and you need at least 50 generations of 50 individuals before the thing stops embarrassing itself. Do that arithmetic: 2,500 evaluations at a minute each is a two-day run for one facade study. Worse, the solver does not guarantee an answer. Left alone it runs forever, either never reaching the peak or standing on it without noticing. The upside is that it hands you a result at any moment you abort — newer answers generally beat older ones, so even a killed run leaves something on the desk.
That trade-off is the whole story on a working desk. You do not use a genetic algorithm because it is elegant. You use it because your problem is under-constrained, ugly, and shaped like nothing a closed-form solver will touch — panel angles against annual glare, member depths against deflection, a stair that must hit two landings and one budget. The bad news is the compute bill. The good news is you can build the engine yourself and see exactly where the time goes.
←TODAY: Rutten’s 2010 Galapagos essay still describes the exact solver you run in 2026 — five interlocking parts, no guarantee, harvest-anytime.
→3012: Optimisation stops being a two-day batch and becomes a background hum; the desk reviews intent, not runtime.
Fulcrum: The algorithm has not changed since Fogel — only the number of evaluations you can afford before dinner has.
The Tool: DEAP (Distributed Evolutionary Algorithms in Python) is the open-source library that makes Rutten’s five parts touchable. It is maintained by a research group out of Université Laval, it is pip-installable, and it exposes the same anatomy Galapagos hides: a genome, a fitness function, selection, crossover, and mutation. An afternoon with DEAP teaches you more about what your Grasshopper solver is actually doing than a year of dragging the slider.
Setup:
git clone https://github.com/DEAP/deap.git
cd deap
pip install deap # or: pip install .
python -c "import deap; print(deap.__version__)"
python examples/ga/onemax.py # first evolutionary run, ~1s
First steps:
- Open
examples/ga/onemax.py. It is the smallest complete solver: atoolboxregisters your genome, yourevaluate, and the three operators — this is Rutten’s anatomy in ~40 lines. - Find
creator.create("FitnessMax", base.Fitness, weights=(1.0,)). Flip the weight to(-1.0,)and you now minimise instead of maximise — the same one-line switch between chasing light and killing it. - Replace
evalOneMaxwith your own objective returning a one-tuple: total glare hours, kilograms of steel, deviation from a target curve. - Run again and watch the generation log climb. That climbing number is the population clustering around Rutten’s fitness peaks, printed instead of drawn.
Atelier: In a Zurich or Basel studio this is not a toy. The moment you can express a design question as “one number I want lower,” DEAP lets you prototype the search in Python before you ever commit a two-day Galapagos run inside the live model — you debug the objective, not the geometry engine. Your Monday move: take one recurring optimisation you currently eyeball — panel rotation, beam depth, opening ratio — write its objective as a single Python function returning one tuple, and run it against 20 random genomes to confirm the number moves in the direction you expect before you scale up.
Hack: Cap the run before it eats your week. Rutten’s second warning — the solver never knows when to stop — is a one-line fix: give it a good-enough gate and a place to stash the best genome seen so far, so an aborted run still leaves a usable result on the desk.
from deap import tools
hof = tools.HallOfFame(1) # keep the single best genome ever seen
GOOD_ENOUGH = 0.5 # your acceptable fitness, in real units
for gen in range(200):
population = evolve(population) # one select/mate/mutate/evaluate pass
hof.update(population)
if hof[0].fitness.values[0] <= GOOD_ENOUGH:
break # harvest and stop, don't chase the peak
PAZ has walked this ground before — our piece on Grasshopper’s new Ant and Raven copilots made the same point from the other end: the parametric desk is shifting from authorship to audit. An evolutionary solver you actually understand is the difference between auditing a result and trusting a slider you cannot read.
One warning from further down the road. The solver is the cheap part; the model it evaluates is the liability. An optimisation is only as durable as the file you can still open in twenty-five years — a facade tuned to the third decimal is worthless if the proprietary format that held it went dark. Keep the objective in plain Python and the geometry in something open, and your two-day run still means something long after the plugin does not.
Learn-it:
- Source repo: github.com/DEAP/deap — clone it, read
examples/ga/first. - Docs: deap.readthedocs.io — the toolbox and operator reference.
- The original lecture: David Rutten on Evolutionary Solvers — the anatomy in his own words.
- Root concept: Genetic algorithm — the Fogel/Holland lineage.
Do not run Galapagos on faith. Rebuild it in DEAP once, feel where the minute-per-iteration goes, and you will size every optimisation you commit for the rest of your practice with your eyes open.
SOURCE · ↗
PAZ Kaffi · multidisciplinary editorial, led by PAZ Academy