Validation
How certain is one CFD run?
We reran the 2026 concept car for 2000 iterations instead of 1000. Drag held still; downforce kept falling. What that means for the numbers we publish, and how to read a single steady RANS run of an F1 car.
On 8 October we published a study of a 2026 concept F1 car imported from an STL file: three grids from 1.6 M to 8.5 M cells, forces, component split and balance. The medium grid gave −CL·A 1.352 m² of downforce. The fine grid gave 1.533 m², 13 % more, and we wrote that downforce was “not grid-converged”.
A day later, with the geometry, the solver post-processing and the rendering on the GPU and a determinism bug fixed, we ran the medium grid again. 1000 iterations gave 1.212 m², 10 % below the published value. Same grid, same settings, a slightly different path through the iteration. So we ran it for 2000 iterations and looked at the history.
The downforce is still moving
| iterations | 300–600 | 600–900 | 900–1200 | 1200–1500 | 1500–1800 | 1800–2000 |
|---|---|---|---|---|---|---|
| −CL·A [m²] | 1.360 | 1.238 | 1.220 | 1.234 | 1.199 | 1.169 |
| CD·A [m²] | 1.111 | 1.084 | 1.077 | 1.073 | 1.074 | 1.066 |
Drag settles within about 1 % after iteration 600. Downforce does not: after iteration 1000 it still falls by about 0.075 m² per 1000 iterations, on top of an oscillation of ±0.03–0.04 m² (one standard deviation within a block). The 1.352 we published is an average over iterations 700–1000 of a run that took a slightly different path. It sits at the top of a band that runs from about 1.17 to 1.35 m² depending on when you stop and where the average starts.
What this changes
- The medium-to-fine difference is not all grid. The +13 % from medium to fine mixes grid resolution with where each run happened to be on its drift. The fine run (1500 iterations) probably carries the same drift. We cannot yet separate the two.
- Read one run’s downforce as ±10 % and its drag as ±2 %. That is now written into the study, the report page and the documentation, next to the numbers.
- The same holds for the parametric car. Across six NVIDIA GPUs and the CPU, its medium run lands on −CL·A between 1.889 and 1.971 m² (CPU 1.937). Each device’s rounding picks a path through the oscillation, and the path picks the averaging window.
Why a steady solver does not settle
Steady RANS assumes the flow has a steady mean and solves for it directly. Behind an F1 car the real flow is unsteady: tyre wakes, the vortices off the floor edge and the rear wing, and a large separated wake. On a grid fine enough to resolve some of that, the steady iteration does not reach a fixed point. It keeps exchanging energy between those structures and ends up in a slow oscillation or drift. Downforce depends on the underbody and the diffuser, where these structures interact most, so it moves far more than drag.
What we do about it
- Longer runs, judged by block means. With the whole job on the GPU, 2000 iterations of the medium grid take under 8 minutes on the mini PC’s integrated GPU and, scaled from the parametric car’s time per iteration, about a minute on an L40S. Running until the block means stop moving costs little.
- Report the band, not just the mean. The run record now keeps the force history, so block means and their spread can go next to every number.
- Make runs reproducible first. Before the determinism fix, two identical runs on the Radeon could land in different places, and we could not tell whether a change came from the input or from the race. That question is now closed.
None of this is new to CFD practitioners. It is easy to forget once you have a fast solver that hands you a number with three decimals. We would rather publish 1.2 ± 0.1 than 1.352.
Data: results/aero/f1_2026/runs.jsonl (records f1_medium, g1_medium, h1_medium_long) and runs/h1_medium_long/history.json, the force record every 10 iterations.