The Computational Workflow, End to End

A computational project runs through a recognisable sequence, and every module in this course lives somewhere on it. First the brief: goals, site, budget, the constraints that actually matter. Then concept - the driving design idea and, crucially, the parameters that will carry it. Then the parametric model in Grasshopper, where that idea becomes a live definition. Then analysis (sun, daylight, structure, cost) that measures how the current version performs. Then optimization, searching the design space for versions that perform better. Then rationalization, bending the geometry into something buildable - flat panels, repeated members, standard sizes. Finally fabrication or BIM: cut files, shop drawings, or a Revit model the wider team can run with.

The arrows do not only point forward. Analysis feeds back into the model; a rationalization constraint sends you back to reconsider the concept. Real work is a loop, not a line. What makes it a workflow rather than chaos is that you always know which stage you are in and what question it is answering. Naming the stage stops the most common failure: fiddling with panel joints while the massing is still undecided.

To make this concrete, we will carry one running example through the whole lesson: a timber gridshell canopy over a small courtyard, roughly twelve metres across, that has to shade a cafe terrace, drain rainwater and be cut from flat plywood ribs. It is deliberately modest - not an icon, just a real thing with real constraints - and it touches every stage of the pipeline. Watching it move from a one-line brief to a stack of numbered, laser-cut ribs is a better teacher than any single component, because the difficulty was never any one stage; it was carrying the design across all of them without losing the thread.

The strongest computational designers resist opening Grasshopper first. A definition built without a concept becomes an aimless pile of components that generates shapes but answers no question. So the first move is on paper: state the design intent in a sentence, then ask what are the parameters and what are the relationships - exactly the parametric-thinking habit from Module 0.

Concretely, you decide the inputs (a site curve, a slider for bay count, an attractor for a view) and the outcome you will measure (shading in summer, floor area, panel count). This is where you choose the model's spine: the small number of driving parameters everything else hangs off. Pick three or four, not thirty. A facade might reduce to opening size as a function of orientation plus module width; a canopy to support spacing plus sag. Everything downstream is machinery serving those decisions.

Writing the concept first also tells you what not to build. If the brief never asks the roof to change, the roof does not need to be parametric - model it once and move on. The concept is the filter that keeps the definition proportionate to the problem.

For the canopy, the concept sentence is: a single anticlinal surface, found by hanging and inverting, dished so rain runs to one corner, gridded into ribs thin enough to bend from plywood. From that one sentence the driving parameters fall out almost automatically - the two or three support heights that set the sag, the grid density (how many ribs each way), and the drainage low-point. Notice what is not a parameter: the plywood thickness is fixed by what the supplier stocks, the courtyard outline is given by the site, and the cafe's furniture layout is somebody else's problem. Deciding this on paper, before touching Grasshopper, is what stops the definition ballooning into a machine that can move things no one ever needs moved.

The whole point of a parametric model is that it flexes, so the middle of the workflow is really about protecting flexibility. A few disciplines keep a definition alive rather than brittle. Keep your driving parameters as clearly labelled sliders and panels at the far left, so a collaborator can steer without reading the graph. Reference Rhino geometry through named layers, not by clicking objects one by one, so the link survives when the Rhino file changes.

Be careful with Internalise Data and baking. Internalising captures geometry inside a component so the definition no longer depends on the Rhino file - handy for sharing, but it freezes that input, so use it deliberately, not by habit. Baking writes geometry out to Rhino as dead objects; do it for delivery, not mid-design, because a baked shape no longer updates when a slider moves. The failure mode to avoid is a model that looks parametric but is really a stack of frozen results wired to nothing.

Flexibility has a cost, though. Every extra parameter is another thing to solve, test and explain, and a giant definition recomputes slowly and breaks in surprising ways. The craft is building enough flexibility for the decisions that are genuinely still open - and no more.

Once the model flexes, you can measure it. This is where Module 8 and Module 9 plug in. Environmental analysis with Ladybug and Honeybee turns the current geometry into numbers - radiation on the facade, useful daylight hours, an energy estimate. Structural plug-ins such as Karamba3D give you deflection and utilisation. Those numbers become the fitness that an optimizer reads.

With a measurable model and a driving parameter, Galapagos searches for a single best value and Wallacei balances several competing goals along a Pareto front. But optimization is a tool for exploring, not a vending machine for answers. The genome and fitness you wire up encode your judgement; a badly framed objective optimises the wrong thing beautifully. Treat the results as a shortlist of informed options and choose with your eyes and the brief in hand.

Crucially, this stage loops. An analysis result of 'the west facade cooks in summer' does not end at a number - it sends you back to change the shading parameter, re-solve, re-measure. Keeping the model flexible in the previous stage is exactly what makes this loop cheap. If every change means a manual redraw, you will run the loop once and stop; if it means moving a slider, you will run it fifty times and actually learn something.

Back at the canopy: we find the shell form with Kangaroo, hanging a mesh from the three supports and inverting it so it stands in pure compression, then read the ribs off the relaxed surface. Ladybug measures how much summer sun the terrace still catches; a Karamba check flags where the ribs deflect too far. Now a single objective appears - minimise timber length while keeping deflection under the limit and shade above the target - which is a job for Galapagos, or for Wallacei if we want to see the trade-off between material and shading rather than collapse it to one answer. The optimizer proposes; we, holding the brief, dispose. That division of labour - machine searches, human judges - is the whole point of the stage.

A gorgeous doubly-curved surface is not a building; it is an intention. Rationalization is the stage that makes it real - approximating that surface with planar or single-curved panels, snapping members to a few repeated lengths, unrolling developable strips, checking that fabrication tolerances and node connections are sane. Module 6's panelization and Module 9's file-to-factory work live here. This is where computation earns its keep in practice, because it can hold thousands of pieces to a rule that a human could never track by hand.

Then the hand-off: cut files (DXF for laser or CNC, meshes for 3D printing), shop drawings, schedules, or a BIM model via Rhino.Inside.Revit so the documentation team can build on it. The next lesson is entirely about doing this cleanly.

Finally, the professional judgement that separates finished work from endless tinkering: knowing when to stop parameterising. A model should be exactly as flexible as the live decisions demand - once the massing is fixed, freeze it; once the panel logic is signed off, bake it and document it. Chasing 'fully parametric everything' is a trap that burns weeks and produces a fragile definition no one else can touch. The mature move is to stop, commit, and deliver.

The canopy finishes the journey here. Its found surface is doubly curved, so we unroll each rib into a flat strip with developable-strip logic, snap the strips to the plywood sheet width, add finger-joints where ribs cross, and number every piece so the builder can assemble it in order. The output is a set of nested DXF cut files plus a simple assembly key - and, if the cafe is documented in Revit, the canopy handed across as native geometry via Rhino.Inside.Revit. Then we stop. The supports are fixed, the grid is signed off, the ribs are cut - so we bake them, archive the flexible definition as a labelled version, and issue. Chasing one more parametric refinement at this point would add fragility and risk, not value. Brief to buildable, one continuous thread: that is the workflow.