Multi-Objective Optimisation

Real Engineering Rarely Has One Objective

A single-objective optimisation — minimise mass, say — is a useful abstraction, but it is rarely the actual engineering problem. Real structures are judged on several criteria at once: mass, stiffness, static strength, fatigue life, natural frequency, thermal behaviour, cost, manufacturing time, aerodynamic drag, reliability, and more. These objectives compete. Making a panel stiffer usually means making it heavier. Improving fatigue life by adding material may worsen the natural frequency or raise cost. Multi-objective optimisation is the discipline of navigating these trade-offs honestly rather than pretending they can be collapsed into a single number.

Competing Objectives in Practice

The first step in any multi-objective problem is to list the objectives and characterise how they conflict. Not every conflict is obvious. Mass and stiffness are directly opposed for a given material. Mass and natural frequency are opposed for a fixed configuration. Fatigue life and mass are opposed, but the relationship is non-linear because fatigue depends on stress range, which depends on geometry and load path, not just thickness. Cost interacts with all of them through manufacturing complexity.

• Mass vs stiffness — more material usually means stiffer, but heavier
• Mass vs natural frequency — frequency scales with stiffness/mass, so they pull together or apart depending on where material is added
• Strength vs fatigue life — a design sized for ultimate load may still have poor fatigue behaviour if load paths are tortuous
• Cost vs performance — tighter tolerances and exotic materials raise cost for diminishing returns
• Reliability vs mass — higher reliability demands larger margins, which means more mass
• Manufacturing time vs complexity — efficient structural shapes are often harder to make

Hard Constraints vs Soft Objectives

A useful distinction separates hard constraints from soft objectives. A hard constraint is a requirement that must be met: the structure must not yield under limit load, must not buckle under ultimate load, must fit within the envelope, must be manufacturable by the chosen process. A soft objective is something you want more of but are willing to trade: lower mass, higher stiffness, longer fatigue life. Formulating the problem correctly means deciding which quantities are non-negotiable and which are preferences. An objective that is actually a requirement should be a constraint, not a term in a weighted sum — otherwise the optimiser will happily trade away compliance with a regulation for a gram of mass.

The boundary between a hard constraint and a soft objective is an engineering and regulatory judgement, not a mathematical one. A fatigue life of 100,000 cycles might be a hard constraint if it is a certification requirement, or a soft objective if it is a customer preference. Document the rationale for each classification — it is one of the most consequential decisions in the optimisation setup.

The Weighted-Objective Approach

The simplest way to handle multiple objectives is to combine them into a single scalar objective using weights. Each objective is normalised to a comparable scale, multiplied by a weight, and summed. The optimiser then solves a conventional single-objective problem. The advantage is simplicity and compatibility with any single-objective optimiser. The disadvantage is that the result depends entirely on the weights, and the weights encode a subjective judgement about what matters.

F  =  w₁·f₁  +  w₂·f₂  +  w₃·f₃  +  …  +  wₙ·fₙ

  where  fᵢ  =  normalised value of objective i
         wᵢ  =  weight assigned to objective i,  with  Σwᵢ = 1

  The weights are chosen by the engineer; they are not derived from physics.

Normalisation of Objectives

Objectives live on wildly different scales. Mass might be in kilograms, stiffness in newtons per millimetre, fatigue life in cycles, cost in pounds. Summing raw values is meaningless — the objective with the largest numerical scale would dominate regardless of the weights. Normalisation brings each objective onto a comparable footing. Common approaches include dividing by a target value, dividing by the range observed across a sample of designs, or scaling between the best and worst values found so far. The choice of normalisation affects the result as much as the weights do, and it should be documented.

• Target normalisation: fᵢ = raw_value / target_value — requires a meaningful target for each objective
• Range normalisation: fᵢ = (raw − worst) / (best − worst) — maps each objective to [0, 1]
• Min-max scaling can be unstable if the sample of designs is small or unrepresentative
• Document the normalisation scheme alongside the weights — both are engineering judgements

Pareto Optimisation

Rather than combining objectives into one scalar, a Pareto approach works with the objectives directly and seeks the set of designs where no single objective can be improved without worsening another. This set is called the Pareto front. A design on the front is non-dominated: no other design is better in every objective simultaneously. A design off the front is dominated: some other design is at least as good in all objectives and strictly better in at least one. The Pareto front does not give you a single answer; it gives you the menu of efficient trade-offs from which you must choose.

pareto-front

Dominated and Non-Dominated Solutions

Consider a problem with two objectives — minimise mass and maximise stiffness — plotted against each other. Each candidate design is a point on this plane. A design A dominates design B if A is both lighter and stiffer (or equal in one and strictly better in the other). The non-dominated designs trace out a curve: the Pareto front. Designs inside the region bounded by the front are dominated and can be discarded. The front itself is the set of designs worth considering. No point on the front is "better" than another in an absolute sense — they simply represent different trade-offs between the two objectives.

• A non-dominated design cannot be improved in one objective without degrading another
• A dominated design is worse than some other design in every objective — discard it
• The Pareto front is the set of all non-dominated designs for the given objectives
• The shape of the front reveals how severely the objectives conflict — a sharp knee indicates a region of favourable trade-off

Choosing the Final Design

The Pareto front gives you the efficient candidates; it does not choose among them. Selecting the final design requires a separate decision about which trade-off is acceptable for this application. A common heuristic is to pick the design at the "knee" of the front — the point where you stop getting large gains in one objective for small sacrifices in another. But the knee is a geometric convenience, not an engineering mandate. In a safety-critical application you may deliberately choose a heavier, more conservative point on the front. In a performance-driven application you may choose an aggressive point. The choice is governed by the requirements, the certification basis, and the customer — not by the optimiser.

THE OPTIMUM DEPENDS ON WHAT YOU VALUE

An optimisation algorithm minimises a mathematical function. It does not know what is important. The weights in a weighted sum, the constraints that bound the feasible region, and the objectives included in a Pareto study are all inputs that encode engineering and commercial priorities. Change the weights and you get a different optimum. Add an objective you previously ignored and the front shifts. The algorithm is a tool for exploring the consequences of your stated preferences; it does not generate those preferences. If the "optimum" surprises you, the first thing to question is not the algorithm but the objective function and the weights you gave it.

• Weights and objective selection encode priorities — they are the most consequential inputs
• A different set of weights yields a different optimum; run sensitivity studies on the weights themselves
• Omitting an objective from the formulation does not make it irrelevant — it makes it uncontrolled
• The optimiser explores your stated preferences; it does not decide what those preferences should be

Key takeaways

• Real structures have competing objectives — mass, stiffness, strength, fatigue, cost, reliability — and these cannot honestly be collapsed into a single number.
• Distinguish hard constraints (regulatory, non-negotiable) from soft objectives (preferences you will trade); misclassifying a requirement as an objective lets the optimiser trade away compliance.
• The weighted-objective approach F = Σwᵢfᵢ is simple but its result depends entirely on the weights and the normalisation, both of which are engineering judgements.
• A Pareto front gives the set of non-dominated designs — the efficient trade-offs — but it does not select the final design; you must choose based on the requirements.
• The optimiser explores the consequences of your stated preferences; it does not generate them. If the result surprises you, question the objective function first.
• Run sensitivity studies on the weights themselves — a robust design decision should not flip when a weight changes by ten per cent.