GPU CFD Solvers: When the Switch Pays Off, and What You Give Up

Two runs, one decision

The GPU run finished before lunch. The same case on the CPU cluster sat in the queue overnight and took most of the next morning. The drag coefficients agree to the third digit, the outlet temperature differs by half a degree, and someone in the meeting asks why the team still runs anything on CPUs.

It is a fair question. There is a duller one that should come first. Which of the two answers would you sign?

A GPU CFD solver pays off when three things are true: the case fits in GPU memory, it uses only models the GPU solver supports, and it is large enough that the speed-up beats the higher hourly price of the hardware. This article shows how to check each one before you buy or rent anything, what the GPU solver does differently from its CPU sibling, and the afternoon of verification I would spend before trusting it with a decision.

What actually runs on the GPU?

Two quite different things are sold under the same three letters.

• GPU-native solvers move the whole iteration onto the card: assembly, linear solve, gradients, the lot. Fluent’s GPU solver works this way, and other commercial codes now offer GPU-native solvers too. This is where the large speed-ups come from.
• GPU offloading keeps the solver on the CPU and sends one expensive part, usually the pressure linear system, to the card. It helps, and the rest of the loop still runs at CPU speed.

The first kind deserves a mental adjustment. Fluent’s GPU solver reads the same case file as the CPU solver, and it is a separate implementation. It runs 3D cases only. It offers one gradient scheme, Least Squares Cell Based. Its Linear pressure scheme differs from the CPU version, and Ansys says it is more accurate on nonuniform meshes. It runs in single or double precision. Each of these is documented, and together they make the GPU run a second numerical setup of your problem, close to the first and slightly different from it.

That is the whole argument of this article, so I will make it once. A new numerical setup earns trust the way every setup does, by agreeing with a reference on a case you understand.

How much faster is it, honestly?

Speed-up figures are like fuel economy figures. They are real, they were measured, and they were obtained on a route you will never drive.

SimuTech Group ran a steady conjugate heat transfer case of about 16 million cells in Fluent and compared one NVIDIA RTX 6000 card with CPU nodes. Against 16 cores the GPU was about 2.5 times faster than the AMD processors and 3.5 times faster than the Intel ones. Against 96 and 128 cores the CPUs won. One mid-range card against a modest CPU job is a clear win; the same card against a properly sized CPU job is a loss.

Vendor benchmarks with several GPUs and meshes of hundreds of millions of cells report much larger speed-ups. Smaller cases gain less, because the parts of a run that do not parallelise well take a larger share of the time.

Both kinds of result are honest, and they answer different questions. Whenever you see a speed-up, ask what the baseline was, how big the mesh was and which physics was switched on. One GPU against 16 cores and eight GPUs against a thousand are different claims that happen to share a headline.

Will my case fit?

GPU memory is the hard wall. A CPU job that runs short of memory gets slow; a GPU job that runs short of memory does not start.

The Fluent documentation gives a planning figure: about 1 GB of GPU memory per million cells for a turbulent case on a hexahedral mesh in single precision. Double precision needs 50% more and a polyhedral mesh 20 to 40% more. Species, radiation and other models add their own share, and the exact number depends on the case.

Worked example. A turbulent case on a polyhedral mesh of 40 million cells, in double precision:

On an 80 GB card that is somewhere between a tight fit and no fit at all, before you add a single species. The same mesh in single precision needs 48 to 56 GB and fits with room to spare. The precision setting is a decision about memory, cost and accuracy at once, and it deserves a minute of thought before it becomes a default.

Is single precision good enough?

Usually, for the quantities engineers report. Single precision carries about seven significant digits. That is plenty for a velocity field or a pressure drop of a few hundred pascals. It becomes marginal when the answer is a small difference between two large numbers: a few pascals of pressure drop on top of ten bar, a tenth of a degree across a solid at 400 K, a small net heat flux between two large ones.

Solvers already protect you from the most common case by working with gauge pressure relative to an operating pressure. Set that operating pressure sensibly and most of the risk goes away. For the rest, the check later in this article tells you, on your own case, whether precision matters.

One more effect shows up in practice. In the SimuTech comparison the GPU ran in single precision and the CPU in double, and the GPU needed more iterations to converge, with almost identical temperatures at the end. So compare wall-clock time to a converged answer. A faster iteration that needs twice as many of them is a smaller win than it looks.

Is a GPU CFD solver cheaper per case?

The arithmetic is simple, and it is rarely done.

Here C is the cost of one case, r the hourly rate of the hardware, t the wall-clock time to a converged answer, and S = t_CPU / t_GPU the speed-up measured on your case.

Worked example, with made-up rates. Suppose a GPU node costs four times as much per hour as the CPU allocation your team normally uses. Then the GPU must be at least four times faster on your case just to break even. At 2.5 times faster it costs more per case and delivers the answer sooner. At 8 times faster it costs half as much and delivers sooner. Both can be the right choice. Faster and cheaper are separate questions, and a project that is late will happily pay for the first.

Three costs hide outside the formula. Queue time, which is often longer than solve time on a shared cluster. How your software licence counts GPU hardware, which is worth checking with your vendor before you plan around it. And the one-off cost of verifying the GPU setup for each family of cases, which is the subject of the next two sections.

What does the GPU solver do differently?

Ansys publishes a limitations page for the Fluent GPU solver with each release. Reading it for 2025 R2 and 2026 R1 is an education. A selection, with what each item does to you:

• Pressure level in closed incompressible regions. In a closed, incompressible, steady region the GPU solver keeps the initial volume-averaged pressure, while the CPU solver fixes pressure to zero at a reference cell. The fields are offset, and Ansys notes this can affect force integrals on bodies that are not closed surfaces. A constant shift in lift between the two solvers points here first.
• Mass flow sign at non-conformal interfaces. Mass flow monitors at such interfaces can print the wrong sign. The mass balance looks appalling while the flow is fine.
• Surface mass flow reports. The 2025 R2 page on supported features says the GPU solver reports mass flow rate correctly only on interior zones and reports the others as zero. An outlet showing 0 kg/s is a reporting limitation. The duct is fine.
• Dynamic pressure at stationary walls. The monitor correctly shows zero, while reports used for output parameters show an incorrect nonzero value.
• Turbulent viscosity ratio clipping. The ratio is clipped at the same limit as on the CPU, with no message to the console. The CPU solver tells you when it clips. The GPU solver keeps it to itself.
• Initialisation. Hybrid initialisation with far-field pressure boundaries may fail to converge or give unphysical outflow, and Ansys recommends standard initialisation. Starting a transient run from a steady solution does not work correctly when the energy equation is solved; a workaround is documented.
• Restarts across solvers. A GPU solution with a compressible material and the energy equation will not restart correctly on the CPU solver.
• Unsupported settings in old case files. Models the GPU solver does not support are hidden in the interface or marked Unsupported. Set through the text interface, they are reported as ignored, converted or unsupported. A CPU case file that relied on one of them still runs, and the transcript is the only place that tells you what happened to it.

The list also moves. The 2025 R2 page said that supersonic flow at pressure inlets, velocity inlets and pressure outlets is treated as subsonic. The 2026 R1 page no longer lists that item, and it adds others, such as a limit of 20 species and the incompatibility of the flamelet generated manifold model with porous media and moving frames.

None of this is a scandal. Every item is written down, which is more than can be said for some CPU solver behaviour I have met. The trouble is that most of us read release notes the way we read the terms and conditions of a phone contract. Read the page for the exact version you run, every time it changes.

How I would check a GPU result

One afternoon per family of cases, repeated when the solver version or the physics changes.

1. Pick a reduced case from the family. Same physics, same mesh style, same boundary condition types, small enough to run on both solvers in a few hours.
2. Run it on the CPU in double precision to a tight convergence. Monitor the quantities you will report and check the mass and energy balances, as for any study.
3. Run it on the GPU with the settings you will use in production, including the precision. Testing double precision and then running single precision tests the wrong thing.
4. Read the GPU transcript for anything ignored, converted or unsupported.
5. Compare the quantities of interest, the balances and one line profile through the region that matters.
6. Judge the difference against your discretisation error. Two solvers never agree exactly, so zero is the wrong yardstick.

The last step is the one people skip. The question is whether the two solvers disagree by more than you already accept from the mesh.

Worked example. Suppose your mesh study gave a grid convergence index of 3% on pressure drop. If the GPU and CPU results differ by 0.4%, the difference is noise next to the uncertainty you already report, and the GPU setup is fine for that family. If they differ by 2.5%, the solver choice is almost as large as your whole mesh uncertainty, and you need to know why before you use it: precision, the pressure scheme or an ignored setting. The numbers are illustrative; the logic is the point.

If you have never done a mesh study on that family, the GPU comparison has nothing to stand on, so do that first. The worked example in the mesh independence article on this blog takes about the same afternoon.

Common mistakes, as they look on screen

• A zero at the outlet. The GPU run reports no mass leaving the domain. It is a reporting limitation; check with an interior surface before you rebuild the mesh.
• A constant offset in force or pressure between GPU and CPU runs of a closed incompressible case. It is a difference in pressure level, and it matters for forces on open surfaces.
• “It converged in half the time”, quoted per iteration while the iteration count doubled. Measure the time to a converged quantity of interest.
• A 16-core baseline in the business case. If the CPU job you actually run uses 128 cores, compare with that.
• Running out of memory at initialisation on a polyhedral mesh sized with the hexahedral rule of thumb. Add the 20 to 40%.
• Silent model changes from an old case file. Read the transcript.

What I would do

I would move a case family to the GPU when the cases are large, the physics sits inside the supported list for my version, and the work involves many runs: design sweeps, transient airflow, conjugate heat transfer on big assemblies, scale-resolving runs that were unaffordable before. Under those conditions the speed changes what you can study, which matters more than the cost per case.

I would stay on the CPU for one-off studies with unusual physics, for cases that need models outside the supported list, for small meshes where a decent CPU allocation already returns the answer in an hour, and for any workflow that restarts cases across the two solvers.

And I would rent before I buy. One GPU node for a day, the afternoon check above on a case I know well, and I would have my own speed-up figure, measured on my own route.

If you already run on GPUs and want a second pair of eyes on whether the results match what your CPU workflow used to give, that is a model review, one of the smaller engagements described on the services pages.