Optimization and Simulation Loops

Every optimization, from a two-line hill climber to an industrial solver, is the same loop: generate a candidate design, evaluate it with a score, and improve by keeping what scores well and trying variations of it - then repeat until it is good enough. It is the generate-and-test idea from the packing lesson, now aimed deliberately at getting better rather than merely valid.

The loop only works if two things are in place. First, a design you can describe with numbers - parameters like a window ratio, a wall thickness, a column spacing. Second, a way to turn any set of those numbers into a single score. With those, the skeleton is tiny:

def optimize(evaluate, propose, start, steps=100):
    best = start
    best_score = evaluate(best)
    for _ in range(steps):
        candidate = propose(best)          # a nearby variation
        score = evaluate(candidate)
        if score < best_score:             # lower = better here
            best, best_score = candidate, score
    return best, best_score

That is the entire shape of optimization. Everything sophisticated - genetic algorithms, simulated annealing, gradient methods - is a cleverer propose (how you make the next candidate) or a smarter rule for what to keep. The designer's real work is the other two pieces: choosing the parameters and, above all, writing the evaluate function that captures what 'good' means.

It is worth seeing how directly this connects to everything earlier in the module. The generative techniques - random variation, L-systems, attractors, packing - are all ways to generate candidates; a fitness function is a way to evaluate them; and the loop is what ties generation and evaluation into a search. In other words, optimization does not replace the earlier lessons, it puts them to work with a purpose. Where the packing algorithm proposed positions and tested them only for 'does it fit', optimization proposes whole designs and tests them for 'is it better' - the same generate-and-test reflex, now pointed at quality rather than mere validity. Once you hold that framing, the whole module reads as one idea building toward this loop.

The heart of optimization - and the part that is genuinely hard - is the fitness function (or objective function): the code that scores a design. Optimization can only chase what you can measure, so the entire exercise lives or dies on how honestly your score captures the real goal.

def fitness(width, height):
    area = width * height
    daylight_penalty = abs(area - 2.4)     # want ~2.4 sqm of glazing
    heat_penalty = 0.3 * area              # more glass, more heat gain
    return daylight_penalty + heat_penalty # lower is better

This toy window-sizing score balances two competing aims - enough daylight, but not so much glazing that heat gain runs away - and combines them into one number to minimise. That combining is the crux: real design goals conflict (cost versus quality, daylight versus heat, area versus circulation), and a single fitness function forces you to weigh them explicitly. Change the weight on heat_penalty and you get a different 'optimal' window - which is exactly right, because you have changed what you value.

Be deeply honest here: the optimizer is only as wise as the fitness function. It will exploit every loophole you leave - shrinking a window to nothing if you forgot to reward daylight - producing technically optimal, practically absurd results. Writing a fitness function that truly reflects a good building is a design skill, not a coding one, and it is where your judgement matters most.

When goals genuinely pull in different directions, collapsing them into one weighted number is not always the right move, because the weights hide the trade-off. The alternative is multi-objective optimization, which keeps the objectives separate and searches for the set of designs where you cannot improve one goal without harming another - the Pareto front. Instead of a single 'best' answer it hands you a spread of balanced options - this one cheaper, that one brighter, another cooler - and you choose where on the trade-off to sit. Grasshopper's Wallacei solver is built around exactly this, and it is often the more honest tool for real design, because it surfaces the compromise rather than burying it inside a weight you picked arbitrarily.

The simplest optimizer is hill climbing: start somewhere, take a small random step, and keep it only if it improves the score - repeat. It literally walks uphill (or downhill, for a score you minimise) until it can improve no further.

import random

def cost(x):
    return (x - 3.6) ** 2 + 1.0          # lowest at x = 3.6

def hill_climb(start, step=0.4, iters=60):
    random.seed(0)
    x = start
    for _ in range(iters):
        candidate = x + random.uniform(-step, step)
        if cost(candidate) < cost(x):
            x = candidate
    return round(x, 3), round(cost(x), 3)

print(hill_climb(0.0))                   # closes in near x = 3.6

Hill climbing is easy and often good enough, but it has a famous flaw: it can get stuck on a local optimum - a peak that is higher than everything nearby but lower than the best peak elsewhere. Because it only ever steps to something immediately better, it cannot cross a valley to reach a taller hill it cannot see. On a simple landscape with one peak it finds the answer; on a rugged one it finds a good answer, not necessarily the best. The cures all add a way to escape local optima - random restarts, occasionally accepting a worse step (simulated annealing), or maintaining a whole population of candidates, which is where genetic algorithms come in.

A genetic algorithm escapes the local-optimum trap by borrowing from evolution. Instead of one candidate, it keeps a whole population of designs. Each generation it scores them all, selects the fitter ones, crosses pairs to blend their parameters into offspring, and mutates a few values at random - then repeats. Because many candidates explore in parallel and crossover can jump across the landscape, a genetic algorithm is far better at escaping local optima than a lone hill climber. Here is the selection heart of one:

import random

random.seed(1)
def fitness(x):
    return -((x - 3.6) ** 2)             # higher is better

population = [random.uniform(0, 8) for _ in range(8)]
population.sort(key=fitness, reverse=True)
parents = population[:2]                 # select the fittest two
child = sum(parents) / 2                 # crossover: blend
child += random.uniform(-0.3, 0.3)       # mutation: nudge
print(round(child, 2))

A few dials govern how a genetic algorithm behaves, and they are worth naming because you will meet them in Galapagos too. Population size trades breadth for speed - a larger population explores more of the landscape but costs more evaluations per generation. The mutation rate balances exploration against stability - too low and the population stagnates, too high and it never settles. And elitism - always carrying the very best few designs unchanged into the next generation - stops evolution from accidentally throwing away its best result. You do not have to tune these expertly to get value; the defaults in real tools are sensible, and understanding what they mean is enough to read what the solver is doing.

In Grasshopper this is exactly what Galapagos (and solvers like Wallacei) do: you nominate sliders as genes and a single output as the fitness, press start, and it evolves the sliders toward the best score while you watch the population converge on the fitness graph. It is genuinely powerful for problems too large to search by hand - facade tuning, structural sizing, packing layouts. Be honest about the cost: evolutionary search is slow, needs many evaluations, and can still miss the true optimum. Treat its result as a strong, well-argued option to interrogate - not an oracle.

Optimization is only as meaningful as what the fitness function measures - and for real buildings that often means a simulation: code that predicts how a design performs before it exists. Daylight and glare, energy use, structural stress, solar gain, pedestrian flow, acoustics - each can be simulated, and the number that comes out becomes the fitness the optimizer chases. That closes the loop between form and performance: generate a form, simulate how it performs, improve toward better performance.

In practice you rarely write these simulators yourself - they are hard, specialised and validated over years. You call existing engines: Ladybug and Honeybee in Grasshopper (wrapping the Radiance and EnergyPlus engines) for daylight and energy, structural analysis tools for stress, computational-fluid-dynamics packages for airflow. Your Python or Grasshopper code sets up the design, hands it to the simulator, reads back the result, and feeds that into the optimization loop. Be realistic on two counts: simulations are approximations - only ever as trustworthy as their inputs and assumptions - and a full simulate-in-the-loop optimization can take hours or days, because each candidate must be fully simulated. Used well, though, this is the summit of the whole course: code that does not just draw or automate, but actively searches for better-performing designs - with you setting the goals and judging the results. From here, Module 10 turns to doing all of this well - debugging, version control and AI assistants.