Multi-Physics & Co-Simulation

Multi-Physics Within One Solver vs Co-Simulation Between Solvers

Multi-physics analysis captures the interaction between physical domains that a single-domain model cannot represent. There are two fundamentally different ways to perform multi-physics analysis, and the distinction matters because they have different strengths, different limitations and different verification requirements. The first is monolithic multi-physics: a single solver solves the coupled equations of multiple physical domains simultaneously. The governing equations for each domain are assembled into a single system matrix, and the solver advances all domains together at each step. The second is co-simulation: multiple specialised solvers — each handling one physical domain — run independently and exchange information at defined coupling points. Each solver advances its own domain using its own timestep and its own numerical methods, and the coupling variables are transferred between solvers at agreed intervals. Monolithic multi-physics offers tight coupling and consistency guarantees but is limited to the physical domains and coupling types that the single solver supports. Co-simulation offers flexibility — the best specialised solver can be used for each domain — but places the burden of consistency on the coupling interface. The choice depends on the problem, the available software and the strength of the coupling between domains. For weakly coupled problems, co-simulation is often sufficient. For strongly coupled problems with tight feedback between domains, monolithic coupling or tightly orchestrated co-simulation may be necessary.

Examples of Multi-Physics Coupling

Multi-physics problems arise wherever the behaviour in one physical domain influences the behaviour in another. The coupling may be one-way — one domain drives the other without feedback — or two-way — each domain influences the other. The examples below illustrate the range of couplings that arise in structural and mechanical engineering. In each case, the coupling variables are the quantities that transfer information between domains: forces, displacements, temperatures, heat fluxes, pressures, velocities, control commands and sensor outputs.

• CFD + structure (fluid–structure interaction): fluid pressure and shear load the structure; structural deformation changes the fluid boundary. Coupling variables: pressure, shear force, displacement, velocity.
• Thermal + structural (thermo-mechanical): temperature field causes thermal expansion and temperature-dependent material properties; structural deformation may change thermal contact conductance. Coupling variables: temperature, heat flux, displacement.
• Electromagnetics + thermal: electromagnetic losses (eddy currents, resistive heating) generate heat; temperature changes electrical conductivity and magnetic properties. Coupling variables: power dissipation, temperature, conductivity.
• Multibody dynamics + FEA: multibody solver computes rigid-body motion and joint loads; FEA computes component stress and flexibility. Coupling variables: joint forces, displacements, velocities, accelerations.
• Controls + flexible structure: control system commands actuator positions; flexible structure deforms and feeds back sensor measurements. Coupling variables: control command, sensor output, actuator force, structural displacement.
• Electrical + thermal: electrical current causes resistive heating; temperature changes resistance and may trigger thermal protection. Coupling variables: current, voltage, power loss, temperature, resistance.

Coupling Variables, Frequency and Direction

The coupling variables are the quantities that transfer information between the coupled models. Their selection is not arbitrary: the variables must be sufficient to represent the physical interaction, and they must be transferred with the correct units, the correct sign convention and the correct spatial and temporal resolution. A coupling that transfers pressure from the CFD model to the structural model must transfer it on the correct surface, with the correct orientation, at the correct time. A coupling that transfers temperature from a thermal model to a structural model must transfer it at the correct nodes, interpolated correctly between the two meshes. The coupling frequency — how often the variables are exchanged between solvers — determines how tightly the models are coupled. A high coupling frequency approximates continuous coupling; a low coupling frequency introduces a lag between the models. The coupling direction — one-way or two-way — determines whether the coupling is a simple load transfer or a feedback loop. One-way coupling is simpler and more stable: one model drives the other without feedback. Two-way coupling is more realistic but introduces stability concerns: if the feedback between models is positive, the coupled system may be numerically unstable even if each model is stable in isolation. The engineer must understand the coupling variables, the coupling frequency and the coupling direction, and must verify that the coupled solution converges to a consistent result — not merely that each solver ran without error.

CO-SIMULATION IS ONLY AS CREDIBLE AS THE INFORMATION TRANSFERRED BETWEEN THE MODELS. The coupling interface — the variables exchanged, their units, their sign conventions, their spatial interpolation, their temporal frequency — is part of the analysis. A co-simulation in which the coupling interface is wrong produces a coupled result that neither solver would produce independently, and the error may not be visible in either solver's output alone.

Timestep Mismatch

In co-simulation, the coupled solvers typically use different timesteps. A structural explicit dynamics solver may use a timestep of microseconds to capture stress-wave propagation. A thermal solver may use a timestep of seconds because thermal diffusion is slow. A CFD solver may use a timestep between the two, dictated by the Courant number. When these solvers are coupled, the timesteps must be reconciled: the coupling variables must be exchanged at a frequency that is consistent with the physics of the interaction and with the numerical stability of each solver. If the coupling frequency is too low relative to the physics, the models may miss transient interactions — a structural vibration that influences the flow may be averaged out if the coupling frequency is below the structural natural frequency. If the coupling frequency is too high relative to the slower solver, the slower solver may be forced to take unnecessary substeps, increasing cost without improving accuracy. The timestep mismatch is not merely a technical inconvenience; it is a physical issue. The coupled solution must represent the physical interaction at the timescale at which it occurs, and the coupling strategy must be designed to capture that interaction. A common approach is to use the fastest relevant timescale as the coupling frequency and to allow each solver to subcycle internally between coupling points. The engineer must verify that the coupled result is insensitive to the coupling frequency within the range of physically relevant timescales.

A Realistic Co-Simulation Example

The diagram below illustrates a realistic co-simulation for an electrically driven actuator. The example is chosen because it involves multiple physical domains — electrical, thermal, structural and control — with two-way feedback between them. The coupling variables are shown explicitly, because the credibility of the co-simulation depends on the correct transfer of these variables at each interface. The same structure applies to other multi-physics problems: the domains are different, but the principle is the same — the coupling variables must be identified, transferred correctly and verified.

CO-SIMULATION — ELECTRIC ACTUATOR: ELECTRICAL → THERMAL → STRUCTURAL → CONTROL

  ┌──────────────┐    I, V        ┌──────────────┐    P_loss     ┌──────────────┐
  │  ELECTRICAL  │───────────────▶│  THERMAL     │──────────────▶│  STRUCTURAL  │
  │  MODEL       │                │  MODEL       │               │  MODEL       │
  │              │  R(T) ◀─────── │              │  T(x,t) ◀──── │              │
  │  Current,    │  resistance    │  Temperature │  thermal      │  Displacement│
  │  voltage,    │  depends on    │  field from  │  expansion    │  from thermal│
  │  power loss  │  temperature   │  electrical  │  loads +      │  + mechanical│
  │              │                │  losses      │  mechanical   │  loads       │
  └──────────────┘                └──────────────┘  loads        └──────┬───────┘
                                                                              │
                                        position, force                      │
                                                                              ▼
                                                                   ┌──────────────┐
  ┌──────────────┐                                                   │  CONTROL     │
  │  ELECTRICAL  │  command (voltage / current)                      │  SYSTEM      │
  │  MODEL       │◀──────────────────────────────────────────────────│              │
  └──────────────┘                                                   │  Sensor:     │
       ▲                                                             │  position,   │
       └─────────────────────────────────────────────────────────────│  force,      │
                            control command                           │  temperature │
                                                                       └──────────────┘

  COUPLING VARIABLES EXCHANGED:
  • Electrical → Thermal:   power loss (W) as heat source
  • Thermal → Electrical:   temperature (K) → resistance R(T)
  • Thermal → Structural:   temperature field → thermal strain
  • Structural → Control:   position (m), force (N)
  • Control → Electrical:   command (V or A)

  Two-way feedback: temperature changes resistance → changes losses → changes temperature.
  Position changes control command → changes current → changes force → changes position.

  ALTERNATIVE EXAMPLE — AEROELASTIC:
  Aerodynamic load (pressure, shear) → Flexible structure (displacement) →
  Deformed geometry → Aerodynamic load update → Control response (surface deflection)

Coupling Types and Their Considerations

The table below characterises the main coupling types — one-way, two-way loose, two-way strong, co-simulation and monolithic — in terms of the coupling character, the variables exchanged, the timestep consideration, the stability behaviour, when each is appropriate and its limitations. The categories are not always sharply distinct — the boundary between "loose" and "strong" two-way coupling depends on the strength of the feedback — but the table captures the key distinctions that drive the choice of coupling strategy.

Verifying the Coupled Solution

The verification of a co-simulation is more demanding than the verification of a single-domain analysis. Each solver must be verified individually — mesh convergence, timestep convergence, reaction balance, energy balance — and the coupled solution must be verified in addition. The coupled verification checks that the coupling interface is transferring information correctly and that the coupled solution is consistent. Key checks include: are the coupling variables conserved across the interface — is the force transferred from the CFD model equal and opposite to the force received by the structural model? Is the energy transferred across the interface balanced — does the work done by the fluid on the structure equal the energy gained by the structure? Does the coupled solution converge as the coupling frequency increases — does the result change when the variables are exchanged more often, and does it approach a limit? Does the coupled solution converge as each solver's mesh or timestep is refined? Is the coupled result sensitive to the coupling strategy — does a one-way approximation differ materially from a two-way result, and if so, is the one-way result acceptable? These checks are not optional; they are the evidence that the co-simulation is producing a physically consistent coupled solution rather than two independent solutions stitched together. A co-simulation in which each solver ran without error but the coupling interface was not verified is not a verified multi-physics analysis.

RUNNING TWO SOLVERS WITH ARBITRARY TIMESTEP AND COUPLING FREQUENCY WITHOUT VERIFYING THAT THE EXCHANGED VARIABLES CONVERGE TO A CONSISTENT COUPLED SOLUTION CAN PRODUCE RESULTS THAT NEITHER SOLVER WOULD PRODUCE INDEPENDENTLY — AND NOT IN A GOOD WAY. The coupling interface introduces its own errors: interpolation error, energy imbalance, momentum imbalance, timestep lag. These errors are not visible in either solver's output alone. The coupled solution must be verified as a coupled solution, not merely as two individual solutions.

Key Takeaways

• Multi-physics captures interactions between physical domains that no single-domain model can represent
• Monolithic multi-physics solves all domains in one solver; co-simulation couples specialised solvers at an interface
• Coupling variables — forces, displacements, temperatures, heat fluxes, pressures, commands — must be identified, transferred correctly and verified
• Coupling direction (one-way vs two-way) and coupling frequency determine the tightness and stability of the coupling
• Timestep mismatch between solvers must be reconciled to the physically relevant timescale of the interaction
• The coupling interface is part of the analysis and a source of error — energy balance, momentum balance and convergence with coupling frequency must be checked
• A co-simulation is only as credible as the information transferred between the models
• Each solver must be verified individually, and the coupled solution must be verified as a coupled solution