What is multiphysics simulation?

Multiphysics simulation is solving two or more kinds of physics together because each affects the other. Flow heats a solid and the solid’s temperature changes the flow. A coil induces current and the resulting heat changes the conductivity that determined it. Pressure deflects a structure and the deflected shape changes the pressure.

Almost every real engineering problem is multiphysics if you look closely enough. The skill is not in coupling everything — it is in identifying the one coupling that changes your answer, and ignoring the rest with your eyes open.

One-way coupling runs physics A, takes its result, and applies it as a load or boundary condition to physics B. Nothing flows back.

• CFD surface pressures applied as structural loads on a bracket or a wing.
• CFD wall heat flux driving a thermal model of the surrounding assembly.
• A computed temperature field producing thermal stress and distortion.
• Electromagnetic losses acting as the heat source in a thermal analysis.

The condition for this being legitimate is simple: the second physics must not change the first in any way that matters. If the bracket deflects by a fraction of a millimetre in a flow field metres across, the flow does not care, and a one-way chain gives you the right answer for a fraction of the cost of a coupled run.

This is worth stating plainly, because two-way coupling is often reached for reflexively: most industrial multiphysics is one-way and correct.

Two-way coupling exchanges data in both directions and iterates until both physics agree. You need it when the feedback is strong enough to change the result:

• Fluid–structure interaction where deflection is large enough to alter the flow — a flexible wing, a valve reed, a sail, a slender riser in a current.
• Flutter and instability, where the coupling itself is the phenomenon and a one-way run cannot show it at all.
• Natural convection, where buoyancy from the temperature field is the only thing driving the flow.
• Induction heating, where temperature changes conductivity and permeability, which changes the heating.

Two-way runs are qualitatively harder. They are usually transient, they add an outer iteration loop around two solvers that each have their own convergence behaviour, and they can be unstable in ways neither physics is alone — particularly when a light structure meets a dense fluid, the well-known added-mass problem.

The two physics rarely share a mesh. A CFD mesh is refined for boundary layers; a structural mesh is refined around stress concentrations. So every exchange requires interpolating a field from one surface discretisation onto another that does not match it.

Doing that badly loses conservation — the total force applied to the structure is not quite the force the fluid exerted, and energy quietly appears or disappears at the interface. Conservative mapping schemes exist precisely to prevent this, and mapping is usually where a coupled setup goes wrong before either solver does.

Coupled simulations fail differently from single-physics ones, and the symptoms mislead. A divergence in the flow solver may be caused by a mesh being deformed past usability by the structural solution. An oscillation that grows every coupling step may be a genuine physical instability, or it may be the coupling scheme itself — and telling those apart is the actual skill.

The reliable discipline is to make each physics work alone first. Get the CFD converging on the undeformed geometry. Get the structural model right under a representative static load. Only then couple them. Debugging two solvers and an exchange scheme simultaneously, having never seen either work, is where coupled projects go to die.

Two pieces of open-source infrastructure matter here. MEDCoupling handles field mapping between non-matching meshes — all a one-way chain actually needs. preCICE is a coupling library that orchestrates true two-way exchange between independent solvers, with maintained adapters for the major codes.