Skip to content

external-references.md

Latest commit

 

History

History
168 lines (144 loc) · 11.6 KB

external-references.md

File metadata and controls

168 lines (144 loc) · 11.6 KB
Raw

External references — the prior art we build on

Cross-checks for our findings. Search this + the other KB files before doing fresh external research.

Preconditioner theory (why ILU/BJ lose, why AMG wins)

  • Saad, Iterative Methods for Sparse Linear Systems (2nd ed.) — canonical: ILU(0)/Jacobi give a constant-factor κ improvement but keep the O(h⁻²) asymptotics → CG iterations ~O(h⁻¹) = O(N^(1/3)) in 3-D; multigrid is mesh-independent (O(1) iterations, O(N) work).
  • "One-level PCG solvers deteriorate for medium-to-large problems while multigrid multi-level PCG is fast" — multiple AMG-PCG papers, e.g. An efficient AMG-PCG solver, A fast AMG-PCG solver. Validates our 7.1M result (ILU ~192 iters ≈ N^(1/3), GAMG 3–5).

GPU OpenFOAM pressure-solve (the win = GPU algebraic multigrid)

Ginkgo / OGL (our stack)

Our own upstream reports

  • intel/compute-runtime#922 — CR ≥26.14 multi-process zeInit abort on BMG-G31.
  • Ginkgo PR #2023 — lower_trs/upper_trs SYCL gap (merged 2026-06-02), unblocks ILU/IC apply.
  • OGL status / patches → ../logs/ogl-greole-consolidated-status.md, OGL issue #170.

Tuning & deeper sources (2026-06-17 research round)

  • Tsai, Beams, Anzt, "Three-Precision Algebraic Multigrid on GPUs", FGCS 2023 — doi/full text, OSTI PDF. Ginkgo's own AMG on H100/MI250X/Intel PVC: PGM size-2 aggregation + weighted-Jacobi smoother; AMG-CG iteration counts 10–359 (problem-dependent); W-cycle +12–60%; DP-SP mixed precision; skip FP16 for short-row pressure Laplacian on Intel (subgroup {16,32} → FP16 SpMV can be slower). Best GPU smoother = scalar Jacobi.
  • Notay, "Aggregation-Based AMG", ETNA 37 (2010) — PDF: unsmoothed aggregation is not grid-independent without smoothed aggregation or K-cycle Krylov acceleration → explains our ~13-iter floor with Ginkgo PGM.
  • Olenik et al., Matrix Repartitioning, arXiv:2510.08536 — PDF: ranks-per-GPU tuning; naive MPI oversubscription = ~140× slowdown; repartitioning up to ~10× on A100.
  • petsc4Foam + Hypre BoomerAMG, PRACE WP294 — PDF: the canonical BoomerAMG pressure config (strong_threshold 0.7 for 3D, HMIS, ext+i); 64M cavity 128 nodes: AMG-CG 79 s vs GAMG-PCG 553 s (scalability win).
  • NVIDIA AmgX configs — stock JSON configs, Poisson production config (barbagroup): PCG + CLASSICAL AMG, V-cycle, PMIS, D2, block-Jacobi, dense-LU coarse.
  • The AMG-resetup gotcha (AmgX 2.5× slower than GAMG) — SPUMA benchmark arXiv:2512.22215: pressure coefficients change each SIMPLE iter → AMG hierarchy can't be cached like GAMG.
  • Oliani/Polimi, GPU coupled OpenFOAM, arXiv:2403.07882 — PDF: cells/GPU win threshold (~1–5M min,

    10M ideal); LDU→CSR cached; LA drops from ~80% to ~20% of step on GPU.

Conflation warning: the "2.3× GAMG GPU speedup" sometimes seen online is RapidCFD (CUDA OpenFOAM fork) on Titan X, not OGL/Ginkgo. Both real OGL papers benchmark vs CPU PCG, not GAMG.

Intel-platform fit & FP64 / mixed precision (2026-06-17 research round)

See intel-platform-fit.md for the synthesis.

  • B70 FP64 (our own measurement): clpeak in Ginkgo #2013 → 1335 GFLOPS FP64, 530 GB/s (~1:8). Battlemage FP64 is native-rate-limited on XVE units, not Alchemist-style emulation. Alchemist had no native FP64 (Tom's Hardware). Compute-runtime FP64 policy / cl_khr_fp64: intel/compute-runtime FAQ. B580 ~909 GFLOPS clpeak: Phoronix.
  • We are the only documented consumer-Battlemage OGL/Ginkgo OpenFOAM user — our OGL #170, compute-runtime #922, Ginkgo #2013/#2015/#2018.
  • Classical RS-AMG merged to Ginkgo develop (CPU-only, unreleased): PR #1985, GPU-kernel draft PR #2034. Distributed MG since v1.8.0: PR #1269. Mixed-MG example: ginkgo/examples/mixed-multigrid-solver.
  • Mixed-precision iterative-solver consensus (FP64 outer + FP32 precond keeps full accuracy): Carson & Higham 2018 SISC; Bake/Carson/Ma 2025 arXiv:2510.11379; Abdelfattah et al. 2021 survey arXiv:2007.06674.
  • FP32 floor ~1e-6 (keep reductions in FP64): Neko/Nekbone Chen et al. 2025 arXiv:2503.02134. Pure FP32 fails for turbulent LES → OpenFOAM keeps the solve FP64: Brogi et al. 2022 arXiv:2209.06105.
  • FP16/short-row verdict (FP64→FP32 only ~2.33× at 7 nnz/row; index traffic dominates): Loe et al. 2021 arXiv:2105.07544; Ginkgo-on-Intel subgroups {16,32}: Tsai/Cojean/Anzt 2021 arXiv:2103.10116; FP16 range/squeezing: Higham/Pranesh/Zounon 2019 PDF.
  • FluidX3D on Intel Arc = excellent (FP32/FP16 LBM, B70 ~6750 MLUPs/s): FluidX3D README, Phoronix B70. Contrast: FP64 OpenFOAM-via-OGL is experimental/unsupported on consumer Arc.

Retraction logged: an earlier research pass hallucinated a citation (arXiv:2509.16081) for "OGL wires mixed precision only for Block-Jacobi" — that paper says no such thing; the claim rests on our own code reading (Preconditioner.hpp:172).

Where our work is genuinely new

The fundamentals above are established. Our novel contribution is the Intel Arc Pro B70 (Battlemage) + SYCL/Ginkgo/OGL combination: the CR driver multi-process bug, the Ginkgo SYCL preconditioner bugs and their 2.0 fixes, the find_blocks distributed-path failure, and the first measured BJ/ILU/ISAI/Multigrid numbers on this hardware.

Research sources (2026-06-18 deep dive) — the prior art we build on

AMG hierarchy reuse (the #1 lever):

  • NVIDIA AmgX structure_reuse_levels + open coarse-sparsity-skip: AMGX#127
  • AMGCL partial reuse (−40–200% setup): Demidov arXiv:2108.02054
  • Trilinos MueLu reuse: RAP (3.5×, problem-dependent): OSTI 1364816
  • PETSc-GAMG -pc_gamg_reuse_interpolation: PETSc docs
  • Ginkgo has NO reuse API: issues #1681, #1158
  • OpenFOAM cacheAgglomeration (caches map, re-sums coarse ops): OpenFOAM-dev GAMGSolver.C

Mixed / single precision (validates our single-precision win):

Smoother (the #2 lever, deprioritised by our 72%-setup finding):

OpenFOAM-on-GPU ecosystem:

Our contribution = the Intel-Battlemage + SYCL/Ginkgo/OGL combination, not the linear-algebra fundamentals above. See gpu-comparison.md for hardware context.