No pages match that search.
Simulate · Coupled multiphysics
A flow report, a stress report and a thermal report rarely agree about the wall they share. The TensorLynx platform couples flow, structure and heat in one partitioned run: forces, displacements, temperatures and heat flux cross the interface every coupling iteration until both sides agree, and the interface balance is checked to show that they do.
Two-way and partitioned: each physics keeps its own solver and mesh Conservative and consistent mapping across non-matching meshes Heat-balance closure judged against a bar set before the run
The flow team exports a wall temperature. The structures team imports it a week later, on a different mesh. Nobody sends the deformed shape or the solid's heat path back, so each report is consistent on its own and the three together describe a part that cannot exist.
Wall temperature depends on conduction in the solid, which depends on the flow, which depends on how far the wall has moved. A one-way transfer assumes the answer it should compute. Interpolating between meshes that do not match can quietly create or lose heat and force, and a loosely staggered scheme can go unstable when the fluid is heavy compared with a thin structure: the added-mass effect described by Causin, Gerbeau and Nobile.
Partitioned coupling keeps each physics in a solver built for it and lets an established open coupling library move data between them. TensorLynx sets the case up from forms, writes every participant's files itself, checks the set-up before anything runs and judges the result against bars fixed in advance.
Each participant keeps its own solver and its own mesh: finite volumes for the flow, finite elements for the structure or the solid's conduction. Interface faces are picked in 3-D or taken from the named groups that came with the geometry from design exploration. A CPU plan shares the cores between participants.
Presets cover Dirichlet–Neumann, Neumann–Dirichlet, Robin and FSI. In mechanical FSI the flow sends wall forces and the structure returns displacement increments. In conjugate heat transfer one side sends temperature and the other heat flux, or both exchange a near-wall temperature and its conductance (Robin–Robin). Extensive quantities such as force and heat flow are mapped conservatively; intensive ones such as temperature and displacement consistently.
Before the run, an interface matcher reports the gap between the two face sets, how well their normals agree and how much area has no counterpart. A half-overlapping pair is flagged as partial, with advice to use radial-basis-function mapping; a distant pair is flagged as far. Nearest-neighbour, nearest-projection, linear-cell, radial-basis-function and axial multiscale mappings are available.
Schemes are serial or parallel, explicit or implicit. Implicit windows repeat the exchange until a convergence measure on each coupled quantity is met, accelerated by constant or Aitken under-relaxation or by quasi-Newton methods (IQN-ILS, IQN-IMVJ). A window that stops at its iteration cap is counted, because it hands a half-iterated state to the next one.
Heat balance is closed per interface, per participant and over the whole run, from the solvers' own heat flows, and judged against a declared bar: 2 % passes, 5 % is the edge. The Results tab shows convergence, balance and bars, and Export report writes the complete HTML report. Next, the coupled result goes to mesh verification, because a converged coupling is not yet a converged mesh.
The engine works on a solver-neutral case model: participants, interfaces, data, mapping, scheme, acceleration and convergence. Every control comes from a declaration with unit, bounds, default and fix, so a wrong value is refused with its correction.
An implicit window is a fixed-point problem on the interface: find the displacement d with d = S(F(d)), where F is the flow solve and S the structural solve. The residual of iteration k is rk = S(F(dk)) − dk.
dk+1 = dk + ωk rk ωk+1 = −ωk · rkT(rk+1 − rk) / ‖rk+1 − rk‖2
That is Aitken's dynamic relaxation. Quasi-Newton methods build an approximate inverse Jacobian of the interface from earlier residuals; for a dense fluid on a slender structure, an implicit scheme with quasi-Newton acceleration is the method of choice.
Method
With a mapping matrix M from solid to fluid nodes, a consistent mapping interpolates, Tf = M Ts, while a conservative one transposes it, Fs = MT Ff, so the sum of the forces is the same on both meshes. The transfer method matters more than it looks: for a temperature field passed from finite-volume cells to finite-element nodes in a one-way thermal-stress chain, the displacement error was:
| Transfer | Displacement error |
|---|---|
| cell-wise linear | 26.3 % · fail |
| L2 projection | 6.1 % |
| radial basis function | 1.2 % · caution |
| cell-wise quadratic | 0.88 % · pass |
Measured Restrained plate with an analytic temperature profile; 0.88 % equals the error of the exact nodal field, the mechanics' own floor. The transfer is now chosen per quantity, with its cost shown before the run.
| Coupling | Flow → solid | Solid → flow |
|---|---|---|
| Mechanical FSI | wall force | displacement increment |
| CHT, Dirichlet–Neumann | heat flux | wall temperature |
| CHT, Robin–Robin | near-wall temperature and conductance | near-wall temperature and conductance |
Reference comparisons use converged data only: in a serial-implicit scheme, the force the second participant exports after advancing already belongs to the next window's first, unconverged iteration.
Each case was set up from the TensorLynx forms, run and compared with the published reference results of its open tutorial.
Finite-volume flow and finite-element solid, Robin–Robin on the inner and outer wall, serial-implicit with Aitken. Against the published baseline: total-pressure loss +0.01 %, outlet mean temperature −0.03 %, heat flux into the inner flow +0.55 %, objective −0.03 %.
Measured · 7 coupling iterations
On the same run, heat leaving one side against heat arriving on the other: 0.0023 % on the inner wall and 0.00012 % on the outer wall, against a declared pass bar of 2 %. Fluid and solid participants close to 0.19 % and 0.15 %.
Measured · settled
A dynamic finite-element tube (HHT time integration, Green–Lagrange strain, quadratic tetrahedra) in internal flow; the structure alone was first checked against the Lamé solution of a pressurised thick tube, within 1 %.
Measured · 3 windows vs reference
A pipe split between two flow participants: pressure within 1.2 × 10−4 and velocity within 1.2 × 10−5 relative L2 of the published reference over 10 windows, with flow closure of 1 × 10−5.
Measured · 10 windows
Defaults were set by measurement: the structure takes the force as a ramp within each window, corner nodes of quadratic faces carry the coupling, and only converged data enter a comparison. Each is a declared setting you can change.
One review instead of three: wall temperature, deformation and stress come from the same converged exchange, with the heat balance beside them.
No hand-written coupling files and no silent interpolation: interfaces, mapping and scheme are forms with units and bounds, checked before the run.
Coupling stops being a late surprise between teams. Every coupled run leaves a report and a run record that the engineering history can trace.
Cooled walls whose metal temperature sets both the heat path and the thermal stress: conjugate heat transfer feeding a structural model on its own mesh.
Heat sinks and cold plates solved as fluid and solid regions from their own CAD, reporting thermal resistance and pressure drop; a serpentine cold plate read 0.327 K/W at 107 Pa Measured · one operating point
Heat exchangers where two streams trade heat through a wall, closed interface by interface.
Flexible walls, ducts and panels in flow, where load and deformation are iterated together in each window.
| Step | Typical workflow | With TensorLynx |
|---|---|---|
| Interface data | Exported once, one way, by file | Exchanged both ways in every coupling iteration |
| Non-matching meshes | Interpolated, rarely checked for conservation | Conservative or consistent per quantity, with gap and overlap reported |
| Set-up | Configuration and solver files edited by hand | Forms with units, bounds and one-click fixes; every file written by the platform |
| Convergence | Assumed from a fixed iteration count | Measured per quantity; capped windows counted against a bar |
| Proof | Three reports to reconcile | One report with heat-balance closure and reference agreement |
Conjugate heat transfer between fluid and solid (temperature, heat flux or Robin data), mechanical fluid-structure interaction (wall forces to the structure, displacements back to the flow) and partitioned flow, in which one flow domain is split between two participants. The coupling is two-way and partitioned: each physics runs in its own solver on its own mesh.
No. Data are mapped between non-matching meshes: conservatively for force and heat flow, consistently for temperature and displacement. Before the run the gap, normal agreement and uncovered area are reported, and a partially overlapping pair is flagged with advice to use radial-basis-function mapping.
Both are available, serial or parallel. Explicit coupling exchanges once per time window; implicit coupling repeats the exchange until every convergence measure is met, with constant, Aitken or quasi-Newton acceleration. For strongly coupled cases, such as a dense fluid on a slender structure, implicit coupling with quasi-Newton acceleration is the method of choice.
Heat balance is closed per interface and per participant from the solvers' own heat flows and judged against a bar fixed before the run. Windows that stop unconverged are counted. Reference cases are compared on converged data only, and each verdict reads pass, caution, fail or unknown; unknown is never a pass.
Yes. An existing configuration file of the coupling library is imported into the forms, and every element the model cannot represent is listed rather than dropped. From then on the platform writes every participant's files itself.
A complete HTML report exported from the Results tab, with convergence per window, heat balance, the bars and their verdicts, and a run record. OLTRION engineers can set up and run the coupled case with you or hand over a workflow your team runs. Simulation supports the engineering decision; it does not replace the tests and sign-off 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.
