No pages match that search.
Product / TensorLynx / High-fidelity reassessment
Verify · Design reassessmentOptimisers are good at finding where a fast model is wrong, and the best design a surrogate predicts often sits exactly there. The TensorLynx platform puts a gate between the search and your design review: the recommendation is the best design the solver itself evaluated, predictions are held to solver values by rules written before any result exists, and a candidate is Verified only after an independent re-run.
Recommended = best solver-evaluated feasible designVerified only after an independent re-runUnknown is never a pass
Every surrogate-based or low-fidelity search carries the same trap. The optimiser hunts for the lowest predicted value, and that value tends to sit where the model is most optimistic: at the edge of the design box, between sparse samples, outside its data. Trust-region model management has answered this since the late 1990s: an approximate step is checked against the high-fidelity model before it is accepted [3].
In a 2026 consultation for a NAFEMS and Teratec event on AI and simulation, 47 % of respondents named trust and validation of results among their top barriers Industry survey [1]. A 2026 survey of 120 manufacturers found that 16 % trust AI-supported verification and validation Industry survey [2].
Most simulation-AI pages lead with speed and rarely show the verification step. On the TensorLynx platform it is a stage of the loop, with its own rules, labels and report section.
Reassessment is where the loop stops trusting itself. Whatever produced the candidate, the same sequence applies, and each step leaves a label on screen and in the report.
A gradient search, a surrogate-based search, a trust-region refinement or a point picked on the Pareto front ends with a candidate. Until something checks it, it is labelled what it is: Exploratory, not verified. The surrogate’s own pick gets no special status.
The recommendation pool holds solver evaluations only. Failed or unconverged runs are never ranked, and are recorded as failed with outputs missing, never as zeros. Feasibility is judged on solver values against tolerances you declared. The recommended design is the best feasible, converged evaluation; when none exists, the run says Unconfirmed instead of choosing quietly.
Where a surrogate proposed the design, its prediction meets the solver value under a fixed rule: a pass needs a gap within 2 % and inside the 95 % band (±1.96σ); up to 5 % reads Caution, with the reason; beyond that, or without convergence, it fails Method. Only a pass earns “Surrogate-proposed design, confirmed by the solver”, and the reported value is always the solver’s. A surrogate that fails its own fit check has its prediction hidden.
In a trust-region refinement, a step the solver does not bear out is not taken: the centre stays where the solver last stood and the region adapts to how well the model predicted. A step whose solve does not converge never becomes a centre. A predicted-feasible point the solver finds infeasible reads Infeasible, and its source stays “Prediction – not verified”. Nothing is averaged away.
Verify solves the chosen candidate again as a separate job, against your acceptance limits and a match tolerance you type in; there is no platform default. Only that re-run promotes a candidate to Verified, never an optimiser’s exit. In geometry-family studies the candidate is also re-solved on a finer mesh, with discretisation error from the Grid Convergence Index.
The study report carries “Verification evidence and limitations” next to the decision, and reports from the report library refuse export if a claim cannot be traced. Edit an acceptance limit later and old verdicts read Stale, keeping the limits they were judged by. The ranking is computed; a decision is recorded only when an engineer makes it, and the chain goes into the engineering record.
The vocabulary follows ASME V&V 20 and 40, NASA-STD-7009B and NAFEMS [4–6]: credibility is evidence gathered for a stated use, and verification is not validation. Every verdict needs a rule, every rule a reference, and an unmeasured verdict reads Unknown.
r = |Js − μ| / |Js|
Js: converged solver value; μ, σ: surrogate mean and standard deviation. Js is what is carried forward. Method
Decisions are recorded by a person, append-only, superseded choices kept. Method
Method
Method
From TensorLynx study records: the band a surrogate predicted, next to the value the solver returned. Two held. Two were rejected as infeasible, and their source stayed a prediction.
Pipe bend: the model promised +0.3726 Pa of pressure-loss reduction; the solver delivered +0.3275 Pa (4.0 % of baseline), inside the band, and that is the figure reported. After trust-region refinement the verified gain is +0.3722 Pa, 4.56 % of 8.1554 Pa, and the report labels its error budget unconfirmed, because mesh and turbulence-model error were outside the scope of this case. Measured · pipe bend
Airfoil drag at fixed lift: the surrogate failed its fit check, so its prediction was hidden. The recommendation went to evaluation 24 (solver CD 0.019390, CL 0.50038), not the surrogate’s pick, evaluation 26 (CD 0.020652). Measured · recorded run
Airfoil drag minimisation reproducing a published reference case, 4,032-cell study mesh: CD 0.0175321783 optimised, 0.0175321906 on re-run, relative difference 7.0e-7 against a 1e-4 tolerance: Verified. A plate-sizing re-run differed by 0 on mass, tip displacement and peak stresses. Measured
Bracket at constant volume: stress aggregate (KS of von Mises) 24.4 → 9.50 MPa (−61.1 %); the fine mesh confirmed −59.0 %; GCI 0.13 % over 1,635, 3,615 and 9,833 cells. S-duct intake: pressure drop 79.30 → 72.98 Pa (8.0 %), 8.9 % on a second mesh. Measured
Simulation supports the decision; it does not replace your tests and sign-off. Reassessment changes what reaches them: designs the solver has confirmed, with the checks on record.
One rule for what counts as recommended, in every study. A candidate that fails shows its reason before it reaches a review board.
No re-runs pasted into spreadsheets: Verify, the band check and the labels share the optimiser’s record, and failed checks stay attached.
Predicted and delivered gains side by side, so the gain in the plan is one the solver confirmed.
Drag at fixed lift: the surrogate proposes, solver evaluations recommend.
Brackets and plates re-solved on a finer mesh, discretisation error stated before release to test.
Ducts, bends and intakes: promised and confirmed pressure-loss gains on one line.
| Question | Typical workflow | With TensorLynx |
|---|---|---|
| What is recommended? | The optimiser’s final point, often a prediction | The best feasible, converged design the solver evaluated |
| Prediction vs solver | Checked when someone remembers to | A fixed rule: pass, caution or fail, with the reason |
| Tolerance | Chosen after the answer is known | Declared by you up front; later edits mark verdicts Stale |
| A check not run | Silently omitted | Unknown, which is never a pass |
| “Verified” | An adjective | A status granted only by an independent re-run |
| The report | Assembled by hand | Exported only if every claim traces to its evidence |
Reassessment is one stage of the TensorLynx loop. OLTRION engineers agree limits and tolerances with you, run it on your designs and hand over the record.
The recommendation is always a design the solver itself evaluated: the best feasible, converged evaluation of the run. Verified status comes from a separate Verify step, launched by you or OLTRION engineers with your acceptance limits and match tolerance. Until then the candidate reads Exploratory.
It is not recommended, and the reason stays on the result. A solver value more than 5 % from the prediction, or a solve that does not converge, reads Fail. In a trust-region refinement the step is not taken and the centre stays where the solver last stood. A predicted-feasible point the solver finds infeasible is labelled Infeasible, and its source stays a prediction.
No. Verified means an independent re-run reproduced the candidate within your tolerance and met your acceptance limits: verification of the numbers, not validation of the physics against experiment. Simulation supports engineering decisions; it does not replace the tests and sign-off your programme requires.
You do, before the result exists; there is no default match tolerance. The platform's own verdict thresholds are written down with a reference before any measurement and never moved afterwards. Edit an acceptance limit later and earlier verdicts keep their original limits and read Stale.
It reads Unknown: not measured. Unknown is never a pass and never a failure, and four passes plus one unmeasured axis is not a pass. A missing value is never shown as zero.
Each study run writes a self-contained HTML report and JSON, with a section on verification evidence and limitations next to the decision. Where a prediction is shown, it is labelled as one beside the solver value, and the value reported is the solver's. Reports from the report library refuse export when a claim cannot be traced to its evidence.
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.
