“Right” can mean two things for a CFD model. It can mean the solver did its job: the equations are balanced, the heat is accounted for, and the report describes the model you built. Or it can mean the model matches your room. We can check the first on every job, and this page shows how. The second depends on what goes into the model, and the last section is about that.
The solver
CoolSim was first built at Fluent, Inc. in 2005. Fluent is now part of Ansys, and CoolSim is an Ansys Technology Partner.
The physics isn’t ours. Every job is meshed with Ansys Icepak and solved with Ansys Fluent, the commercial solvers engineers use across industry for airflow and heat transfer. Our part is turning racks, cooling units, floor tiles and containment into a model those solvers can run, and checking the answer before it reaches you.
Since 2016 we have delivered more than 31,000 customer simulations this way. This page describes jobs built in the CoolSim model builder and solved on our cluster.
What every job has to pass
These checks run on our cluster on every job. Nobody has to remember to run them.
- The model is complete. Before meshing, the model file and its settings are read and checked. A file that is missing parts or can’t be read stops here.
- The mesh is valid. After Icepak meshes the room, its errors and warnings are read. A mesh with objects left unmeshed, or with objects the air can’t reach, is rejected and meshed again. An invalid mesh never reaches the solver.
- The solution settles. Fluent iterates until each equation’s leftover error, its residual, reaches its target or an iteration limit set by the mesh size. At the end, the airflow and energy residuals must be below set limits. One exception: if only the mass-balance residual is above its limit, by no more than five times, the solution is accepted when the heat balance passes and nothing in the room is impossibly hot (above 302 °F, 150 °C, a sign of a broken model). Anything else is refused.
- Heat in equals heat out. The heat the racks put into the room has to leave it, through the cooling units and the room’s boundaries. After the solve, the heat entering and leaving the room is added up. The difference must be under 1% of the rack heat load on a fine mesh, 3% on a medium mesh and 5% on a coarse one, or the solution is refused. This runs on every model with rack heat.
- A diverging solve is stopped. If the residuals grow instead of shrinking, the solve stops. It isn’t left to run to its limit and report whatever it reached.
- The report is complete. Before the completion email goes out, every file the report needs is checked for.
If a job fails any of these, it isn’t delivered as a result. You get a failure notice, our support team gets a copy of it, and a support engineer follows it up.
Before a change reaches your jobs
We change the scripts that mesh, solve and report a job, like any software. Each new version is run on a set of recent customer jobs, on our own account so nobody is billed. They cover the kinds of model customers run: rooms, ducted and raised-floor sites, parametric studies, large halls and external flow. Each job must complete and deliver a report that names the same equipment as the one the customer received, with the same average temperatures within a set tolerance. A version that fails isn’t given to customers.
Check a report yourself
You don’t have to take the heat balance on trust. Every report lists the heat the racks put into the room and the heat the cooling units take out, and you can compare them.
In our sample report, built from our Demo Data Center example model:
- Total Rack Heat Load: 618.78 kW
- Total Heat Removed by CRACs: 617.04 kW
That’s 0.3% apart. Look for the same two lines in your own report.
What a model can’t tell you
All models are wrong; some are useful. The checks above show that a solution is sound: its equations are balanced, its heat is accounted for, and its report is complete. They don’t show that the model matches your room.
A model’s temperatures are only as close to the room as its inputs are: the rack loads, the open area of each tile, the cable cutouts, the cooling units’ airflow and setpoints. Two habits get the most out of a model:
- Put in what’s really there. Measured rack loads and tile airflows make a better model than nameplate values and guesses.
- Compare options, not single numbers. The difference between two runs of the same model, with and without containment or with one cooling unit off, is usually more trustworthy than any one absolute temperature. That’s the question most studies are asking anyway: which layout, which failure, which fix.
What CFD is, and how a simulation works explains the method in more depth.