Optimization Fundamentals

Every optimization problem, in any field, is built from the same five ideas - learn them once and Galapagos, Wallacei, generative design and machine learning all read the same.

Variables are the things the computer is allowed to change: your Grasshopper sliders. In evolutionary optimization they are nicknamed genes, because the solver treats a particular set of slider values as one individual's genome. Three sliders that each take 20 positions already describe 20 x 20 x 20 = 8,000 possible designs - the search space.

Fitness (the objective function) is a single number that says how good one design is. Higher is better, by convention - shading performance, usable floor area, structural efficiency. Constraints are conditions that must hold: the tower must not exceed 40 m, panels must stay flat enough to fabricate, the plan must fit the site. Optima are the best designs - the peaks. The landscape is the imaginary terrain you get if you plot fitness against every possible combination of variables. Optimization is simply the act of climbing that terrain toward its highest point.

Notice how tightly these five ideas connect. The variables define the width of the landscape (how many axes it has); the fitness defines its height (how tall each point is); the constraints carve away the regions you are not allowed to stand on; and the optima are simply the tallest legal ground. Everything a solver does is motion across this terrain. Keep the picture in mind and the tool menus stop being mysterious - Galapagos, Wallacei and generative design differ mainly in how they move and how many goals define height, not in what they fundamentally are.

Picture the fitness landscape as a range of hills. The horizontal position is a combination of slider values; the height is the fitness of that design. A simple search strategy is to stand somewhere and always step uphill - a hill-climber. It is fast and it always improves. It is also easily fooled.

If the landscape has more than one peak, a pure hill-climber walks to the top of whichever hill it started on and stops, because every direction from there goes down. That summit is a local optimum: better than everything nearby, but not the best overall. The tallest peak in the whole range is the global optimum - the answer you actually wanted.

This is why the good solvers do more than climb. Evolutionary algorithms keep a whole population scattered across the landscape and recombine them, so some individuals explore distant hills. Simulated annealing deliberately accepts some downhill steps early on to escape a local peak, then 'cools' toward hill-climbing. Neither guarantees the global optimum - for a rugged, high-dimensional landscape nothing cheap can - but both are far harder to trap than naive climbing. When you read that a solver 'got stuck', a local optimum is almost always what happened.

Two properties of the landscape decide how hard your problem is. Its ruggedness - how many peaks and how jagged - governs how easily a search is trapped: a smooth single hill is trivial, a spiky range is treacherous. Its dimensionality - how many variables - governs its sheer size: each extra slider adds a whole new axis, and the number of combinations grows explosively, the so-called curse of dimensionality. You reduce difficulty on both fronts by choosing fewer, more meaningful genes with sensible ranges. A search over three well-chosen parameters routinely beats a search over ten vague ones, because you have handed the solver a smaller, smoother country to explore.

The hardest part of optimization is not the solver. It is writing down, as a number, what you actually want. A computer cannot optimize 'a beautiful facade' or 'a nice atmosphere'. It can optimize 'total annual direct sunlight hours on the glazing', 'square metres of usable floor above 2.4 m headroom', or 'kilograms of steel'. The craft is translating a design intention into a quantity your definition can compute.

Two failure modes bite everyone. The first is a proxy that drifts from intent: you optimize for maximum floor area, and the solver hands you a bloated slab that technically maximizes the number while ignoring everything you cared about but did not measure. The second is rewarding the wrong thing: minimize facade cost and the solver may delete all the shading you needed, because you never priced the cooling penalty. The solver is ruthlessly literal - it optimizes exactly what you wrote, not what you meant.

So before you optimize, spend real time on the fitness. Compute it in Grasshopper first and sanity-check it by hand on a few variants. If a design you know is good does not score well, your fitness is wrong, and no amount of solver runtime will fix a bad objective.

Constraints are where a tidy textbook problem meets a real brief, and how you handle them decides whether a solver returns something buildable. There are two honest ways to enforce them, and knowing which to use is a real skill.

A hard constraint is a line the design must never cross: the tower cannot exceed the 40 m height limit, panels cannot exceed the sheet size, the plan must fit the plot. Some solvers let you declare these directly; more often, in Grasshopper practice, you enforce them by construction - clamp the slider ranges, or build the definition so it geometrically cannot produce an illegal design in the first place. If the search can never generate a forbidden variant, it can never waste runs on one.

A soft constraint is a preference you would rather not violate but could, at a cost. These you fold into the fitness as a penalty: when a design breaks the rule, subtract a large amount from its score so the solver learns to avoid that region without being forbidden from passing through it. The art is scaling the penalty - too gentle and the solver happily breaks the rule to win elsewhere; too brutal and it distorts the whole landscape into a cliff the search cannot navigate.

The deeper point is that constraints and objectives are not separate worlds - a soft constraint is part of your fitness, and a badly-scaled penalty is just another way to write a dishonest objective. Decide, for every requirement, whether it is truly inviolable (build it in) or a priced trade-off (penalise it), and write that decision down. A solver handed sloppy constraints will exploit every one of them, cheerfully and literally.

Optimization is a power tool, and like any power tool it is the wrong choice for many jobs. Reach for it deliberately.

Do not optimize when you cannot measure the goal. If the thing you care about is genuinely qualitative and you have no honest proxy, forcing a number invents false precision and the solver optimizes the artefact, not the aim. Do not optimize a design you have not yet understood - if you cannot predict roughly how a slider changes the outcome, you are not ready to hand it to a machine; explore by hand first. Do not optimize when a quick parameter sweep answers the question - if there are only two sliders, rendering a grid of variants (Lesson 8.4) is faster, clearer and teaches you more than a black-box search.

And never let a fitness number overrule engineering. A solver that 'minimizes material' has no idea about buckling, connections, fire or deflection; a daylight optimizer knows nothing about glare comfort unless you modelled it. Optimization narrows options and reveals trade-offs brilliantly - but the decision, and the responsibility, stay with you and the qualified engineers you work with. Use it to think faster, not to stop thinking.