Most CFD estimates are a single number extrapolated from one measurement on one machine. Ours is a range, it was fitted to real runs, and when we got it wrong the correction went in the direction nobody likes — the honest one.
The stored runtime figure had been measured once, at one resolution, on one core count. Everything else extrapolated from it on the reasoning that halving cell size multiplies cells by eight and halves the timestep. That extrapolation had never been measured.
When we measured it against the full benchmark, the model said 21.6 hours. The observed figure was around 59.5. Recalibrating against twenty-four meshes produced a band of 42 to 82 hours for the same job.
The first replacement band we tried was tighter and looked better. It also failed three of seven measurements, including two from its own calibration set. A band that excludes its own data is a wish, not a model. The wider band is the one that survives contact with the measurements, so it is the one we quote.
If the estimate is wrong high, the watchdog kills legitimate jobs mid-solve. If it is wrong low, the quote is fiction. Both failures are expensive and only one of them is visible.
The difference is not solver speed. It is whether you wait for capacity to free up or capacity is created for you.
Jobs run on committed capacity in the order they arrive. Cheapest per run, and entirely adequate for the iteration phase of a scheme — where you are running variants, not waiting on a submission date.
Hardware is started for your job rather than waited for. This is the tier that exists for the week before a planning submission or a Gateway 2 response, where the cost of the run is irrelevant next to the cost of the delay.
Both tiers run the same engine, the same register and produce the same document. We do not sell a cheaper answer — only a cheaper wait. A tier that relaxed the checks to go faster would be selling exactly the failure this system was built to stop.
Three providers are supported. Which one you choose is usually decided by your existing commercial agreements and your data policy, not by us.
Compute-optimised instances sized to the mesh. Jobs run to completion and the instance is released.
Supported with one operational difference worth knowing: it enforces a hard execution deadline, so the runtime estimate is not advisory there — it decides whether a job is dispatched at all.
For practices already standardised on Microsoft, and the usual answer where procurement has an existing enterprise agreement.
On-premises is a first-class option rather than a fallback. A single-tenant appliance on hardware you own means scheme data never leaves your network — which for some of the buildings this gets used on is not a preference but a condition of the engagement.
The building we validate against is a ten-storey commercial office, thirty-one and a half metres, with mechanical smoke ventilation — modelled at 1,327,200 cells across 24 meshes for a 1,500-second simulation. That is a genuine commercial scheme, not a demonstration box.
Above roughly a million cells there are operational realities that bite regardless of how much hardware you point at the problem — memory ceilings, stack limits that fail silently rather than loudly, and mesh balance that decides whether twenty-four cores behave like twenty-four or like four. Ashbeck handles these as part of dispatch rather than leaving them to whoever is watching the terminal.
The useful conversation starts from when you need the document and what it has to withstand. The resolution, the tier and the provider follow from that, and we would rather work them out with you than have you guess.