We quoted 21.6 hours for a job that was going to take 60

Before a model runs, we tell you what it will cost — runtime and peak memory, from a table measured on real hardware rather than estimated. It is one of the more useful things the product does, because the alternative is discovering at hour forty that the machine cannot finish.

Then we ran the full benchmark: 1,327,200 cells, 24 meshes, 1500 seconds of simulated time. The model said 21.6 hours. Forty-nine minutes in, it had solved 20.4 seconds.

What it was not

The obvious suspect is mesh count. Twenty-four MPI ranks means twenty-four subdomains exchanging boundary data every timestep, and communication overhead does scale with the number of neighbours. It is a reasonable hypothesis and it was wrong: earlier calibration runs were already at 24 meshes and matched the model fine.

It was not hardware. Same box, same cores, same FDS build. It was not cell count either — the cost model is expressed per million cells per simulated second precisely so that scale is already divided out.

What it was

Every point in the calibration table was measured on a deck with zero pressure zones.

The benchmark script that produced the table runs a residential archetype. Leakage, &ZONE, and the glazing control tree were all added to the engine afterwards. So the table described a solver doing strictly less work than the one we ship — and had no way of knowing.

Control and device counts correlate here too, and it would have been easy to blame them. Runs 82 and 83 separate the variables: 83 has twice the glazing controls of 82 and is cheaper. The control tree is not what costs. The pressure solve is.

The run we threw out, and why we named it

Run 45 measured 4.6× the table — the worst point in the set, and excluding it moves the fit substantially. It is the run from the sealed compartment: it reached 60,275 Pa because nothing vented.

A pressure solver asked to converge on a compartment with no path to atmosphere iterates far harder than one that vents. Its 4.6× measures a broken model, not the cost of pressure zones. Folding it into the fit would have inflated every future quote to cover a defect the register now blocks outright.

The fix

A linear multiplier on zone count, because zone count is the mechanism:

The mistake inside the fix

The first version of the corrected model quoted a band of ±15% around the estimate. It was fitted only to the zoned runs, and it failed three of the seven measurements it was meant to describe — two of them from its own calibration set.

It is now derived from the runs of commercially meaningful length, with the sub-minute ones excluded and said — a 45% error on a 77-second run is 35 seconds, and letting that widen the band would make every real quote useless to protect a number nobody is billed for.

The estimate is also returned as a range rather than a number. A single figure reads as a promise, and this one cannot see how hard the pressure solve will turn out to be, what the fire does, or whether the glazing fails early.

Why this matters commercially

The cost model is not an internal curiosity. It feeds three things:

• The quote. Under-predicting by 2.8× on large jobs is a direct loss on every one of them.
• The watchdog ceiling, derived from the prediction. Set it from zone-free data and a legitimate run gets killed near completion — the most expensive possible failure, because it wastes the whole run.
• The engineer's afternoon. "Four hours" and "two days" are different decisions about whether to start now or refine the model first.

Every fire modelling tool has a cost model, whether or not it admits it. Most of them live in someone's head as "about a day for something like this". The difference is not whether the estimate is wrong — it is whether anyone measures it afterwards, and whether the correction gets written down.

One thing this does not fix

The correction is to a model, not to hardware. On faster cores the absolute number falls, but the zone multiplier does not — the pressure solve is real work, and it scales with what the building actually is. A larger job needs a larger machine, and the honest version of that is that compute is a real cost we pass through rather than a rounding error we absorb.