A full car fire under a steel car-park frame: FDS + CalculiX coupled with preCICE on cloudHPC
TL;DR
- We coupled FDS 6.11.1 (fire) and CalculiX 2.20 (steel frame) through preCICE 3.3.1 and our open-source FDS preCICE adapter, and ran a full 35.5-minute car fire (8.2 MW peak, 6.67 GJ) under an 8 m steel frame carrying a car-park slab.
- The beam above the car reached 755 °C (791 °C at the hottest node); the frame did not collapse during the fire. Mid-span deflection grew from 17.7 mm (cold, fire load combination) to 33.9 mm (L/236) at 23.8 min, then recovered to 21.5 mm while the steel was still above 700 °C.
- The governing effect is restrained thermal expansion: the hot beam pushes the column tops outward by 18 mm, bends the columns and loads their cold bases. Plastic strain appears at 16.5 min at the cold beam–column joints and at 19 min at mid-span; it stays small (max 0.46 %, in the top flange at mid-span).
- The run took 9 h 05 min on a 16-core hypercore spot instance and cost €16.32.
- Getting there exposed three things worth knowing if you couple CalculiX on the cloud: the CalculiX adapter advances preCICE on non-converged increments (PR #179), multithreaded SPOOLES gave wrong solves on many-core machines, and a coupled log can grow to 206 MB.
Why this case
In the previous post we introduced the FDS preCICE adapter and validated it on two small cases: a ceiling plate against a 1D conduction solution and a clamped plate against a hand calculation of thermal stress. Both were deliberately simple.
This post is the next step: a case that looks like an engineering question. A car burns in an open car-park bay, under a steel portal frame that carries the slab. How hot does the steel get, how much does the frame move, does it yield? These are the questions a fire engineer answers with a performance-based (FSE) design, usually with a decoupled workflow: run FDS, extract adiabatic surface temperatures, apply them as boundary conditions in a separate thermal-structural model.
Coupling the two codes removes the hand-over: FDS sees the real (and rising) steel surface temperature, CalculiX sees the real heat flux, every 5 seconds, for the whole fire.
Results at a glance
| Quantity | Value | When |
|---|---|---|
| Fire: peak heat release rate (design 8.2 MW) | 8.11 MW | 25.1 min |
| Fire: total energy (design 6.67 GJ) | 6.66 GJ | 0–35.5 min |
| Gas 5 cm below the beam, mid-span (max) | 1310 °C | 26.4 min |
| Adiabatic surface temperature, beam soffit (max) | 871 °C | 29.4 min |
| Steel, beam soffit above the car (max) | 755 °C | 31.3 min |
| Steel, hottest node of the frame | 791 °C | 30.0 min |
| Steel, beam soffit 2 m from mid-span (x = 2 m / 6 m) | 247 / 261 °C | end |
| Steel, columns at 1.2 m (top of the columns: 136 °C) | 112 °C | 31.5 min |
| Mid-span deflection: cold, full load | 17.7 mm | 20 s |
| Mid-span deflection: maximum (absolute; 34.8 mm relative to the column tops) | 33.9 mm (L/236) | 23.8 min |
| Mid-span deflection: end of fire | 21.5 mm | 35.5 min |
| Column tops pushed outward (max) | 18.2 mm each | 31.8 min |
| First plastic strain: beam–column joints (steel ≈ 40 °C) | PEEQ > 0 | 16.5 min |
| First plastic strain at mid-span (top flange) | PEEQ > 0 | 19.0 min |
| Maximum plastic strain (top flange, mid-span), still rising | 0.46 % | end |
| Run: wall time / cost | 9 h 05 min / €16.32 | 16 vCPU hypercore, spot |
The case
Geometry. An open car-park bay, 10 × 6 × 2.8 m, all four sides open. A steel portal frame spans 8.0 m between column axes: beam RHS 400×200×10 against the slab, columns SHS 200×200×10, clear height 2.4 m, S355 steel. The column bases are fixed; the beam top is held sideways by the slab; the beam–column joints are stiffened.
Loads. The fire situation of EN 1990 (§6.4.3.3) for a category F car park (EN 1991-1-1): slab 160 mm (4.0 kN/m²), finishes 0.5 kN/m², traffic 2.5 kN/m² × ψ₂ = 0.6, over a 5.0 m tributary width → w = 30.0 kN/m on the beam, plus the steel self-weight. For reference, the cold ULS load is 49.1 kN/m. The load is ramped in over the first 20 s, when the fire is still a few kW.
Fire. A single car on the floor under the beam, modelled as a 1.8 × 4.4 × 1.4 m box with the heat release on its top face. The curve is a t² growth to 8.2 MW at 25 min, then a linear decay to zero at 35.4 min, for 6.67 GJ. Peak, time to peak and energy are those of car test C2 of the CTICM car-park campaign (Joyeux, 1997), as tabulated by Tohir & Spearpoint (2013).
What is exchanged. Every 5 s (parallel-explicit coupling), FDS sends the net heat flux into the steel (convective + net radiative) on all steel faces, and CalculiX sends back the steel surface temperature, which FDS uses as the wall temperature of those faces. The FDS geometry does not move: deformations stay on the CalculiX side (34 mm against 100 mm FDS cells would not be visible to FDS anyway).
How the run was set up
| Fire side | Structure side | |
|---|---|---|
| Solver | FDS 6.11.1 with the FDS preCICE adapter | CalculiX 2.20 with calculix-adapter 2.20.2 |
| Coupling | preCICE 3.3.1, parallel-explicit, 5 s windows, 426 windows, nearest-neighbour mapping | |
| Model | 0.1 m cells, 168,000 cells in 10 meshes; slab: 160 mm concrete; open boundaries on four sides | 3,864 C3D20R hexahedra (1 element through the 10 mm wall), 25,774 nodes; NLGEOM; *COUPLED TEMPERATURE-DISPLACEMENT |
| Material | propane surrogate fuel, soot yield 0.07 | S355 to EN 1993-1-2: E, fp, fy with the elliptic branch, thermal expansion, conductivity and specific heat, all temperature-dependent |
| Time stepping | adaptive (180,796 FDS steps) | fixed 1 s increments (2,130 increments, 8,922 iterations, 0 divergences) |
| Cores (16 vCPU hypercore) | 10 MPI processes | 6 threads (SPOOLES solver on 1 thread, see below) |
The cloudHPC app is preCICE-v3.3.1: it detects the FDS folder (one .fds file with a &PRCI namelist) and the CalculiX folder, gives FDS one MPI process per &MESH, gives CalculiX the remaining cores, and starts both.
Results
Fire and temperatures
FDS reproduces the design curve: 8.11 MW at 25.1 min and 6.66 GJ, against 8.2 MW and 6.67 GJ. The gas just under the beam above the car reaches 1310 °C around the peak; the adiabatic surface temperature of the beam soffit, the temperature an inert surface would reach, stays around 800–870 °C between 20 and 30 minutes.
The steel lags behind, as it should. The beam soffit above the car passes 400 °C at 17.6 min, 600 °C at 21.5 min and 700 °C at 25 min, peaks at 755 °C at 31.3 min, six minutes after the fire peak, and is still at 722 °C when the car has burnt out. Two metres from mid-span the soffit only reaches 250–260 °C (the webs there up to about 440 °C), and the columns stay near 110 °C at mid-height (136 °C at the top): the heating is local, with 2.5 m of beam (webs included) above 400 °C at 24 min and 4.4 m at 30 min.
What the frame does
Cold state. Under the fire load combination the cold frame deflects 17.7 mm at mid-span. A quick check: the same beam (I ≈ 2.4·10⁸ mm⁴) simply supported would deflect about 31 mm, fully fixed about 6 mm; the frame with stiff joints and flexible columns sits in between, as expected.
Heating (0–24 min). As the beam above the car heats up, its stiffness and strength drop (EN 1993-1-2) and the bottom flange expands more than the top one, which is shielded by the slab. Both effects increase the deflection, which reaches 33.9 mm (L/236) at 23.8 min. The first plastic strain appears at 16.5 min, not in the hot zone but at the cold beam–column joints (steel at about 40 °C), where the expanding beam is restrained. At mid-span the top flange starts to yield at 19 min and the bottom flange at about 22 min.
Restrained expansion. The hot part of the beam wants to get longer, and the columns, clamped at the base, resist. The beam pushes the column tops outward by 12.7 mm at 23.8 min and up to 18.2 mm at 31.8 min. The columns bend, and from about 27–28 minutes the largest stresses of the whole frame are at their cold bases: the node-averaged von Mises stress there reaches about 430 MPa, a local peak at the clamped corner of the mesh. At the integration points the steel cannot exceed its yield stress (355 MPa at 20 °C). This is exactly the mechanism the case was built to show: heat, expansion, restraint, internal stress.
After the peak (24–35 min). The deflection comes back to 21.5 mm while the beam is still above 700 °C. The main reason is visible in the temperatures: the top of the section catches up, and the bottom-to-top flange difference at mid-span drops from about 370 °C at 23.8 min to about 220 °C at the end, so the thermal bowing shrinks. The plastic strain grows slowly to 0.37 % by 33 min, then accelerates to 0.46 % at the end of the simulation, still increasing, at the top flange at mid-span. Above 0.1 % it is concentrated in the heated middle 4 m of the beam and at the beam–column joints.
Verdict for this design fire: the frame survives the heating phase with small plastic strains. In the fire combination the beam is lightly loaded (30 kN/m against 49 kN/m at cold ULS), and the cooler parts of the continuous frame take over what the hot middle cannot carry.
What this case does not tell you
- It is one car, in one position, with one design curve. A car-park FSE looks at several positions (under the beam, under a column, between bays) and often at fire spread to adjacent cars.
- The slab is a thermal boundary in FDS and a load in CalculiX, but it is not modelled as a structural member: no composite action, no membrane effect.
- The cooling phase is not simulated: the run stops at burnout with the beam still at about 720 °C and the plastic strain still increasing. Cooling of a restrained beam produces tension and can matter for the connections.
- There is no experiment for the coupled structural response of this frame. The fire input comes from a test; the coupling was validated in the previous post; the cold deflection agrees with a hand check; the rest is a prediction.
What went wrong on the way (and how it was fixed)
Coupled runs fail in ways single-solver runs do not. These are the issues we hit, in the order they appeared.
| Run | Set-up | What happened | Cost |
|---|---|---|---|
| 92576 | 300 s, CalculiX automatic increments, SPOOLES 11 threads | Completed, but CalculiX ended at 259 s while preCICE reached 300 s: 13 cutbacks, 41 s of lag | €1.05 |
| 92585 | 300 s, fixed 1 s increments, SPOOLES 11 threads | Diverged at the first increment (residual 1.8 MN against 58 N locally) | €0.29 |
| 92587 | 300 s, 8 vCPU, CalculiX 3 threads | Residuals off from increment 1, diverged at increment 17 | €0.16 |
| 92588 | 300 s, 4 vCPU, CalculiX 1 thread | OK: residuals equal to the local run, 18.02 mm at 300 s | €0.72 |
| 92589 | CalculiX 2.21 alone, 16 vCPU, SPOOLES 1 thread | OK: residuals equal to the local run (8–9 significant digits) | €0.29 |
| 92592 | 300 s, 16 vCPU, new launcher (SPOOLES 1 thread) | OK: 18.02 mm at 300 s, matches 92588 | €2.10 |
| 92610 | full fire, 2130 s, 16 vCPU | OK | €16.32 |
1. The CalculiX adapter advances preCICE on non-converged increments. With automatic incrementation, CalculiX repeats an increment with a smaller size when it does not converge. The adapter (2.20.2 and the current develop branch) writes the coupling data and calls advance() before CalculiX rolls back, so preCICE time runs ahead of CalculiX time by the size of every failed increment, and the other solver receives temperatures from a non-converged solution. In run 92576 that added up to 41 s of lag in 300 s. We submitted a fix: precice/calculix-adapter PR #179. Until it is merged, use fixed increments (*COUPLED TEMPERATURE-DISPLACEMENT, DIRECT) small enough to converge: 1 s here.
2. Multithreaded SPOOLES gave wrong solves on many-core machines. The same input, the same first increment, gave a largest residual force of 58 N locally and 1.8 MN on 11 threads in the cloud. On 3 threads the residuals already deviated at the first increment and the run diverged at increment 17; on 1 thread it never went wrong. The standalone CalculiX 2.21 on cloudHPC, built with a single-threaded SPOOLES, matched the local run to 8–9 significant digits while assembling the stiffness and computing stresses on 16 threads. The decisive test is run 92592: the same CalculiX preCICE binary, with 11 threads everywhere except SPOOLES on 1 thread, matches the all-single-thread run 92588 (18.02 mm at 300 s, within 0.002 mm). So the culprit is the multithreaded SPOOLES of the CalculiX preCICE package, not CalculiX’s other multithreaded parts. The cloudHPC preCICE app now runs SPOOLES on 1 thread (CCX_NPROC_EQUATION_SOLVER=1) and keeps the other threads.
3. A coupled FDS run writes a lot of log. Every FDS MPI process prints a preCICE line at every FDS time step. With 10 processes and 180,796 steps, the platform log of the full run reached 206 MB, and its periodic copy to the web interface got stuck for hours (the simulation itself was not affected). The launcher now filters what it prints: one preCICE line per coupling window instead of one per FDS step and per process, and no CalculiX iteration detail. On the output of a 300 s test run (92592) the filter takes the participants’ output from 4.9 MB to 78 KB; the full solver logs stay in fluid/log.Fluid and solid/log.Solid.
Run time and cost
| Value | |
|---|---|
| Instance | 16 vCPU hypercore, spot (preemptible) |
| Coupled simulation (both solvers) | 545 min |
| Billed time (boot, run, upload) | 9.27 h, 148.4 core-hours |
| Cost | €16.32 (≈ €0.11 per vCPU-hour) |
| FDS | 180,796 time steps; about half of the FDS rank-0 time is spent outside the flow solver (most likely waiting at the coupling) |
| CalculiX | 2,130 increments, 8,922 iterations (4.2 per increment), 32,718 s |
| All development runs (table above, a 1-vCPU CalculiX check and an early run that hung) | €11.32, of which €6.69 for the run that hung before the launcher watchdog existed |
The pace was not uniform: about 15–17 s of wall time per second of fire in the first 12 minutes, when CalculiX was the slower participant; about 18 s per second on average between 18 and 30 minutes of fire, around the 8 MW peak, when FDS needs time steps of about 0.009 s; and under 10 s per second during the decay. With the CalculiX fix of PR #179 in place, automatic increments of up to 5 s should cut the CalculiX work in the cool phase by a factor of 3–5 (our estimate); the phase around the peak, limited by FDS, would not change.
A coupled run cannot be restarted (preCICE keeps no checkpoint): on spot instances a preemption means starting again. For a 9-hour run that is a real risk; we took it and it went through. For production work on long fires, consider a regular instance.
How to run this case on cloudHPC
- Layout.
precice-config.xmlat the root, afluid/folder with one.fdsfile containing a&PRCInamelist, and asolid/folder with the CalculiX input and the adapter’sconfig.yml. All files are in thecases/folder of the download. - App:
preCICE-v3.3.1. FDS gets one MPI process per&MESH, so split the domain (here 10 meshes of 1 m) and choose the vCPU count accordingly; CalculiX gets the rest. - Steel surfaces in FDS: a
&SURFwithTMP_FRONT(noMATL_ID), listed in&PRCI SURF_ID. Its temperature is replaced by the CalculiX value at every window. - CalculiX:
*COUPLED TEMPERATURE-DISPLACEMENT, DIRECTwith a fixed increment that divides the coupling window (1 s for a 5 s window), until a calculix-adapter release includes PR #179. - Output frequency: CalculiX uses one frequency for the
.frdand the.dat(the lastFREQUENCY=read wins). With 1 s increments, write every 10 increments, or the.frdgrows to about 12 GB. - Results: FDS outputs in
fluid/and in theCloudHPC-massive-files-*.tar.gzarchive (slices, boundary files), CalculiX results insolid/frame.frdandsolid/frame.dat. Storage is kept for 60 days.
FAQ
Can FDS be coupled with a finite-element code for structural fire analysis? Yes. FDS has no structural solver, but with the open-source FDS preCICE adapter it can exchange heat flux and surface temperature with any preCICE-enabled solver. Here it is coupled with CalculiX for a thermo-mechanical analysis of a steel frame.
Why couple FDS and CalculiX instead of using adiabatic surface temperatures? The adiabatic surface temperature approach is one-way: the structural model needs its own convective coefficient, and the FDS gas field never sees the heated steel. Two-way coupling exchanges the actual heat flux and surface temperature at every coupling window, and removes the manual hand-over between the two models.
How hot does a steel beam get above a burning car? In this case, with an 8.2 MW design car fire directly under an RHS 400×200×10 beam at 2.4 m, the beam soffit reached 755 °C after 31 minutes and stayed above 700 °C until the end of the fire. Two metres from mid-span the soffit stayed near 250 °C.
Does the steel frame fail in a single car fire? Not during the heating phase of this case. Plastic strain appears at 16.5 minutes at the beam–column joints and at 19 minutes at mid-span, but stays small (max 0.46 %), and the deflection peaks at 33.9 mm (L/236). The main structural effect is restrained thermal expansion pushing the column tops outward by about 18 mm. The cooling phase was not simulated.
How long and how much does a coupled FDS–CalculiX run take on cloudHPC? The full 35.5-minute fire took 9 h 05 min on 16 hypercore vCPU (spot) and cost €16.32. A 5-minute test of the same case costs about €2.
References
- D. Joyeux, Natural fires in closed car parks — car fire tests, CTICM report INC-96/294d-DJ/NB, 1997.
- M. Z. M. Tohir, M. Spearpoint, Distribution analysis of the fire severity characteristics of single passenger road vehicles using heat release rate data, Fire Science Reviews 2:5, 2013. doi:10.1186/2193-0414-2-5
- K. McGrattan et al., Fire Dynamics Simulator User’s Guide and Technical Reference Guide, NIST Special Publications 1019 and 1018, sixth edition (FDS 6.11.1). github.com/firemodels/fds
- G. Chourdakis et al., preCICE v2: A sustainable and user-friendly coupling library, Open Research Europe 2:51, 2022. doi:10.12688/openreseurope.14445.2
- preCICE CalculiX adapter: github.com/precice/calculix-adapter; fix for non-converged increments: PR #179.
- G. Dhondt, CalculiX CrunchiX User’s Manual, version 2.20. calculix.de
- FDS preCICE adapter (CFD FEA SERVICE): github.com/CFD-FEA-SERVICE/fds-precice-adapter
- EN 1993-1-2:2005, Eurocode 3: Design of steel structures — Part 1-2: General rules — Structural fire design.
- EN 1990:2002, Eurocode — Basis of structural design; EN 1991-1-1:2002, Eurocode 1: Actions on structures — Part 1-1: Densities, self-weight, imposed loads for buildings.
CloudHPC is a HPC provider to run engineering simulations on the cloud. CloudHPC provides from 1 to 224 vCPUs for each process in several configuration of HPC infrastructure - both multi-thread and multi-core. Current software ranges includes several CAE, CFD, FEA, FEM software among which OpenFOAM, FDS, Blender and several others.
New users benefit of a FREE trial of 300 vCPU/Hours to be used on the platform in order to test the platform, all each features and verify if it is suitable for their needs
