Computational Engineering / Structural optimisation
Posing the problem
Objective, variables and constraints — and the four kinds of structural optimisation, which are not interchangeable.
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.
- Verify the four bracing-layout force tables and actual stability in the lab; simplified rejection of mechanisms is not a design check.
- Confirm truss depth optima against independently reproduced engine calculations.
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
An optimisation needs a clear objective, permitted variables and explicit constraints before an algorithm can be chosen. Algorithm suitability also matters: discrete choices, non-smooth responses and expensive analyses call for different methods. This lesson concentrates on defining the engineering problem so that a numerical improvement has a useful meaning.
By the end of this lesson you should be able to
- Write an optimisation problem in the standard form
- Identify the objective, the variables and the constraints in an informal brief
- Distinguish the four kinds of structural optimisation by what each may change
- Recognise when a stated objective is a proxy for something else
What you should already know
- The stiffness method and member force recovery (Module 9)
- Sensitivity and design variables (Module 14)
The three parts
Objective — the single number being minimised. Mass, cost, carbon, deflection, depth, number of distinct members. One number, because an algorithm cannot rank two things at once without being told how to trade them. Module 17 is about what to do when there genuinely are several.
Variables — what the algorithm may change. Member areas, node positions, which members exist at all, material choices. Continuous or discrete: a plate thickness is continuous, a rolled section is not, and that distinction changes which methods apply.
Constraints — what must remain true. Stress below a limit, deflection below a limit, a minimum member size the fabricator will supply, a maximum depth the floor zone allows. A design that violates one is not a poor design; it is not a design.
Written formally:
minimise f(x) subject to g(x) ≤ 0, h(x) = 0, and x_L ≤ x ≤ x_U
The formality matters less than the discipline of filling in all three. Most badly-posed optimisation problems are missing a constraint that the engineer assumed was obvious.
The four kinds
They differ in what they are allowed to change, and they belong at different stages.
Topology — what connects to what. Which members exist. The most powerful and the earliest, because it decides the load path. A topology result is a starting point for a design, never a design.
Layout — the discrete version. Start from a dense set of candidate members and remove the ones doing nothing. Sometimes treated as a kind of topology optimisation, and worth separating because the method is different: it is a search over a finite set.
Shape — where the nodes are, with the topology fixed. Truss depth, arch rise, the profile of a haunch.
Form-finding — a special case of shape where the geometry is an output of equilibrium rather than something chosen. Cable nets, membranes, funicular arches. Module 15's last lesson.
Size — how big each member is, with topology and shape fixed. The latest, the most automated, and the least powerful in terms of what it can save.
The savings available fall sharply from topology to size, and the certainty rises just as sharply. That tension does not resolve: the biggest opportunities are at the stage with the least information.
Objectives that are proxies
'Minimise weight' is almost never the real objective. It is a proxy for cost, or for carbon, or for foundation size, and it is a poor proxy for all three:
- Cost. Steel is cheaper per tonne in quantity, so more of a heavier section can cost less than less of a lighter one. Fabrication is driven by the number of distinct pieces and the complexity of connections, neither of which appears in weight.
- Carbon. Depends on the factor per tonne, which varies by a factor of three within 'steel' alone depending on recycled content and production route.
- Buildability. Entirely absent from weight, and often decisive.
When you write 'minimise mass', write down what it is standing in for and whether it is a good stand-in for that. Sometimes it is — for a long-span roof where the structure dominates everything else. Often it is not.
Check yourself
A brief asks for 'the most efficient roof structure for a 40 m span'. What is missing before this can be optimised?
Practice
A truss has 23 members whose areas may each take one of 8 catalogue values. How many distinct designs are there in that space?
Worked example
What an optimisation was actually told
Given
- A truss size optimisation returns every member at 100 % utilisation
- The objective was minimum mass, subject to stress and deflection limits
Find
What the result means and what was omitted
Check yourself
Why must an optimisation problem state its constraints explicitly?
Check yourself
What does Maxwell's load-path theorem tell you before any sizing is done?
Summary
- Objective, variables, constraints — all three, or the problem is not posed
- Topology decides connectivity, shape moves nodes, size chooses members
- Savings fall from topology to size; certainty rises the same way
- 'Minimise mass' is usually a proxy — write down what for, and whether it is a good one
- A violated constraint means not a design, rather than a poor design