Most data hall simulations that go wrong are wrong in the model, not in the solver. The solver does exactly what the model tells it to, including things that cannot be true. A model can be built so that no steady state exists, or so that the answer is plausible and wrong. This note lists the mistakes we see most, the physical reason each one breaks a run, and a check you can make in a few minutes before you spend hours solving.
The cooling is smaller than the heat
A steady state needs every watt that goes in to leave. If the cooling units can remove less heat than the racks and power equipment put in, the room warms until something outside the model changes. The solver never settles, because there is nothing for it to settle to.
The check is addition. Total the rack heat (minus any heat a liquid loop carries away), add the power distribution units, and compare it with the rated capacity of the cooling units. Allow a margin for units that can run above rating, but not much. For example, eight units rated 10 kW each remove at most 96 kW even if each runs 20 percent over its rating, so a 120 kW hall cannot reach steady state.
The same sum catches the commonest cause: units left at their defaults. A newly placed cooling unit in the CoolSim desktop application starts at 3,200 CFM and 10 kW. If nobody changes those to the nameplate values, the model cools a different room than the one you meant.
Some control methods hide the problem. A unit set to hold a return or supply temperature will absorb whatever load it is given, so the sum above always “works” and the model reports a cool room that no real unit could deliver. Check the capacity the units would need, not just the temperatures they report.
Racks that move too little air for their power
A rack’s temperature rise follows from its power and its airflow:
Take a 10 kW rack with air at 1.2 kg/m³ and of 1,005 J/(kg K). At 1,600 CFM the rise is 19.8 °F (11.0 K), which is ordinary. At 800 CFM it is 39.5 °F (22.0 K). At 400 CFM it is 79.1 °F (43.9 K), which no server would survive.
When a model produces a rise that large, the cause is almost always the model: a flow value left at a default, a rack typed in the wrong units, or a power copied from a different row. We flag any rack whose implied rise exceeds 45 °F (25 K) before the run starts. The fix is to correct the input, not to trust the result.
Pockets of air that nothing feeds or drains
Air is conserved. If a region is sealed, with a closed cold aisle, a ducted plenum or a boxed-in corner, then everything supplied into it must leave it. A region with supply but no return has no solution. A region with return but no supply is just a dead pocket that the solver fills with whatever the neighbors push in.
The check is to walk every sealed region and ask what feeds it and what drains it. The same logic applies to a duct run that ends without a diffuser, and to a boundary inlet with no outlet anywhere in the model: continuity cannot be satisfied, and the pressure has no level to settle at.
A downflow unit raised off the floor
A downflow cooling unit blows cold air down into the raised floor. Sometimes a unit is modeled raised, with its base above the floor deck. If the deck is then cut away under it, the unit’s air goes into the plenum under the floor instead of where the real unit sends it. This one error moves the temperature of the whole hall, not just the air near the unit.
It is worth the detail because the result looked sensible. Every rack moved by the same amount, so nothing stood out. Units that hold a fixed temperature difference make it worse, because they amplify the error through their own control loop.
The check is to look at where each unit’s supply face actually sits relative to the deck, and to confirm the deck is intact under it.
Tiles and panels the mesh cannot see
A perforated tile is a flow restriction, and a nearly closed one is hard to solve. A tiny open area gives a huge pressure drop for a little flow, which makes the equations stiff, and a solver can blow up on it.
Two things matter. First, the open area needs a floor. In our solver, tiles and containment panels 10 percent open or less are modeled as thin resistance plates, which stay stable, and no tile solves below 5 percent open. A tile entered as fully closed therefore still passes some air, so a tile that is meant to be shut should be modeled as solid floor. Second, the tile needs enough cells across it to carry a flow at all. We ask for at least 9 faces on a tile, a 3 by 3 pattern, and prefer 16 or 25. For a 2 ft (0.6 m) tile that means cells no larger than 0.2 m; a 0.3 m cell leaves 4 faces, and the tile is effectively a single hole.
Altitude ignored
Air gets thinner with height. At 1,500 m (4,920 ft) the standard atmosphere puts the air pressure at 84.6 kPa, 16.5 percent below sea level, and air at the same temperature is 16.5 percent less dense. The same fan moves the same volume but carries 16.5 percent less mass and heat, so a rack’s rise goes up by about 20 percent.
A model that leaves the altitude at zero uses the wrong density and under-reports every temperature rise. The check is a single field, and it is the cheapest one on this list.
Objects that touch or overlap
Two racks that overlap, a CRAC that intersects a wall, or a panel that shares a face with a rack create zero-thickness gaps or doubled solid. The mesh has to decide which object owns that space, and the answer is not something you chose. Leave a visible gap, or merge the objects deliberately.
Catching it before the solve
None of these checks needs a solver. They need the model file and arithmetic. That is why we wrote the Model Doctor: a program that reads a model and reports each of these problems before a run is submitted. It reads the package, finds the problem and says what it found, and for some problems it offers a repair. Among other things, it checks the cooling budget, flags rack temperature rises above 45 °F (25 K), looks for sealed regions with no supply or no drain, and uses the altitude you set to compute the air density. Today it is a tool our staff run.
If you build models yourself, the habit is the useful part: add, divide, then look at where the air goes. The solver can only answer the question you asked it.
To see what a checked model looks like in a finished study, read how we know it’s right, or contact us if you want a model reviewed before it is solved.