PaperlayerView exact revision on arXiv

Source-linked AI summary

Recent progress and challenges in exploiting graphics processors in computational fluid dynamics

Kyle E Niemeyer, Chih-Jen Sung

arXiv:1309.3018v1physics.flu-dynphysics.comp-ph

TL;DR

High-fidelity CFD simulations face growing computational demands, particularly for dense grids and detailed reactive chemistry. This review surveys GPU programming, optimization, and CFD solvers, using case studies to compare GPU and CPU performance. The case studies show substantial gains from GPU-specific optimization, while the review identifies algorithm redesign and broader GPU execution as continuing challenges.

  • Problem

    High-fidelity CFD simulations require costly computing resources as dense grids and detailed reactive chemistry increase computational demands.

    Source: §1 · p. 1

  • Method

    The paper surveys GPU programming and performance considerations, CFD solvers across flow regimes, LBM implementations, and CPU–GPU case studies.

    Source: §1 · p. 2

  • Results

    Nearly 19-fold improvement over the naive GPU implementation was achieved through GPU-specific optimization, and at mesh sizes of 1024^2 and above the GPU solver ran up to about 10 times faster than the single-core CPU solver in double precision.

    Source: §3.1.2 · p. 9

  • Takeaways & Limitations

    GPU acceleration benefits from moving more calculations onto the GPU and redesigning numerical algorithms for many-core execution.

    Source: §5 · pp. 23, 25

    Reactive-flow strategies that split chemistry on the GPU and transport on the CPU require repeated CPU–GPU transfers and incur corresponding latency.

    Source: §5 · p. 24

Abstract

from arXiv · show

The progress made in accelerating simulations of fluid flow using GPUs, and the challenges that remain, are surveyed. The review first provides an introduction to GPU computing and programming, and discusses various considerations for improved performance. Case studies comparing the performance of CPU- and GPU- based solvers for the Laplace and incompressible Navier-Stokes equations are performed in order to demonstrate the potential improvement even with simple codes. Recent efforts to accelerate CFD simulations using GPUs are reviewed for laminar, turbulent, and reactive flow solvers. Also, GPU implementations of the lattice Boltzmann method are reviewed. Finally, recommendations for implementing CFD codes on GPUs are given and remaining challenges are discussed, such as the need to develop new strategies and redesign algorithms to enable GPU acceleration.

1 Introduction

Growing CFD workloads make high-fidelity simulations costly, especially when resolving high-Reynolds-number flows or modeling detailed reactive chemistry. This survey introduces GPU computing, reviews GPU-accelerated CFD methods, and discusses optimization, recommendations, and remaining challenges.

1 Introduction

  • High-Reynolds-number flows require denser grids, while detailed reactive chemistry can raise computational demands by another order of magnitude.These demands can make high-fidelity simulations inaccessible to many industrial and academic researchers.Source: §1 · p. 1
  • GPUs offer hundreds to thousands of relatively simple cores, contrasting with the four to eight cores common in top-end CPUs described in the survey.The paper presents this many-core parallelism as relevant to scientific computing.Source: §1 · pp. 1–2
  • Parallel computing suits data-independent tasks such as cell-flux and finite-difference calculations, while iterative methods may remain serial even when each iteration contains parallel work.The key distinction is whether tasks can operate on data independently.Source: §1 · p. 2
  • The survey covers GPU computing and optimization, Laplace and incompressible Navier–Stokes case studies, CFD solvers for laminar, turbulent, and reactive flows, and GPU implementations of LBM.It also discusses recommendations and remaining challenges for GPU-accelerated CFD.Source: §1 · p. 2
  • The surveyed approaches are presented as applicable beyond GPUs to future many-core architectures, with OpenCL designed for heterogeneous computing platforms.The paper notes that the same OpenCL programs written for GPUs should be usable on whichever many-core standard is adopted.Source: §1 · p. 2

2 GPU Computing

The section introduces GPUs as throughput-oriented processors and outlines programming models for mapping independent work onto their many threads. It then describes performance considerations centered on memory access, thread execution, and instruction and precision trade-offs.

2 GPU Computing

  • GPUs prioritize throughput over latency, and the newest models described offer more than an order of magnitude higher theoretical peak performance than multicore CPUs, though recent CPU data were unavailable.Figure 1 compares theoretical peak performance in GFLOPS over the past decade, separately for single and double precision, on a logarithmic scale.Source: §2 · p. 2, Figure 1 · p. 3

2.1 Programming GPUs

  • CUDA kernels replace loops with concurrent threads for independent operations, while data must be allocated on the device and explicitly transferred between host and device.The vector-addition example stores vectors in global memory and launches threads to add elements independently.Source: §2.1 · p. 4, Figure 2 · p. 5
  • OpenACC directives identify parallel code regions and can accelerate compatible existing code with little source modification, but convenience may come with degraded performance and limited applicability.The described vector-addition example adds a directive before the loop; CUDA or OpenCL ports require rewriting the application.Source: §2.1 · p. 4, Figure 3 · p. 5

2.2 GPU performance considerations

  • GPU performance depends on choosing memory types carefully: global-memory access is slow, and a compute-to-global-memory-access ratio near one indicates memory-latency limitation.The section recommends reducing excess global-memory use with faster GPU memory types.Source: §2.2 · p. 6
  • Threads execute in warps of 32 and diverging control paths can require multiple passes, while consecutive warp accesses can be coalesced into a single global-memory operation.The section also describes loop unrolling as a way to remove branch and counter-update instructions.Source: §2.2 · pp. 6–7
  • Hardware-accelerated transcendental functions are faster but limited to single precision in the described CUDA setting, with slightly reduced accuracy relative to software versions.The passage reports maximum ulp errors of 2 for software exp(x) and 2 + floor (|1.16x|) for hardware __exp(x).Source: §2.2 · p. 7

3 Case studies

The case studies compare CPU, CUDA, and OpenACC implementations on Laplace heat conduction and lid-driven cavity flow. GPU-specific optimization substantially improves the native GPU solver, while performance advantages over CPUs and OpenACC vary with mesh size.

3 Case studies

  • The case studies compared single-core CPU, six-core OpenMP, CUDA GPU, and OpenACC GPU solvers on an NVIDIA Tesla C2075 with an Intel Xeon X5650 host.CPU, OpenMP, and OpenACC versions used compiler directives or CPU code; CUDA used native GPU code.Source: §3 · p. 7, §3.1.1 · p. 8

3.1.1 Methodology

  • The Laplace case models heat conduction in a square plate with a finite-volume discretization, solved iteratively using red-black Gauss–Seidel with successive over-relaxation.Red-black updates alternate between cells that depend on the opposite color, permitting parallel updates within each color.Source: §3.1.1 · pp. 7–8

3.1.2 Results

  • In Laplace, OpenACC’s nearly fivefold small-grid slowdown approached zero at the largest grids; in cavity flow, it was 1.3 times slower than native GPU code at the largest size.For the cavity solver, OpenACC ran nearly four times slower than native GPU code at smaller problem sizes.Source: §3.1.2 · p. 9, §3.2.2 · pp. 12–13

3.2.1 Methodology

  • The cavity-flow study used a finite-difference incompressible Navier–Stokes solver on a uniform staggered grid, with lid-driven cavity boundary conditions.The performance study integrated a single initial time step for each mesh size, in double precision.Source: §3.2.1 · pp. 9, 11, 12

3.1.2 Results

  • GPU-specific optimization raised Laplace solver performance by nearly 19-fold over the naive implementation, using coalesced access, separate red/black arrays, and shared-memory residual reductions.The performance comparison covers a wide range of mesh sizes and double-precision calculations.Source: §3.1.1 · p. 8, §3.1.2 · p. 9, Figure 4 · p. 10
  • At mesh sizes of 1024^2 and above, the Laplace GPU solver outperformed CPU versions, reaching up to 10 times the single-core and 4.6 times the six-core speed.These comparisons concern double-precision calculations.Source: §3.1.2 · p. 9, Figure 5 · p. 10

3.2.1 Methodology

  • The cavity GPU implementation kept simulation arrays on the device, with transfers for SOR stopping criteria and maximum velocities; timing included initialization, transfers, and final outputs.Shared memory reduced each block’s reduction result to one value transferred back to the CPU.Source: §3.2.1 · p. 11

3.2.2 Results

  • At 2048^2 cells, the optimized GPU cavity solver was 8.1 times faster than one CPU core and 2.8 times faster than six OpenMP cores.Below 128^2 cells, both CPU solvers ran faster than either GPU solver.Source: Figure 6 · p. 12, §3.2.2 · p. 12

4 GPUs in computational fluid dynamics

This section surveys GPU acceleration in CFD across laminar, turbulent, reactive-flow, and lattice Boltzmann solvers. It highlights their parallelism and performance potential, alongside constraints involving chemistry stiffness, memory movement, and precision.

4.1 Laminar flow

  • The first GPU-accelerated unstructured-grid solver used memory coalescing and boundary-element ordering, achieving average speedups of about 32 and 9 versus one- and four-core CPU codes.It simulated three-dimensional compressible, inviscid flow, including supersonic flow over an airfoil and a missile.Source: §4.1 · p. 15
  • Up to 71 times faster than a serial CPU core, the GPU-based CESE solver handled shock-tube condensation; a separate SHLL solver ran more than 60 times faster on larger meshes.CESE uses shared memory and extra boundary threads to handle data needed across thread blocks. SHLL reshapes flux calculations into a vector-split form suited to GPU parallelism and keeps the simulation on the GPU after initialization.Source: §4.1 · p. 16

4.2 Turbulent flow

  • GPU acceleration for turbulent flow spans whole-step and DNS solvers: asynchronous transfers improved performance by up to 40%, while eight GPUs ran about nine times faster than eight quad-core CPUs.The whole time-step loop ran on the GPUs, with CPUs driving the simulation and transferring information between domain blocks. The DNS solver’s speedup increased from about 12 times on a 128 × 32² mesh to nearly 16 times on a 512 × 128² mesh; the subsequent LES solver had no equivalent CPU performance comparison.Source: §4.2 · pp. 16–17

4.3 Reactive flow

  • Reactive-flow simulations need accurate, efficient computation to support engine and combustor design, because global reaction mechanisms cannot capture pressure dependence or pollutant and soot-precursor concentrations.The passage identifies pressure dependence as vital for high-compression-ratio engines and emissions prediction as important under increasingly stringent regulations.Source: §4.3 · p. 19
  • Detailed reactive-flow chemistry is costly because stiffness demands specialized integration and realistic fuel mechanisms can reach thousands of species, while GPU acceleration remains an emerging approach.The survey notes a gasoline surrogate mechanism of about 1550 species and 6000 reactions, and a biodiesel surrogate mechanism of almost 3300 species and over 10,000 reactions.Source: §4.3 · p. 19
  • GPU rate evaluation in S3D sped up ethylene chemistry about 15× in single precision and 9× in double precision; GPU integration reached up to 22× for mechanisms over 1000 species but could match or trail CPUs below 100 species.Spafford et al. kept CPU time integration, requiring four GPU rate-evaluation calls per Runge–Kutta step; Shi et al. used GPU reaction-rate calculation and matrix inversion.Source: §4.3 · p. 19
  • For a 2877-species biodiesel mechanism, Shi et al. achieved nearly 20× speedup without dynamic reduction but only 2× with it, using the CPU below 300 species and GPU above that threshold.With dynamic reduction, mechanisms were sufficiently small during most of the simulation that GPU acceleration might not be needed.Source: §4.3 · p. 19
  • GPU chemistry strategies ranged from concurrent nonstiff integration reaching 75× speedup to hybrid stiff/nonstiff integration at 11–46× and a combined GPU transport-and-chemistry solver reaching 40× with first-order accuracy [59].Niemeyer et al. performed the full Runge–Kutta step on the GPU to reduce transfers and allowed CPU transport to proceed concurrently; Shi et al. serialized CPU transport with stiff chemistry.Source: §4.3 · pp. 20–21
  • Levesque et al. ported production S3D using OpenACC and restructuring that enabled overlap and improved CPU performance, while Sankaran accelerated turbulent-combustion chemistry by solving unsteady laminar flamelet equations on GPUs.Levesque et al. reported around 1.5× speedup with one 16-core CPU plus GPU versus OpenMP on dual 16-core CPUs; Sankaran’s approach used three concurrent GPU levels, from reaction rates to multiple flamelets.Source: §4.3 · p. 21

4.4 Lattice Boltzmann method

  • LBM’s local particle movement and collision operations suit parallelism; early GPU implementations reached up to 15× speedup on a single-core CPU comparison and 4.6× on 30 GPUs versus 30 CPUs.LBM can simplify treatment of complex flows and boundaries and is less computationally expensive for high-Knudsen-number flows.Source: §4.4 · p. 22
  • CUDA-era LBM optimizations achieved nearly two orders of magnitude speedup, over 28× versus a quad-core CPU, and 92–130× versus a single-core CPU for single-precision cavity simulations.Reported techniques included raising multiprocessor occupancy, halving memory requirements, coalescing memory access, and merging collision and propagation steps in shared memory.Source: §4.4 · p. 22

4.5 Summary of findings

  • Table 1 compiles reported GPU-CFD optimization factors; precision choices should balance accuracy and performance, with one study finding single-precision GPU results close to CPU results up to five or six digits.The survey notes that newer GPUs offer nearly CPU-like relative double-to-single precision performance, while some applications may not require double precision.Source: Table 1 · p. 23, §4.5 · p. 23

5 Concluding remarks

The review reports roughly an order-of-magnitude GPU performance improvement over multicore CPUs, while emphasizing algorithm redesign and unresolved challenges for complex-flow solvers. It recommends keeping more calculations on the GPU to reduce transfers and calls for stronger CPU comparisons.

5 Concluding remarks

  • GPU implementations generally improved performance by around an order of magnitude over multicore CPU versions.The case studies also demonstrate systematic GPU-code optimization and the importance of redesigning numerical algorithms, even for simple applications.Source: §5 · p. 23
  • GPU comparisons should use parallel multicore CPU versions rather than only serial single-core baselines, and should consider performance normalized by hardware cost and power.The review notes that OpenMP or MPI parallelization is common in scientific computing.Source: §5 · p. 24
  • Successful GPU strategies include coalesced global-memory access, shared-memory reductions, asynchronous transfers, and performing possible calculations on the GPU.The passages associate coalesced access with performance improvements of an order of magnitude, theoretically up to 32 times.Source: §5 · p. 24
  • Reactive-flow approaches that run chemistry on the GPU and transport on the CPU incur repeated transfers, and no practical GPU solver for stiff chemistry had been demonstrated.The review identifies migrating all calculations to the GPU as a question for further investigation.Source: §5 · p. 24
  • GPU two-phase incompressible-flow solvers using level-set methods had been demonstrated in only two studies from one group; other complex models such as multiphase flows remained undemonstrated.The review notes that Lagrangian schemes for sprays or particles stand to benefit from GPUs because particle and droplet tracking is data-independent.Source: §5 · p. 24
  • Overall speedup depends on the parallelizable share: 50% GPU-accelerated work yields 2S/(1+S), and full advantage requires most of the application to be parallelizable.For Niemeyer et al., reactive source terms accelerated by a factor of 75 could yield an overall speedup of about 43 times for larger grids.Source: §5 · p. 24
  • New strategies and algorithms designed for massively parallel processors are needed because sequentially designed codes can benefit only so far from incremental porting.Reactive-flow solvers using complex implicit integration for stiff chemistry cannot simply be ported to GPUs.Source: §5 · pp. 24–25
Loading 1309.3018v1…