Software

Pretty Pictures, Wrong Answers: How to Tell Whether a Flow Simulation Deserves Your Trust

Few things look more convincing in a design review than a fluid simulation, which is why CFD Software has become essential. Smooth colour gradients show air sweeping through a room, streamlines curl neatly around a car body, and a temperature map glows red exactly where everyone expected the hot spot to be. It looks like proof.

It isn’t, at least not automatically. Simulation software will almost always produce a colourful result, whether the setup is right or badly wrong. Engineers who use these tools well know that the image is the last and least important part of the work. The real question is whether the numbers behind it can be trusted enough to base a decision on.

The checks below apply whether you run the analysis yourself or review one from a consultant.

Two questions: is the maths right, and is the physics right?

Specialists split trust into two parts. Verification asks whether the equations are being solved correctly. Validation asks whether those equations, with the chosen models and assumptions, represent the real world well enough for the purpose.

A simulation can pass one test and fail the other. A perfectly converged solution on a fine mesh can still be wrong if the turbulence model is poorly suited to the flow, or if the inlet conditions don’t match reality. NASA’s NPARC Alliance publishes a free tutorial on CFD verification and validation, based largely on the AIAA guide on the subject, which is a good place to start for anyone who wants the formal background.

The same tutorial makes a useful distinction between uncertainty, a possible shortcoming caused by incomplete knowledge (turbulence modelling is the classic example), and error, a recognizable mistake that can be found on examination. It lists the main errors to look for: physical approximations, iterative convergence, discretization from the mesh and time step, round-off, programming bugs, and usage mistakes. In practice, the last category, simply setting the software up incorrectly, causes a large share of bad results.

Check that the solution actually settled

Simulation solvers work iteratively, refining the answer step by step. Stopping too early leaves an unfinished solution that can look perfectly plausible.

Residuals, the solver’s measure of how much the equations are still out of balance, are the usual first check. They should drop by several orders of magnitude and level off. But residuals alone aren’t enough. Good practice is to monitor the quantities that actually matter for the decision, such as outlet temperature, pressure drop, drag force, or air speed at a seat, and confirm they’ve stopped changing.

It’s also worth checking conservation. The mass flowing in should match the mass flowing out, and the heat added should match the heat removed, within a small tolerance. A model that loses 10% of its airflow somewhere has a problem, however good the residuals look.

Make sure the mesh isn’t driving the answer

The mesh divides the space into small cells, and the results depend on how fine and how well shaped those cells are. Too coarse a mesh smears out the details that matter: a jet from a diffuser, a thin thermal boundary layer, a vortex behind a building.

The standard test is a mesh independence study. Run the same case on at least two or three progressively finer meshes and compare the key results. When refining the mesh no longer changes the answer meaningfully, the mesh is good enough. If a consultant can’t show you this, ask why.

Cell quality matters too. Highly stretched or skewed cells cause numerical errors, and near walls the first cell height needs to suit the wall treatment used by the turbulence model. Most software reports quality metrics and wall distance values, and they’re worth reading.

Question the boundary conditions

Boundary conditions describe what’s happening at the edges of the model: how much air comes in and at what temperature, what pressure the outlets see, how much heat equipment gives off, what the wind does around a building. They’re often where the biggest errors hide, because they depend on assumptions rather than calculation.

For each boundary, ask where the number came from. Is the supply airflow from the design, from measurements, or a guess? Are server heat loads based on nameplate ratings, which usually overstate real loads, or on measured values? Is the wind profile realistic for the site’s surroundings? Small changes in boundary conditions can shift results far more than any refinement of the mesh.

Choose models to suit the flow

Turbulence models are approximations, and none of them is right for everything. Some handle attached flows well but struggle with separation. Others capture separation better but cost more. Flows driven by buoyancy, such as natural ventilation or smoke from a fire, need models and settings that represent temperature-driven flow properly.

A trustworthy report explains which models were chosen and why, ideally with reference to published guidance or validation cases for similar flows. “Default settings” is not a satisfying answer for anything important.

Compare against something you already believe

Before trusting a complex result, check it against something simpler. Hand calculations can estimate pressure drops, average temperature rises, or air change rates. Published experimental data exists for many standard cases, such as flow over a backward-facing step or around a cylinder. Measurements from an existing building or prototype are better still.

If the simulation disagrees with a simple estimate, find out why before moving on. Sometimes the simulation is revealing something the simple model misses. Often it’s revealing a setup mistake.

Look for physical sense in the results

Experienced engineers develop an instinct for results that look wrong. Air flowing out of an inlet. Temperatures below the supply temperature in a heated room. Velocities far above anything the fans could produce. Symmetric geometry producing wildly asymmetric flow without a clear reason. Any of these is a reason to stop and investigate.

Ask for the assumptions in writing

A good simulation report reads like a lab notebook. It lists the geometry simplifications, mesh details and quality, boundary conditions and their sources, physical models, convergence evidence, mesh independence results, and any validation. It also states the limitations plainly. If a report contains only pictures and conclusions, ask for the rest.

Questions to ask before you act on a simulation

Whether you’re a building owner, product manager, or engineer reviewing someone else’s work, a short list of questions covers most of the risk. Did the solution converge, judged by the quantities that matter? Was a mesh independence study done? Where did each boundary condition come from? Why were these physical models chosen? Has the approach been checked against measurements, published data, or hand calculations? And what are the known limitations?

A simulation that comes with good answers to those questions is a powerful design tool. One that comes with only a striking image deserves a polite but firm request for more.