Co-Simulation (Coupling with MpCCI)
Theory: linking separate codes in time
Overview
I have the fluid model in Fluent and the structure in Abaqus, and want to couple them with MpCCI. What should I watch for?
MpCCI is coupling middleware developed by Fraunhofer SCAI in Germany; it exchanges interface data (forces, displacements, temperatures, heat fluxes) between separate codes. The biggest advantage is using your familiar models as they are. What to watch is the interval between exchanges (the coupling step) and how values are assumed in between. Get these wrong and, however accurate each code is internally, the coupled result can drift badly or gain energy spontaneously and diverge.
The example model
A standard problem for probing co-simulation: two masses joined by spring $k_c$, split so subsystem 1 receives $x_2$ and subsystem 2 receives $x_1$. $m$ = 1 kg, $k = k_c$ = 1,000 N/m, $c$ = 1 Ns/m. The shortest natural period is 0.115 s.
Exchange schemes
The partner's value can be held constant over the coupling step $H$ (hold) or extended linearly from the last two values (linear extrapolation). Also, both subsystems can use the previous values simultaneously (Jacobi) or one can advance first and pass its new value to the other (Gauss–Seidel).
The arrival of coupling middleware
Until the 1990s, fluid–structure coupling usually meant researchers modifying and linking programs themselves. Data formats and meshes differed per code, and integration was enormously laborious. As a common mechanism for exchanging interface data regardless of software, MpCCI development began at an institute of Germany's GMD (later merged into Fraunhofer), and it spread in the 2000s as a tool for linking commercial codes. Today the FMI (Functional Mock-up Interface) standard for exchanging component models is also widespread, and co-simulation has become a standard design technique.
Worked example: coupling step and exchange
Solved for 2 s from 0.01 m initial displacement and compared with a single-system reference. Inside each subsystem, fourth-order Runge–Kutta with 20 sub-steps per coupling step solves accurately. The table gives the maximum $x_1$ error (% of initial displacement) and energy at 2 s relative to the reference:
| Coupling step | Jacobi + hold | Jacobi + linear | Gauss–Seidel |
|---|---|---|---|
| 1 ms (1/115 period) | 19% (×2.1) | 0.6% (×1.00) | 9.0% (×1.4) |
| 5 ms (1/23) | 185% (×108) | 17% (×1.2) | 55% (×9.1) |
| 10 ms (1/11.5) | Diverges (×11,658) | 77% (×5.7) | 180% (×98) |
| 20 ms (1/5.8) | Diverges | Diverges | Diverges (×5,317) |
Even at 1/115 of the period, just holding values is off by 19%?
Yes. Holding values means the partner's position is always slightly stale. A spring force acting late adds a little energy to the vibration every cycle. Despite damping, energy at 2 s was 2.1 times the reference, and 108 times at 5 ms. Linear extrapolation greatly reduces the lag, improving to 0.6% at the same 1 ms. But extrapolation isn't a cure-all — at 20 ms every scheme diverged. The basics are to choose a good exchange scheme, keep the step small relative to the period, or iterate within each step to match the interface (strong coupling).
Analysis workflow
- Decide what is exchanged (force and displacement, temperature and heat flux) and which code receives what.
- Estimate the shortest period or time constant and choose candidate coupling steps.
- Set up monitoring of energy flow across the interface.
- Halve the step and confirm results don't change; if they do, add extrapolation or iteration (strong coupling).
- At non-matching interfaces, choose a transfer method that conserves total force.
“Once coupled, the vibration never stops”
A vibration that decayed in the structure-only analysis grew gradually once coupled to the fluid until the run stopped. The coupling interval had been matched to the fluid step, but the exchange used a hold scheme. Comparing work done by the fluid at the interface with work received by the structure, the structure received slightly more every step. Halving the coupling interval and switching to extrapolated displacement made the vibration decay correctly. The quickest check for spurious energy is interface work.
Common mistakes
Mistakes and fixes
| Mistake | Effect | Fix |
|---|---|---|
| Setting only each code's step | Coupling error missed | Study the coupling step separately |
| Staying with hold | Energy grows | Extrapolate or iterate |
| Not monitoring interface energy | Divergence unexplained | Monitor interface work |
| No step sensitivity check | Unknown reliability | Halve and compare |
| Non-conservative transfer | Total force off | Conservative mapping |
I'd like to learn related topics.
For solution strategy see partitioned vs monolithic solution, strong versus weak coupling and staggered coupling; for interface data, mapping between dissimilar meshes; for overall architecture, system coupling strategies and multiphysics digital twins.
Related Topics
Experience the theory firsthand with the interactive simulator for this field
All Simulators