Convergent Science and CoreWeave Test GPU Scaling for Turbulence Simulation

Why turbulence simulation drives demand for compute

CoreWeave's write-up opens with the argument that turbulence remains an unsolved problem that matters for cooling microprocessors, automotive aerodynamics, combustion engines, nuclear reactors, marine vessels and manufacturing. It cites a figure that roughly 30% of worldwide energy consumption is used to overcome drag in transportation, with turbulence as the primary cause. Better understanding of turbulence, it says, could cut global CO₂ emissions and save fuel costs.

The Navier-Stokes equations that govern fluid flow have analytical solutions for only a handful of simple cases. For everything else, engineers use computational fluid dynamics (CFD), which solves the equations numerically. Accuracy depends on the mesh, the numerical methods and the physical models chosen. Original equipment manufacturers (OEMs) therefore run larger and more detailed simulations, and the computational demand rises with them.

The test setup: DNS on two classes of NVIDIA hardware

The project had two aims: to validate the accuracy of the CONVERGE GPU solver against a well-established test case, and to measure how it scales on two different hardware classes, NVIDIA RTX PRO 6000 Blackwell Server Edition and NVIDIA HGX B200.

The team chose direct numerical simulation. The industry workhorse is Reynolds-Averaged Navier-Stokes (RANS), which uses a turbulence model to estimate small-scale motion and accepts some error in exchange for an affordable computational load. DNS removes the model and computes every scale directly. The cost is very small cells and very short time steps, so the work grows in both space and time. According to the authors, if a cluster holds up under the hardest workload in CFD, everyday cases have room to spare.

Every run used the same classical case: turbulent flow losing energy with time in a three-dimensional rectangular space. The base case had about 16.8 million cells.

• RTX PRO Server weak scaling: 2 GPUs with about 16.8 M cells, 4 GPUs with about 33.6 M, and 8 GPUs with about 67.1 M.
• RTX PRO Server strong scaling: 2, 4 and 8 GPUs on about 67.1 M cells.
• HGX B200 weak scaling: 1 GPU with about 33.6 M cells, 2 GPUs with about 67.1 M, and 4 GPUs with about 134.2 M.
• HGX B200 strong scaling: 8, 12 and 16 GPUs on about 268.4 M cells.

Outside the matrix, the team extended the 512³ case four times in one direction to 536 million cells and ran it on two HGX B200 instances, or 16 Blackwell GPUs. It is not part of the scaling study because it shows how far the system goes, not how efficiently it scales.

Strong and weak scaling, intranode and internode

The article separates two kinds of scaling. Strong scaling keeps the case fixed and adds GPUs to finish sooner. Weak scaling grows the case and the GPU count together, so a bigger job takes about as long as the smaller one. The authors lead with weak scaling because OEMs want larger, more detailed cases rather than faster versions of existing ones. Strong scaling serves as a check on how much speed can be bought for an existing case. They note that real scaling always falls short of the ideal.

They also distinguish where the GPUs sit. Intranode means GPUs inside one server, connected by PCIe on the RTX PRO Server or by NVIDIA NVLink on the HGX B200, which is considerably faster. Internode means GPUs across servers, connected here by 400 Gb/s NVIDIA Quantum-2 InfiniBand. The authors say this difference is why published scaling numbers are so often incomparable, since the result depends on GPU memory, the link inside a server or the fabric between servers.

What it means for sizing GPU CFD jobs

The article's practical advice for anyone buying GPU capacity for simulation is that memory decides whether a case runs at all, while FLOPS only decide how fast it runs. Cell count shows how big a job is but not how much memory it needs. That depends on the physics switched on, such as the chemical species tracked in a combustion case, and on numeric precision, since double precision doubles the stored values. The solver method also matters.

The authors caution that DNS carries fewer equations than the RANS models used in daily industry work, so a production case with the same cell count is expected to need more memory. The source text provided ends partway through this discussion of sizing.