CFD Basics for Buildings

At its heart CFD enforces three conservation laws in every cell of the domain: mass (air is neither created nor destroyed), momentum (Newton's second law applied to a fluid - the Navier-Stokes equations), and energy (heat is conserved, which lets it solve temperature alongside flow). You do not solve these by hand; the point is to understand what they express. The momentum equations say that the air in each cell accelerates because of pressure differences, viscous friction, and buoyancy forces - which is why CFD can capture a warm plume rising or a jet bending around a corner.

These equations have no general analytical solution, so CFD solves them numerically: it approximates the smooth reality with a large set of algebraic equations, one set per cell, and iterates until they balance. The consequence is fundamental and worth internalising - CFD is always an approximation. It is not the fluid; it is a discretised, iteratively-solved model of the fluid, and every step in setting it up - how finely you dice the space, what you specify at the edges, how you model turbulence, when you decide it has 'converged' - introduces a choice that can help or harm the answer. The elegance of the output hides how many judgement calls produced it.

The first big choice is the mesh - dicing the space into cells. Where the flow changes fast (near walls, around openings, in a jet) you need fine cells; in the calm core you can use coarser ones. Too coarse and the mesh smears out the very features you care about; too fine and the run takes forever. The professional discipline is a grid-independence study: refine the mesh, re-run, and check the answer stops changing. If your result shifts every time you refine, you are reading mesh artefacts, not physics. Near-wall regions get special treatment (fine layers or 'wall functions') because that is where friction and heat exchange happen.

The second big choice is boundary conditions - what you tell the solver about every edge of the domain. An inlet needs a velocity and temperature (and turbulence values); an outlet typically a pressure; walls get a no-slip condition (air velocity is zero at the surface) and either a fixed temperature or an adiabatic 'no heat flow' assumption. These inputs are the problem you are solving. Get the inlet velocity wrong, assume a wall is adiabatic when it is a hot west facade, or place the outlet where no air actually leaves, and the solver will faithfully compute a beautiful, wrong answer. The old computing adage is nowhere truer than in CFD: garbage in, garbage out. Most bad building-CFD results trace not to the solver but to careless boundary conditions.

Real building airflow is turbulent - chaotic, swirling at every scale. Resolving every eddy directly (DNS) is far beyond practical computing for a room, so building CFD uses turbulence models that approximate turbulence's average effect. The everyday workhorse is RANS (Reynolds-Averaged Navier-Stokes), typically with a k-epsilon or k-omega model; it is affordable and gives sensible time-averaged fields, but it is a model of turbulence, not the real thing, and it struggles with separation, strong buoyancy and fine jet behaviour. More detailed LES (Large Eddy Simulation) resolves the big eddies and is more faithful, but costs far more. Choosing a turbulence model is choosing a set of approximations, and different models can give visibly different answers to the same room - a fact CFD's confident images conveniently hide.

Then comes convergence. Because CFD iterates, you must decide when the solution has settled. The tool tracks residuals - a measure of how badly the conservation equations are still out of balance - and you watch them fall over iterations. A converged run has residuals that drop by several orders of magnitude and then flatten low; the monitored quantities (a velocity, a temperature) stop drifting. A run whose residuals plateau high, or whose values are still wandering, is not converged - and its pretty field is meaningless. This is one of the most common ways beginners fool themselves: they stop the solver too early, or accept a non-converged result because the picture already looks plausible.

Knowing the pieces, here is how a building CFD study actually runs, start to finish. You define the domain - a single room for an indoor study, or the building plus a generous box of surrounding air for an outdoor wind study. You generate the mesh, refining near walls and openings. You set boundary conditions from real data - for outdoor work the inlet is a wind profile that increases with height, taken from the site's wind rose; for indoor work it is the supply or window conditions. You choose a turbulence model (RANS k-epsilon for most design work). You solve, watching residuals. Then you post-process: velocity fields, temperature fields, and derived comfort metrics. Skipping or rushing any step is where errors enter.

The tool landscape spans free to expensive. OpenFOAM is the free, open-source, industrial-strength engine - immensely capable but with a steep, text-file-driven learning curve. Butterfly, part of the free Ladybug Tools suite, drives OpenFOAM from Grasshopper with a visual interface, and is the most accessible on-ramp for designers who already model in Rhino. On the commercial side, Autodesk CFD, Ansys Fluent and SimScale (cloud-based) are faster to set up and better supported, at a price. A crucial caution cuts across all of them: the software does not protect you from a bad model. A polished commercial tool will mesh, solve and render a wrong boundary condition just as beautifully as a free one. The value is never in the button; it is in the setup discipline and the sceptical reading - which is exactly why this lesson spends more words on convergence and boundary conditions than on any menu.

When a run is converged and mesh-independent, you read the velocity field for the story: where air moves fast (a jet, a draught risk if it hits an occupant above ~0.8 m/s in cooling), where it stagnates (dead zones, stale air, poor mixing), and where it recirculates. A temperature field shows stratification - warm air pooling high, cool air low - and whether the occupied zone actually gets conditioned air. You are looking for patterns and relative differences between design options, not precise absolute numbers at a point.

And here is the honesty this whole module insists on. CFD's limits are real and easy to forget: results depend on the mesh, the boundary conditions and the turbulence model, all uncertain; a steady-state run captures one condition, not the messy variability of a real day; and the smooth, authoritative image invites far more confidence than the underlying assumptions justify. Treat CFD as an insight tool - it reveals how air behaves and why one option beats another - not as a precise predictor of the velocity at coordinate (x, y, z). Use it comparatively, validate it against a simpler check or measurement where you can, sanity-test every result against physical intuition, and never let a beautiful picture override common sense. A CFD study you cannot defend on its mesh, boundaries and convergence is decoration, not evidence. The most experienced modellers are, tellingly, the most sceptical of their own results - they cross-check a CFD field against a hand calculation, a simpler airflow-network run, or a measured value whenever one is available, precisely because they know how convincingly the method can lie.