No pages match that search.
Product / TensorLynx / Adjoint optimisation
Improve · Adjoint optimisationPressure loss in a bend or duct depends on hundreds of wall positions, and finite differences price each one as a separate flow solve. TensorLynx solves the flow once and the discrete adjoint once, maps how the loss responds to every wall point, moves shape and mesh inside your constraints, and checks the gradient before it steers.
Gradient cost independent of the variable count Every gradient gated before it steers “Verified” only after an independent re-run
A free-form shape is not three parameters on a drawing. The documented pipe-bend set-up in TensorLynx moves a 6×6×6 lattice of control points, with two planes held vertically, which leaves 576 free displacements Method · documented set-up. Estimating that gradient one variable at a time needs 577 flow solves one-sided, or 1,152 central Method · N+1 / 2N, for one step of the design. So teams cut the shape to a handful of knobs, and the design stops where the parameterisation ran out, not where the physics did.
Each design runs one chain: deform, solve the flow, solve the adjoint, project the sensitivity onto the design variables. The gates between the links make the answer usable.
A free-form deformation lattice encloses the region you may change. Its control points are the design variables, bounded by a box you set. Planes can be frozen, and packaging rules (volume, thickness, clearance, curvature, planarity) become constraints with exact derivatives. For CAD-parametric families the variables are the CAD dimensions, set up in design exploration.
The incompressible RANS solve gives the field and the objective, here the surface pressure drop. Convergence is read, not assumed: the loop refuses to stand on an unconverged solve. The mesh it runs on should already have passed mesh verification.
The discrete adjoint solves one linear system, the transpose of the flow Jacobian, and returns how the pressure loss responds to moving each wall node. The result is a sensitivity map: where to push out, where to pull in, where the wall hardly matters. Engineers often learn more from this map than from the final shape.
The surface sensitivity is chained through the volume-mesh deformation onto the control points. That link is not optional: on an S-duct, the gradient taken without it was measured wrong and the gate caught it. Each new shape passes a realisation gate (box, volume, clearance, mesh validity) and a topology check before a solver sees it.
Before it drives a design, the gradient is checked against finite differences on two independent random directions, with a Taylor remainder sweep. A trust region sizes the step from how well predicted and measured reductions agreed. The result is a candidate until a fresh solve on its own deformed mesh verifies it.
Minimise J(u, x) subject to the discrete flow equations R(u, x) = 0. Solve once for the adjoint ψ:
(∂R/∂u)T ψ = −(∂J/∂u)T
and every component of the gradient follows from products, not solves:
dJ/dx = ∂J/∂x + ψT ∂R/∂x
x appears only on the right, so one adjoint serves 6 variables or 600. This is the control-theory route to aerodynamic design introduced by Jameson [1], and the discrete form keeps the gradient consistent with the solver’s own discretisation [2, 3].
Free-form deformation maps the lattice to the wall with trivariate Bernstein polynomials [4]: X(s, t, u) = Σ Bi(s) Bj(t) Bk(u) Pijk. The interior mesh follows by a wall-distance-stiffened elastic analogy or by inverse-distance warping, and the gradient is chained the same way:
dJ/dx = (dJ/dXvol) (dXvol/dXwall) (dXwall/dx)
The deformation Jacobians are checked against complex step; on the bend they agree to 4.5×10−16 Measured · bend lattice. Volume, thickness, clearance, curvature and planarity constraints carry exact Jacobians too.
The full procedure has its own chapter: gradient verification.
An adjoint solve costs more than a flow solve, so for a handful of variables finite differences can be cheaper. The TensorLynx gradient router keeps differences while they fit the budget and switches to the adjoint beyond it, and the plan preview shows the count before you confirm.
Two discrete-adjoint routes are integrated: one through the lattice and an elastic mesh deformation, used on the bend; one through the lattice and inverse-distance warping, admitted through the gate on an S-duct intake for laminar flow and for k–ω SST with wall functions. A new case runs the gate before its gradient is claimed.
The documented case is a 90° pipe bend in incompressible RANS, objective the surface pressure drop, run on four ranks. A learned model proposed a start design; the adjoint trust-region loop refined it with the solver; an independent solve verified it.
The iterative part of the error budget was measured for this case; mesh and turbulence-model error were outside its scope, so the platform marks the budget “unconfirmed” and says so beside the headline. A stationarity check stays on the record and states whether further steps would still move the design. Expect that candour from every number we hand over.
On a published NACA 0012 adjoint tutorial case, drag fell from 0.0209439197 to 0.0175321783 (−16.29 %) with lift held at 0.5, against the tutorial’s −16.3 %; an independent re-run agreed to 7.0×10−7 Measured · 4,032-cell workflow mesh. Its gradient check stays on the label, which reads “Direction-checked”, not “Verified”.
On an S-duct, a gradient taken without the mesh-deformation chain was measured wrong, and the two-reference gate found it. Deformation Jacobians agree with complex step to 4.5×10−16 Measured. The learned start design came from trust-aware surrogates; confirmation follows high-fidelity reassessment.
Ask the shape question at full freedom, not the five parameters the budget allowed. The sensitivity map shows where the wall matters before anyone commits to a change.
No hand-built scripts between morpher, solver and optimiser: deformation, adjoint, projection and gate run as one chain, with refusals that name the fix.
The solve count is shown before the run, every candidate states whether it is verified, and open error-budget terms are visible, so reviews argue about engineering, not provenance.
| Question | Typical workflow | With TensorLynx |
|---|---|---|
| Gradient cost | One or two solves per variable | One flow and one adjoint solve, routed to differences when they are cheaper |
| Mesh after a morph | Found broken when the run diverges | Realisation gate and topology check before any solve |
| Trust in the gradient | Assumed, or checked by hand | Two-seed Taylor and finite-difference gate, result on the label |
| “Optimised” | The optimiser’s last iterate | A candidate until an independent solve on its own mesh verifies it |
Still deciding? Read the TensorLynx overview, or send us the geometry and the objective.
The cost of the gradient does not grow with the number of variables: one flow solve and one adjoint solve give all of them, which is why the documented pipe-bend set-up can move several hundred control-point displacements. In practice the limit is memory and mesh size. TensorLynx predicts memory from the cell count before a run, and a solve the machine cannot hold is refused with a remedy instead of failing halfway.
Accuracy is a property of each case, not of the method, so TensorLynx does not assume it. Every gradient passes a gate before it steers a design: finite differences along two random directions and a Taylor remainder test, against bars fixed before the measurement. A gradient that passes the direction test is labelled Direction-checked, and a failed check stays on the label. For a new turbulent case, OLTRION engineers run that gate on your geometry first.
The volume mesh follows the wall through an elastic analogy or inverse-distance warping, and the sensitivity is carried through the same deformation, so the gradient matches the mesh that is actually solved. Every new shape passes a realisation gate covering the design box, volume, clearance and mesh validity, plus a topology check, before any solver runs.
Yes. Control points have bounds, planes can be frozen, and volume, thickness, clearance, curvature and planarity constraints are applied with exact derivatives. Variables that end at a bound are reported, so you know when the box, not the physics, stopped the search.
For CAD-parametric families the gradient is carried to the CAD parameters and the result is exported as STEP. For free-form deformation, the deformed surface, the design-variable file and the lattice are written, ready for your CAD team to rebuild or accept.
Only after an independent solve of the final shape on its own deformed mesh, checked against your acceptance limits. Until then it is a candidate. The report states what the error budget covers and what it does not cover, and the decision to adopt a design stays with your engineers. Simulation supports that decision; it does not replace the tests and sign-off your product requires.
We set up the parameterisation and constraints with your team, check the mesh and the gradient on your case, run the optimisation, verify the result by an independent solve and hand over the report with every setting, check and open term on record. Start with one geometry and one objective.
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.
