Multi-Objective with Wallacei

Almost every real design goal is really several goals at once, and they pull in different directions. A larger window brings daylight (good) and solar heat gain (bad). A slimmer structure saves material (good) and deflects more (bad). A tighter plan cuts cost (good) and squeezes circulation (bad). These are competing objectives, and the honest truth is there is usually no single design that is best at all of them simultaneously.

The single-objective trick from Lesson 8.2 - roll everything into a weighted sum - technically works, but it smuggles in a decision. When you write 0.7 * daylight - 0.3 * heat, you have already chosen how much heat a unit of daylight is worth, and you chose it blind, before seeing a single result. If the client later says 'actually, comfort matters more', you re-weight and re-run from scratch, and you still never see the shape of the choice.

Multi-objective optimization keeps the objectives as separate axes and asks a better question: not 'what is the single best design?' but 'what are all the designs that represent the best possible balance, and what does giving up a little of one goal buy me in another?' That map of compromises is the thing worth having.

There is a subtler cost to the weighted sum, too: it can hide designs you would have loved. Collapsing objectives into one number flattens a rich trade-off surface into a single ranking, and a compromise that a well-chosen weighting would have surfaced can vanish entirely because some other design edged it on the blended score. You never even see it. Keeping the objectives separate keeps those in-between designs visible, which is exactly where the interesting architecture often lives.

Plot every design as a dot, one objective per axis - say cost across the bottom, energy use up the side, both to be minimised, so 'better' is toward the lower-left. Most dots are dominated: for a given dot there exists another that is at least as good on every axis and strictly better on one, so no rational person would pick the first. Sweep those away and what remains is the Pareto front (from economist Vilfredo Pareto): the non-dominated designs, where you cannot improve any objective without worsening another.

The front is the payload of multi-objective optimization. Every point on it is a legitimate 'best' - they differ only in which goal they favour. One end is cheapest-but-thirstier; the other is greenest-but-dearer; the middle holds the balanced compromises, often including the interesting 'knee' where the curve bends and a small concession in one objective buys a large gain in the other.

Critically, optimization cannot tell you which point on the front to build - that is a value judgement about your project's priorities, and it belongs to you and the client, not the solver. What the front does is priceless: it removes every design that is simply worse, and shows you exactly what each goal costs in terms of the others. You are choosing between genuine, quantified trade-offs instead of guessing.

Wallacei drives an evolutionary algorithm (a variant of the well-known NSGA-II) and wraps it in unusually rich analytics. The setup mirrors Galapagos: wire your sliders in as genes, but now wire several fitness numbers as separate objectives. You then set the run: generation size (how many individuals per generation) and generation count (how many generations). Their product is the total number of designs evaluated, so it drives both quality and runtime.

Each generation, Wallacei evaluates the whole population against all objectives, ranks individuals by non-domination (front membership) and diversity, keeps the best, and breeds the next generation by crossover and mutation. Over successive generations the population migrates toward the Pareto front and spreads along it - early clouds are scattered and dominated; later ones hug the trade-off curve. You watch this happen in Wallacei's charts: the standard-deviation and fitness graphs show whether it is still improving or has settled.

Afterwards, Wallacei's analytics let you explore the results: view the front, colour designs by objective, cluster similar solutions, and - the part designers love - reconstruct and bake the actual geometry of any individual straight back into Rhino. So you do not just get numbers; you get the buildable model behind each point on the front, ready to judge. That round-trip - from abstract trade-off to concrete geometry and back - is what makes Wallacei a genuine design tool and not merely a spreadsheet of scores.

A Pareto front is an aid to judgement, not a replacement for it, and this is where discipline separates good work from theatre. First, choose a point for a stated reason: pick the knee for balance, or an end for a project that genuinely prioritises one goal, and write down why - 'we took the slightly costlier option because it cut predicted energy by 22%'. That sentence is the design decision; the solver only laid out the options.

Second, interrogate the front, don't trust it. An evolutionary run is stochastic and imperfect: a front can be under-converged (run more generations and it may push further), or thin and gappy (increase population or diversity). Run it more than once; if the fronts broadly agree, believe them more. And remember every objective is only as honest as the Grasshopper measure behind it - a beautiful front built on a flawed daylight metric is beautifully wrong.

Third, keep the unmeasured in view. The front optimizes only what you quantified; buildability, delight, context and code still live outside it. Treat the front as a shortlist of quantitatively excellent candidates, then bring back everything the numbers could not see. Multi-objective optimization is at its best not when it hands you an answer, but when it sharpens the conversation about what you are really trading away.

Wallacei's real gift over a bare solver is its analytics dashboard, but the charts only help if you read them honestly rather than as decoration. A handful repay real attention.

The fitness charts plot each objective's values across generations. If the lines are still descending steeply, the run has not converged - give it more generations. If they have been flat for a while, it has settled, and more runtime mostly wastes electricity. The standard-deviation charts tell you about diversity: falling deviation means the population is homogenising (converging, but also losing variety), and if it collapses too fast the search may have narrowed prematurely onto a thin part of the front. The parallel-coordinate plot lets you trace how individuals score across all objectives at once and spot clusters of similar solutions.

The discipline is to treat these as diagnostics, not trophies. A gorgeous, tight front can still be under-explored - the algorithm found a narrow band of good designs and never discovered a whole better region because the population was too small or too inbred. So cross-check: does a second run with a larger population push the front further or wider? Do the clusters correspond to genuinely different design strategies, or trivial variations? And always reconstruct real geometry from several points - a front is an abstraction, and the only cure for over-trusting an abstraction is to look at the actual buildings behind the dots. The analytics make you faster; they do not make you right.