No pages match that search.
Product / TensorLynx / MDAO
Optimise · Constraint-aware MDAODisciplines tuned one at a time, limits checked afterwards, and a “best” design that turns out to rest on an unconverged solve: that is how optimisation loses a design review. In the TensorLynx platform an MDAO study is declared data, and every candidate is judged on solver values, so the design it recommends is one your team can defend.
Roles assigned, never guessed from namesFeasibility judged on solver values, with declared tolerancesRecommended is not decided: an engineer decides
Optimisation programmes seldom fail inside the optimiser; they fail in the gaps around it. Two teams converge on their own designs, and integration discovers that the two never met. A stress limit lives in someone’s head instead of in the study. A run that diverged half-way still reports a value, and it happens to be the smallest.
Multidisciplinary design optimisation exists because a system’s performance comes from its disciplines and from their interactions, a point the MDO literature puts at its foundation (Martins & Lambe, AIAA Journal, 2013). In industry the hard part is the bookkeeping: which constraint was active, which evaluation converged, which number came from a solver and which from a model.
The diagram follows the MDO community’s XDSM convention: components on the diagonal, data on the grey lines between them. Scroll to follow one evaluation.
TensorLynx reads a set-up model through its own declarations: variables, units, shapes, bounds and registered roles. Nothing is inferred from a name. Whatever the model does not state is recorded as MISSING, never as zero or a default, and the model’s fingerprint changes whenever the model, a mesh or a case file does.
A person, a template or the model itself gives each variable its role: design variable, fixed condition, objective, constraint or monitor. Every constraint carries a relation, a bound and a tolerance. An undefined problem is refused before launch, each refusal with a one-click fix: a zero-width bound, an equality without a tolerance, a decimal comma typed into a number field.
The plan preview shows one evaluation count, and says whether it is exact, an upper bound, approximate or unknown. Duration estimates come from measured runs that match the plan exactly; without one the estimate stays missing, never extrapolated. Runs above your confirmation limit ask first.
Disciplines come from a registry that labels each one’s maturity. A coupled group declares which output feeds which input, in which unit, and every evaluation states whether its analysis converged. A failed evaluation is recorded FAILED with outputs MISSING; the run carries on, nothing imputed.
One rule judges every constraint, wherever a result is shown: the value must sit inside its bound widened by the declared tolerance. Each constraint reads active, inactive or violated, with its margin. Surrogate-assisted search improves on the best feasible value so far and weighs each new point by its probability of being feasible.
The recommended design is the best evaluated design that converged and meets every constraint on solver values. It stays Exploratory until an independent re-run confirms it. The platform ranks; it never records a decision for you. A named engineer does, with a rationale, in an append-only record.
What is judged, by which rule, and what happens when something goes wrong.
minimise f(x, y) over x
subject to gj(x, y) ≤ gjmax + tj, j = 1…m
hk(x, y) ∈ [hk* − tk, hk* + tk], tk > 0
xL ≤ x ≤ xU
where R(x, y) = 0 coupling solved to its declared tolerance
Each tolerance t belongs to its constraint and has a recorded source. An equality needs t > 0; a bound must be one finite number; a vector output is judged per component and the binding component is named. A template tolerance on a scaled constraint is flagged, with a one-click rescale.
Coupled studies use the multidisciplinary-feasible form: the optimiser is handed an analysis after its coupling has been solved, so every design it judges is consistent in its coupling variables.
MethodThe state rule is the platform’s: violated if the margin is below −t, active if its magnitude is within t, otherwise inactive. A constraint with no declared tolerance reads “not judged”, with a fix that opens Responses. Method
Sequential quadratic programming and interior-point optimisers for smooth problems. A derivative that passes its check reads direction-checked, never “verified”.
COBYLA and a genetic algorithm with declared settings; the genetic algorithm is refused when its evaluation arithmetic exceeds your cap.
Full factorial, Latin hypercube and Sobol sequences with a recorded seed, optionally followed by a response surface.
Kriging with one model per constraint component and constrained expected improvement, EI × P(feasible). The surrogate mean never drives infill. No feasible point after the initial sample stops the run as “box infeasible”, naming the constraint.
How surrogates earn trust, and when they are silenced, is the subject of trust-aware surrogates. Method
Every figure here comes from a recorded run on the TensorLynx platform, on a case whose reference answer is known. That is deliberate: a workflow earns trust where you can check it.
A published open-source tutorial case, rebuilt and run by the platform: minimise drag of a NACA0012 section with lift held at CL = 0.5 and thickness, volume and leading-edge radius constrained. Drag fell from CD 0.0209439197 to 0.0175321783, 16.29 % lower, in 10 iterations and 25 evaluations, matching the tutorial’s own −16.3 % on its 4,032-cell mesh. An independent Verify re-run returned CD 0.0175321906, a relative difference of 7.0 × 10−7.
Measured · reproduction of the tutorial resultA steel cantilever plate, 0.5 m long, three thickness zones of 2–10 mm: minimum mass under a 160 MPa von Mises allowable per zone and a 10 mm tip-deflection limit. Against beam theory the baseline came within −1.06 % in deflection and +0.02 % / +0.08 % in stress, mass error 3.8 × 10−16, all inside bars fixed before the run. A surrogate-based study from the interface made 22 evaluations, 7 of them feasible; its recommended candidate was verified by re-solve with zero difference.
Measured · finite-element sizing caseThree seeds, two search engines, six recommended plates, all feasible on solver values. The three from the second engine sit within 2.26 µm of the 10 mm tip-deflection limit (closest 0.0208 µm) and were confirmed by independent re-solve: the deflection constraint is active, as sizing mechanics predicts.
Measured · same plate caseThe classic two-discipline Sellar problem and a model with deliberately unfamiliar variable names run the full path from discovery to candidates in automated tests, with injected failures: unconverged answers, a killed worker, a changed model.
Synthetic · test fixturesSweep the constraint level and the points become a trade-off front. How a front is built, ranked and turned into a recorded choice is the next chapter: pareto selection.
MDAO sits between learning and decision. Cheap predictions from multi-fidelity and surrogates can propose designs; this stage turns them into solver-evaluated, constraint-judged candidates; high-fidelity reassessment confirms the one you choose.
A recommendation you can take into a design review: every number a solver value, every limit with its margin, the selection rule written on the candidate.
No silent defaults. Refusals name the field and offer the fix; an interrupted run resumes without re-running what is recorded.
The evaluation count before launch, a confirmation limit on large runs, and a decision record of who chose which design, and why.
Drag minimised at fixed lift, with thickness, volume and leading-edge limits judged on every evaluation and the price of each lift level explicit.
Brackets, plates and carriers sized for minimum mass under per-zone stress and deflection limits, with the active limit named on the result.
Ducts, manifolds and passages where pressure loss trades against stress or manufacturing limits, set up with your own allowables.
| Topic | Typical workflow | With TensorLynx |
|---|---|---|
| Constraints | Checked after the run, often by hand, against a spreadsheet. | Declared with relation, bound and tolerance; judged on solver values by one rule. |
| Missing data | Blank cells become zeros or defaults. | MISSING stays missing; launch is refused with a fix. |
| Failed runs | May sit in the table as numbers and win the ranking. | Recorded as failed or not converged; never ranked. |
| Cost | Discovered when the queue fills. | Evaluation count and measured duration shown before launch. |
| Final design | The lowest objective in the table. | Best evaluated feasible, converged design; verified on request; decided by a named engineer. |
Every study, run and decision is versioned with its inputs; see provenance, or step back to the TensorLynx overview.
Every constraint is part of the study itself: a relation, a bound and a tolerance you declare. One rule judges it on solver values wherever a result is shown, every candidate carries its margin and its state (active, inactive or violated), and a constraint without a declared tolerance is refused before launch instead of being judged by a guess.
Yes, when the disciplines form a registered coupled group. The group declares which outputs feed which inputs and in which units, the coupled analysis is solved in multidisciplinary-feasible form, and each evaluation states whether it converged. OLTRION engineers register and check the coupling for your case before it is allowed to steer an optimisation.
Gradient-based sequential quadratic programming and interior-point optimisers, derivative-free COBYLA and a genetic algorithm, design of experiments (full factorial, Latin hypercube, Sobol sequences) and surrogate-based search with constrained expected improvement. Every setting that changes a result starts empty and must be declared.
It is recorded as what it is. A failed evaluation is stored as FAILED with its outputs MISSING, an unconverged one keeps its verdict, and neither is ever ranked or recommended. The run continues; if a worker is lost, the results so far are kept and Resume starts a linked run that re-runs no recorded evaluation.
No. It recommends the best evaluated design that converged and meets every constraint on solver values, and labels it Exploratory until an independent re-run confirms it. The decision is recorded by a named engineer, with a rationale, in an append-only record; a later decision supersedes an earlier one and never rewrites it.
The study engine is declaration-driven: a model connects through a discipline adapter that states its inputs, outputs, units and settings, and the same workflow runs it. OLTRION engineers build and check that adapter with your team, from your existing cases.
No. MDAO narrows a design space to candidates your team can defend and shows what each constraint costs. Tests, approvals and sign-off remain what your product requires.
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.
