Computational Engineering / Computational design and creativity
Design is an under-defined problem
Why engineering practice does not look like engineering education, and what follows for how computation is used.
Lesson review: expert verification remains open
This lesson has received a full-context editorial review and a check of its technical explanations. Selected arithmetic has been checked separately. This is not independent engineering sign-off.
Checks needed for project use
- A computational engineering reviewer must check algorithms, convergence claims, statistical assumptions and numerical examples beyond the cases explicitly recorded.
These are educational models and exercises. Check their assumptions before using the results. The full technical content and every diagram have not yet been independently verified.
Concrete and steel calculations retain their stated first-generation Eurocode teaching basis. Use the standards and amendments specified for your project; do not mix generations without an appropriate design basis.
Read the lesson register and outstanding review notesWhy this matters
A 30 m span may have several viable structural forms: a truss, plate girder, portal, cable-stayed deck or stressed-skin box. Choosing between them requires information about cost, programme, buildability, appearance, carbon and risk.
A computational comparison can assess the options and criteria it has been given. The team still needs to decide whether those options and criteria cover the brief.
The two halves of design
Concept design decides the form: what carries the load, where, and by what mechanism. It is decided early, on the least information, and it sets almost everything that follows — the material quantities, the buildability, the carbon, the programme. Change it late and everything downstream changes with it.
Detailed design sizes the members within a chosen form. It is decided late, on the most information, and it is amenable to automation in a way concept design is not.
Computation has transformed the second and touched the first much less. It is worth being clear about why. Sizing a member is a well-posed problem: given forces and a resistance model, find the smallest section that passes. Choosing a form is not well-posed at all — the objectives compete, some of them are unquantified, and the candidate set is not enumerable.
The largest savings in material and carbon are available at concept stage, which is exactly the stage least amenable to optimisation. That tension does not resolve; it has to be managed.
Requirements and constraints
They are different things and confusing them narrows the design space for no reason.
A requirement is something the design must achieve. Provide 40 m of column-free span. Support 4 kN/m² of imposed load.
A constraint is something the design may not do. Structural zone no deeper than 900 mm. No permanent works outside the site boundary.
The useful discipline is asking of every constraint: is this real, and who owns it? A structural depth limit set by a floor-to-floor height is real and belongs to the architect, who may trade it. A depth limit set by 'we always do 800' belongs to nobody and can be discarded.
Divergent and convergent
Divergent generates options and defers judgement. Its failure mode is generating variations of one idea and calling it a range.
Convergent narrows against criteria. Its failure mode is starting too early, killing the option that would have won once someone had thought about it for an hour.
Computation is much better at the convergent half. It will compare fifty parameter combinations without complaint. It will not tell you that the whole family was the wrong idea — because it can only compare what it was given, and what it was given came from you.
Try it
Design-process workspace
Separate requirements from constraints, keep or reject options, and record why. The workspace will not rank the options for you.
Is it a requirement or a constraint?
Requirement: something the design must achieve. Constraint: something it may not do.
Requirements — what the design must achieve (2)
- Provide a 30 m column-free span over the hall
- Support a 4 kN/m² imposed load
Constraints — what it may not do (2)
- Structural zone no deeper than 1.4 m— who owns this?
- No permanent works outside the site boundary— who owns this?
Options
- Options still live
- 3
- Rejections with no reason recorded
- 0
What this workspace deliberately will not do
- It will not score the options. A weighted score hides the decision inside the weights, and the weights were chosen by whoever typed them.
- It will not tell you which constraints are real. Ask who owns each one; the ones that belong to nobody can usually be discarded.
- It will not tell you when to stop diverging. Convergent thinking that starts too early kills the option that would have won.
What this shows: A requirement is what the design must achieve; a constraint is what it may not do — and a rejection without a reason is a decision nobody can review.
Check yourself
At which stage is the greatest reduction in embodied carbon available, and why is that awkward?
Worked example
Counting the options nobody wrote down
Given
- A single-storey industrial building, 30 m clear span
- Three structural forms are under discussion: portal frame, truss on columns, and a tied arch
- Each has three plausible bay spacings and two roof materials
Find
How many distinct schemes are on the table, and how many will actually be compared
Worked example
A score is not a decision
Given
- Three schemes are scored out of ten on cost, programme, carbon and buildability
- Scheme A totals 28, scheme B totals 27, scheme C totals 22
Find
What the totals justify
Practice
Three structural forms, three bay spacings and two roof materials. How many distinct schemes is that?
Practice
Two schemes score 28 and 27 out of a possible 40. What is the gap as a percentage of the maximum?
Check yourself
What does it mean to say a design problem is under-defined?
Check yourself
What is the difference between a requirement and a constraint?
Check yourself
A scheme scores zero on buildability and well on everything else. How should it be treated?
Summary
- Design problems have several defensible answers and no single right one
- Requirements are what must be achieved; constraints are what may not be done, and every constraint has an owner
- Divergent generates, convergent selects, and running them together does neither well
- Computation is strong at converging and weak at diverging
- A weighted score hides the decision inside the weights