Service overview
Single and multi-objective, metaheuristic, Bayesian and topology optimisation; decision models. This service is part of that division and is scoped individually around what you need to learn, decide or publish.
Real design problems rarely have a single objective. A structure should be light and cheap and stiff; a process should be productive, energy-efficient and low in emissions; a controller should be fast and robust. These goals conflict, and any improvement in one usually costs something in another. Multi-objective optimisation does not pretend otherwise. It computes the set of best trade-offs, the Pareto front, and lets decision-makers choose.
The value of the approach is that it separates two tasks that single-objective formulations mix: finding efficient designs, and deciding how to weigh the objectives. Computing the front first, and discussing preferences afterwards with the trade-offs visible, often reveals options, such as a knee in the curve where a small sacrifice buys a large gain, that a pre-set weighted sum would hide.
If you plan to publish the outcome, see manuscript & publication support, for example computational & simulation manuscripts or original research article writing.
What this service covers
Problems this service can address
- Objectives that cannot be combined into one number defensibly
- Pareto fronts that are poorly sampled
- Decision-makers who need to see trade-offs
Methods and analytical approaches
- Evolutionary multi-objective algorithms
- Scalarisation and preference-based methods
- Pareto-front quality indicators
- Decision-support visualisation
Applications
- Design trade-off studies
- Energy-system configuration
- Process operation trade-offs
Relevant engineering disciplines
Scope, inputs and deliverables
Scope of work
- Data audit and definition of the prediction or decision task
- Model development with structure-aware validation and baselines
- Evaluation, error analysis and uncertainty reporting
- Documentation sufficient for others to reproduce the work
- Feasibility check on: objectives and their relative importance (if known)
Typical inputs required from you
- Objectives and their relative importance (if known)
- Model or evaluation process
- Constraints
Deliverables
- Pareto-optimal set with analysis
- Trade-off plots
- Method and parameter documentation
Highly specialised requests are first checked for feasibility from this information. Please do not send confidential data through the public form; describe it first and agree secure transfer afterwards.
Project workflow and method
- 01Enquiry and requirement assessment
- 02Technical scoping and proposal
- 03Execution
- 04Quality review and delivery, with an agreed round of revisions
Read the full project workflow.
In depth: how the work is done
Pareto optimality and what it means
A design is Pareto-optimal if no other design improves one objective without worsening another. The set of such designs in objective space is the Pareto front. Designs off the front are dominated and can be discarded. The shape of the front, convex, concave, disconnected or with knees, tells the decision-maker how the objectives trade off. We define the objectives and their directions carefully, since mislabelled objectives or incomparable units can distort the picture.
Evolutionary multi-objective algorithms
Population-based algorithms such as NSGA-II and its successors, and decomposition-based methods, evolve a set of designs towards the front in a single run. They handle nonlinear, non-convex and discontinuous problems and need no gradients, at the cost of many evaluations. Parameters such as population size, number of generations and operators influence convergence and spread. We recommend settings in light of evaluation cost and use repeated runs to assess reliability.
Scalarisation and preference-based methods
Weighted-sum and epsilon-constraint methods convert the problem into a series of single-objective problems. Weighted sums cannot find points on non-convex parts of the front; the epsilon-constraint method can. Reference-point and goal-programming methods incorporate preferences when decision-makers know what they want. Preference information can focus computing effort on the region of interest, which saves evaluations.
Assessing front quality
Quality indicators quantify how good an approximation of the front is: convergence to the true front, spread along it and uniformity of the distribution. Hypervolume combines convergence and diversity into one measure and is widely used, though it depends on the reference point. When the true front is unknown, indicators are used to compare algorithms or runs, and statistical tests across repeated runs support claims of superiority.
Decision support and visualisation
With two or three objectives, the front can be plotted directly. With more, parallel-coordinates plots, scatter matrices and dimension-reduction methods help. We identify knee points, show the sensitivity of trade-offs and present a small set of representative designs with their performance, rather than hundreds of points. The final choice also depends on factors outside the model, such as risk and manufacturability, which are discussed explicitly.
Quality control and good practice
Quality-control approach
- Data are audited for quality, leakage and drift before modelling.
- Validation respects data structure (by specimen, machine or time) and includes simple baselines.
- Performance is reported with uncertainty and failure cases, not only headline scores.
- Model limits and the conditions under which it should not be trusted are documented.
Common pitfalls this service helps avoid
- Collapsing objectives too early. Choosing weights before seeing the trade-offs can hide attractive designs.
- Comparing algorithms on a single run. Stochastic algorithms need repeated runs and statistical comparison.
- Using a weighted sum on a non-convex front. Parts of the front cannot be reached by any choice of weights.
- Too many objectives. Fronts in many dimensions are hard to visualise and to approximate; consolidating objectives may be better.
What good reporting looks like
A multi-objective report states the objectives and constraints, the models used, the algorithms and settings, the number of evaluations, the Pareto front approximations with quality indicators over repeated runs, representative designs and knee points, sensitivity of the trade-offs to assumptions and a discussion of how a decision may be made. It states which parts of the front are well covered and where the approximation is uncertain, and it avoids selecting a single design on behalf of the decision-maker.
An illustrative scenario
Hypothetical example written for explanation. It is not a client case, a result or a testimonial.
Suppose a team designs a heat exchanger and must trade pressure drop against heat transfer and cost. An evolutionary algorithm produces a front approximation from repeated runs, and hypervolume values across runs show consistent convergence. The front has a knee where a small increase in pressure drop buys a large gain in heat transfer, and beyond it benefits flatten. The team uses the knee as the starting point for detailed design and records the assumptions behind the cost model.
Questions to settle before you begin
- Which objectives truly conflict?
- How expensive is each evaluation?
- Do I have preferences that could focus the search?
- How will I judge the quality of the front?
- Which non-modelled factors will influence the final choice?
Key terms
- Pareto front
- The set of non-dominated trade-off solutions.
- Dominance
- A solution dominates another if it is at least as good in all objectives and better in one.
- Hypervolume
- A measure of the objective-space region dominated by a solution set.
- Epsilon-constraint method
- A technique that optimises one objective while constraining the others.
- Knee point
- A region of the front where a small change in one objective gives a large change in another.
Working together on Engineering Optimisation & Decision Science projects
Optimisation engagements begin with formulation: objectives, decision variables, constraints and the model or experiment used to evaluate designs. Much of the value is created at this stage, because poorly posed problems give unusable optima. We ask for the evaluation model or data, bounds on variables, constraints and any manufacturing or operational limits. Algorithms are chosen to suit evaluation cost and problem structure, and results are checked against independent evaluations and robustness tests. Reports present trade-offs rather than a single answer where objectives conflict, and they state assumptions behind the model that an optimiser could exploit.
Frequently asked questions
Do you choose the final design for me?
We present the trade-offs and, if asked, a selection method. The final decision stays with you.
Do I need to give weights for the objectives?
No. The approach computes trade-offs first, though preferences can be used to focus the search if you have them.
How many objectives can you handle?
Two or three are most practical. More are possible with reduced visualisation and larger evaluation budgets.
Can this be applied to experiments?
With careful planning, multi-objective Bayesian approaches can guide experiments, though noise and cost complicate it.
Which solution should I choose?
That depends on priorities, risks and constraints beyond the model. The report presents options and their consequences.
How is this service scoped and priced?
After your enquiry we review what you need, ask for missing information and send a written scope and quotation. Price depends on complexity, deliverables and timeline. See the project workflow.