No pages match that search.
Product / TensorLynx / Pareto selection
Decide · Pareto-based candidate selection
A multi-objective study never ends with one answer. It ends with a cloud of candidates, a front of honest compromises and a meeting where someone has to choose. The TensorLynx platform sorts solver-evaluated candidates into feasible fronts, makes every trade-off readable, and turns the choice into a recorded engineering decision that goes straight on to independent verification.
Feasibility judged before dominanceNo default weightsDecisions recorded, never rewritten
Schematic synthetic candidates, not study data
The cost of the old way
Optimisers are good at producing fronts. What happens next is rarely engineered: a scatter plot pasted into slides, a weighting agreed in the room after everyone has seen the answer, a spreadsheet that ranks whatever was on the shortlist that day.
Trust is already the bottleneck: in a June 2026 NAFEMS × Teratec consultation on AI and simulation, 47 % of respondents named trust and validation of results among their main barriers.
How TensorLynx does it
Six steps, each with a written rule. Scroll through them and watch one synthetic cold-plate study, thermal resistance against pressure drop under a mass limit, go from raw evaluations to a recorded decision.
Every candidate enters with its status. Only solver-evaluated designs are sorted; a failed evaluation stays FAILED with its outputs MISSING, never zero, and a surrogate prediction is flagged and kept out of dominance. On solver studies the candidates come from an ε-constraint campaign set up as an MDAO study: one constrained optimisation per declared level.
Each constraint becomes a violation, compared with its declared tolerance. Exceed it and the design is excluded with the reason printed beside it. No declared tolerance reads “feasibility not judged”, never a silent pass. Only then is dominance computed, so an attractive infeasible design cannot push an honest one off the front.
Non-dominated sorting splits the feasible set into ranks. Rank 1 is the front; every other design sits one rank above the highest-ranked design that dominates it. Exact twins share a rank and read “duplicate of #23”, not “dominated”, so a repeated evaluation never distorts the counts.
For two objectives the knee is the front point furthest from the line between the extremes, on normalised axes and on the ideal side: where each further gain starts to cost far more of the other objective. Hypervolume is measured against a reference point 10 % beyond the worst feasible value, recorded beside the number. Method
Shortlist candidates and rank them by weighted sum or TOPSIS. Weights start empty: you declare them, or choose “Use equal weights” on purpose. The stability check perturbs the weights at least 1,000 times and reports how often the leader stays first. Here it holds in 76 % of samples Synthetic, below the 95 % bar Method, so the record says “not stable” and shows where the winner changes.
A decision is a human act; nothing is recorded automatically. You write the rationale and who decided; a later decision supersedes the earlier one and never rewrites it. The chosen design stays exploratory until an independent re-run confirms it, which is the next chapter: high-fidelity reassessment.
Synthetic
Inside the engine
Front rules and ranking rules are pure functions with one definition each. All objectives are minimised internally; a maximised quantity such as lift enters negated, and the interface says so.
An ε-constraint campaign solves N constrained problems: minimise f1 subject to f2 ≤ εk, k = 1…N, with every design constraint still in force. Each level reports one state: active, inactive, ε-violated, infeasible or not converged.
The front verdict fails if any point claimed on the front is infeasible, ε-violated or a prediction, or if levels were computed with different model versions. Fewer than three distinct points is a caution, not a pass.
Why not a weighted sum? It reaches the convex-hull (supported) points only; points in a concave stretch of the front never win for any weights. On the solver, scalarising objectives this way is refused.
x dominates y ⇔ fi(x) ≤ fi(y) for every i, and fj(x) < fj(y) for at least one j.
rank(k) = 1 + max { rank(j) : j dominates k }, rank = 1 if nothing dominates k.
Excluded rows (infeasible, missing objective, invalid, predicted, no tolerance) never take part in dominance, and a value that is not a finite number is never coerced into one.
f̃i = (fi − fi,min) / (fi,max − fi,min) over the front; knee = arg max d, the signed distance from the chord between the two extremes, ideal side only.
A knee is computed only for exactly two objectives, on the rank-1 front, with at least three distinct points. A linear or concave front gives no knee, and the interface says why.
ri = fi,worst + 0.1 (fi,worst − fi,best) over all solver-evaluated feasible points. Method
Fronts that are compared share one reference point, stored with the hypervolume. A zero range in any objective gives no number: “front degenerate in …”.
Weighted sum: S = Σ wj rj, rj min–max normalised so that 1 is best; S in [0, 1].
TOPSIS: vector normalisation, closeness C = D− / (D+ + D−) to the ideal and anti-ideal. Criteria on a ratio scale: kelvin, never °C.
Stability: w′ = normalise(w ⊙ (1 + δu)), u ~ U[−1, 1]; share s of samples in which the leader stays first; N ≥ 1,000, seed required; stable iff s ≥ 0.95. Method
Scores within 10−12 at the top read “tied” and no stability is computed. Crossover weights are found by bisection, one criterion at a time. The ranking recomputes live when weights, shortlist or runs change; stability then reads “Stale · Re-check”. On this page’s synthetic front, equal weights put #40 first by weighted sum and #21 first by TOPSIS Synthetic. The method is part of the decision, so it is recorded with it.
Evidence you can check
These are properties you can inspect in every study, followed by a synthetic front to try the decision on yourself.
Decision record · schematic
Twelve front designs of the synthetic cold plate. Slide along the front, or set the weight on thermal resistance and see which design a weighted sum picks. Hover a line in the parallel-coordinates panel to find its design.
Synthetic demonstration data generated for this page, not a study result
What it changes for your programme
Walk into the design review with method, weights, stability and rationale on one record, and a clear statement of what is still to be verified.
No spreadsheet re-ranking. Front, filters, parallel coordinates and ranking read the same records under the same rules, so the numbers in the slide are the numbers in the study.
Every decision has a date, a name and a supersession chain. A change of mind is visible, explained and traceable, not a silent overwrite.
Aerospace
Drag against lift at fixed incidence, the front built from ε levels on the lift constraint; pick where extra lift stops being cheap.
Electronics cooling and energy
Thermal resistance against pressure drop under a mass or envelope limit, as in the demonstration above.
Turbomachinery
Efficiency against operating margin across a duty range, with the margin as a constraint whose tolerance is declared, not assumed.
Process equipment
Pressure loss against mixing uniformity in a manifold or vessel internal, with fabrication limits screened before any ranking.
| Question | Typical workflow | With TensorLynx |
|---|---|---|
| Is the front honest? | Feasibility checked by eye, if at all | Feasibility judged first, with the reason per design |
| Who chose the weights? | Defaults, or tuned after the fact | Declared by the team; no defaults |
| Would a small change flip it? | Unknown | Stability share and crossover weights |
| Why this design? | Slides and memory | Append-only decision record |
| Is it confirmed? | Assumed from the optimiser | Exploratory until an independent re-run |
On client work, OLTRION engineers frame the objectives, constraints and tolerances with your team, run the campaign, facilitate the decision session and hand over the record, kept with its provenance. See the TensorLynx overview for the whole loop.
FAQ
When objectives compete, improving one beyond a point makes another worse. The Pareto front is the set of feasible designs that no other feasible design beats on every objective at once. Picking a point on it is a judgement about what the programme values, so TensorLynx records it as a decision.
With an epsilon-constraint campaign: one constrained optimisation per declared level, each reported as active, inactive, epsilon-violated, infeasible or not converged. A weighted sum is not used to build the front on the solver, because it can only reach convex-hull (supported) points.
Non-dominated sorting, the ranking idea behind NSGA-II (Deb et al., 2002), is how TensorLynx sorts candidates into fronts. Population-based methods such as NSGA-II or SPEA2 suit fronts approximated on a surrogate; any point found that way stays a flagged prediction, outside the solver-evaluated front, until the solver has evaluated it.
Weighted sum with min-max normalisation or TOPSIS with vector normalisation, one definition each. There are no default weights: you declare them, or deliberately choose Use equal weights. Every ranking warns that it depends on the pool, because adding candidates can reverse ranks.
Run the stability check: at least 1,000 seeded weight perturbations, reporting the share in which the leader stays first. It is called stable only at 95 % or more, and crossover weights show where another candidate takes over. When inputs change, stability reads Stale until re-run.
Yes, append-only. Nothing is recorded automatically: you enter the rationale and who decided. A later decision supersedes the earlier one without rewriting it, and the ranking behind each decision is kept, so a design review sees what was chosen, why, and what replaced it.
Every capability hands its result to the next on the same model, the same units and the same record: geometry feeds physics, physics feeds sensitivities and learning, optimisation proposes, verification confirms, and the history keeps every step reproducible.
TensorLynx is built and run by the engineers who use it on client work. You can start small, with one geometry and one question, and grow into a workflow your own team owns.
Send a geometry, the objective and the constraints. We tell you which TensorLynx route answers it, what it needs from you, and what you will get back.
Our engineers run the loop on your problem: physics, sensitivities, optimisation and full-model verification, handed over with every setting on record.
A TensorLynx workflow, surrogate and verification gates set up around your product family, so the next design cycle starts where the last one ended.
Your team on TensorLynx, trained on your own cases, with OLTRION engineers behind it for the questions that need a specialist.
Simulation and AI predictions support engineering decisions; they do not replace the testing, approval and sign-off a product requires. Figures marked measured come from recorded TensorLynx runs on the stated case; figures marked synthetic or schematic illustrate a method.
