Lessons in Computational Fluid Dynamics

Submitted by Richard Smith on October 14, 2008 - 16:18

After a string of success stories (e.g., "Car Design and CFD"), Computational Fluid Dynamics (CFD) recently came in for some implied (if not direct) criticism in two widely reported articles. Peering behind the headlines reveals important lessons in benchmarking and the use of CFD.

Both articles implied that the use of CFD led to faulty conclusions. The Forbes article cites a CFD analysis that was needlessly performed to try to diagnose poor data center cooling, when in fact the problem was simply that the installed equipment was not functioning correctly. You could argue (as the author, Kenneth G. Brill , did) that the problem with the data center analysis was directly attributed to the CFD consultant not matching the CFD model with the actual (faulty equipment) conditions in the data center - the consultant didn't set foot inside the data center.

The Formula1.com article implies that having failed to accurately predict the performance of the CDG wing with CFD, the move to the wind tunnel would ensure correct results. As I discussed previously in "Wind Tunnels and CFD," neither analysis technique alone is a total solution for aerodynamic evaluation.

Lessons Learned

Good engineering practice suggests that prior to using an analysis technique on a new configuration, you should benchmark (validate) the technique against a known (respected) test case similar to the new configuration. If no suitable test case exists, as was probably the case with the CDG wing, then cross referencing with another analysis technique, such as a wind tunnel, is essential. For CFD, the benchmarking process should result in guidelines for a specific class of problems. The guidelines would likely mention the preferred boundary conditions, turbulence model and meshing strategy (clustering and growth rate) required to achieve a desired level of confidence (or accuracy) in the results.

Benchmarking the CFD analysis model with actual temperatures and flow rates in the data center example would have immediately revealed discrepancies that would have likely pointed to the faulty equipment. However, a more cost effective approach would have been to simply benchmark the actual data center against its original design specification (as the author suggested) as part of a routine maintenance schedule.

Of course it is always worth remembering the golden rule of engineering: Use the level of complexity necessary to solve the problem, and no more.