---
title: 'gCAMB: GPU-Accelerated CAMB for CMB Analysis'
url: https://www.emergentmind.com/topics/gcamb
type: topic
---

# gCAMB: GPU-Accelerated CAMB for CMB Analysis

gCAMB is a GPU-accelerated port of CAMB for the calculation of theoretical angular power spectra in Cosmic Microwave Background parameter inference. It is presented as a version of the CAMB code ported to GPUs that preserves all the features of the original CPU-only code, while offloading the most computationally intensive modules to the GPU in order to accelerate the generation of power spectra, save computational time, halve power consumption in high-accuracy settings, and facilitate the creation of extensive training sets for robust cosmological analyses [2509.25110].

## 1. Problem setting and scope

Inferring cosmological parameters from Cosmic Microwave Background data requires repeated and computationally expensive calculations of theoretical angular power spectra using Boltzmann solvers like CAMB. The paper identifies this as a significant bottleneck, particularly for non-standard cosmological models and the high-accuracy demands of future surveys. It also contrasts this approach with emulators based on deep neural networks, which can accelerate the process by several orders of magnitude but first require large, pre-computed training datasets that are costly to generate and model-specific [2509.25110].

Within that setting, gCAMB is positioned as a direct acceleration of CAMB itself rather than as an emulator. The stated objective is not to alter the physical calculation, but to port the expensive part of the existing workflow to GPU hardware while preserving compatibility with the original code base. This suggests a design aimed at reducing the computational bottleneck without introducing the model-specific training burden associated with neural-network surrogates.

## 2. Computational design and numerical formulation

The targeted module is only the line-of-sight projection, identified as “SourceToTransfers” in `CAMBmain`. This routine, for each wavenumber mode $q$ and each multipole $\ell$, accumulates integrals of the oscillatory source functions against spherical Bessel kernels. By contrast, the ODE integrator that computes the source functions $S_T(q,\tau)$ and $S_P(q,\tau)$ remains on the CPU unchanged, and primordial spectra and eigenmode solvers are likewise untouched [2509.25110].

The port uses OpenACC directives. The core multipole-time loops are enclosed in a single accelerator data region; inputs such as $\tau$, $S_X$, and Bessel-kernel tables are copied in once, while the transfer functions $\Delta_\ell^X(q)$ are copied back at the end. Coarse-grain parallelism (`gang`) is over the outer $q$-loop, and fine-grain parallelism (`vector`) is over $\ell = 1 \ldots \ell_{\max}$ and, nested inside, over the line-of-sight sampling index $n = n_{\min} \ldots n_{\max}$. The mapping is described as natural to CUDA: each gang corresponds to a CUDA block, and each vector lane to a CUDA warp or set of threads. Shared versus global memory management for Bessel-kernel lookup tables is delegated to the compiler [2509.25110].

The numerical kernel is explicitly described as preserving Seljak & Zaldarriaga’s line-of-sight integrals:

$$
\Delta_\ell^T(q)=\int d\tau\, S_T(q,\tau)\,\phi_\ell[q(\tau_0-\tau)],
$$

$$
\Delta_\ell^E(q)=\int d\tau\, S_P(q,\tau)\,\epsilon_\ell[q(\tau_0-\tau)].
$$

The implementation discretizes $\tau \to \eta_n$ and rewrites each transfer function as

$$
\Delta_\ell^X(q)\approx\sum_{n=n_{\min}}^{n_{\max}} S_X(q,\eta_n)\,K_\ell[q(\tau_0-\eta_n)]\,\Delta\eta_n.
$$

The paper states that all $\ell$ and $n$ loops are simply vectorized on the GPU, so no novel algorithmic reformulation was required—only a relocation into GPU address space with minimal data movement. A plausible implication is that gCAMB’s performance gains arise primarily from hardware utilization and loop-level parallelism rather than from changes to the mathematical structure of the Boltzmann calculation.

## 3. Runtime characteristics and numerical fidelity

The reported benchmarks use 32 cores of an Intel Xeon Platinum 8358 (2.6 GHz) for CPU-only runs and one NVIDIA A100 on the Leonardo Tier-0 EuroHPC system for GPU runs. gCAMB was built with NVIDIA’s `nvfortran 24.5` with OpenACC, while CPU-only CAMB was built with GNU Fortran 8.5. The paper defines three accuracy settings through $(\texttt{accuracy\_boost}, \texttt{l\_sample\_boost})$: Low $=(1,1)$, Medium $=(3,20)$, and High $=(3,50)$. All runs compute $\ell_{\max,\mathrm{scalar}} = 11000$ and $\ell_{\max,\mathrm{tensor}} = 1500$ [2509.25110].

The end-to-end runtimes reported for “All [s]” are as follows.

| Accuracy | Method | Total [s] |
|---|---:|---:|
| Low | CAMB single core (serial) | 26.8 |
| Low | CAMB OpenMP (32 thr) | 1.56 |
| Low | gCAMB (GPU+CPU, 32 thr) | 1.86 |
| Medium | CAMB single core | 588.2 |
| Medium | CAMB OpenMP (32 thr) | 32.2 |
| Medium | gCAMB (GPU+CPU, 32 thr) | 16.8 |
| High | CAMB single core | 6246.6 |
| High | CAMB OpenMP (32 thr) | 329.9 |
| High | gCAMB (GPU+CPU, 32 thr) | 54.0 |

The paper further reports speed-up factors relative to serial single-core CAMB. For the `SourceToTransfers` kernel alone, the speed-up reaches up to approximately $10\times$ versus OpenMP-32 and approximately $180\times$ versus serial in the High-accuracy case. End-to-end, High-accuracy runs go from approximately $329.9\,\mathrm{s}$ on 32 CPU threads to $54.0\,\mathrm{s}$ on GPU, corresponding to approximately $6.1\times$ speed-up; versus serial the figure is approximately $116\times$ [2509.25110].

Numerical accuracy is evaluated by comparing gCAMB and CAMB spectra for TT, TE, EE, and BB up to $\ell = 11000$. The reported fractional differences $\Delta C_\ell / C_\ell$ are typically $\mathcal{O}(10^{-5}\text{--}10^{-6})$, always $\ll 10^{-4}$. In every multipole bin, $|\Delta C_\ell|$ is stated to be at least $5\times$ below full-sky cosmic variance $\sigma_{\mathrm{CV}}(\ell)$, and the paper therefore characterizes the differences as fully negligible for inference [2509.25110]. This addresses a central concern for accelerated Boltzmann solvers: the implementation is described as materially faster without introducing numerically relevant distortions at the power-spectrum level.

## 4. Power consumption and efficiency

The energy measurements are reported on a test machine consisting of an NVIDIA RTX 6000 Ada Generation and a dual AMD EPYC 9224 system using 32 threads. For a High-accuracy run, CPU-only CAMB with 32 threads drew $61\,283\,\mathrm{J}$, whereas gCAMB using CPU+GPU drew $33\,042\,\mathrm{J}$ [2509.25110].

These measurements imply that gCAMB uses approximately $54\%$ less energy in high-accuracy settings. The measurement tools are specified as `perf` for CPU and `nvidia-smi` for GPU. The paper also notes a trade-off at low accuracy: GPU “warm-up” overhead of approximately $0.2\,\mathrm{s}$ can offset the benefits. For medium and high accuracy, however, the lower power-time product is presented as clearly favorable [2509.25110].

This operational profile suggests that gCAMB is most advantageous in regimes where line-of-sight projection dominates wall-clock time. It is therefore particularly aligned with demanding survey settings and bulk generation workloads rather than with very short, low-accuracy runs.

## 5. Pipeline compatibility and dataset generation

gCAMB is described as a drop-in replacement that preserves all of CAMB’s input/output and FORTRAN modules except for the offloaded line-of-sight integrator. No changes are needed in CosmoMC or MontePython other than linking to the gCAMB executable. The installation procedure reported in the paper is based on cloning the `gpuport` branches of `CAMB` and `forutils`, loading `nvhpc/24.5` and `cuda/12.x`, compiling with `make compiler=nvfortran OPENACC=1`, and running `./camb gpu_params.ini` [2509.25110].

The stated dependencies are NVIDIA HPC SDK / `nvfortran 24.5+`, CUDA 11.0+, and OpenACC. The hardware requirement is any CUDA-capable GPU with compute capability $\ge 7.0$, with testing reported on A100 and Ada RTX6000 [2509.25110].

A central use case is the generation of neural-network training sets. The paper gives explicit throughput estimates:

| Setting | GPU time | CPU time |
|---|---:|---:|
| Medium accuracy per model | 16.8 s/model | 32.2 s/model |
| Medium accuracy for $10^5$ spectra | 19.4 days | 37 days |
| High accuracy per model | 54 s/model | 330 s/model |
| High accuracy for $10^5$ spectra | 62.5 days | 382 days |

These figures situate gCAMB as infrastructure for both direct inference and emulator preparation. The paper explicitly frames the software as facilitating the creation of extensive training sets needed for robust cosmological analyses [2509.25110]. A plausible implication is that the software reduces not only single-run latency but also the practical cost of model-specific surrogate construction.

## 6. Constraints and projected extensions

The current implementation has several explicit limitations. Only the flat-Universe integrator, `DoFlatIntegration`, is offloaded; curved universes, which require hyperspherical Bessel kernels, remain on CPU. The paper also identifies an `NVFORTRAN/OpenACC` compiler issue that prevents full OpenMP + GPU mixing in some polymorphic regions, with the expectation that future compiler versions will remove this limitation. In addition, the implementation is single-GPU only, with no multi-GPU scaling yet, and the source-function ODE step remains a serial-in-time Runge–Kutta integrator per mode, which can dominate in extended models [2509.25110].

The planned extensions are correspondingly specific: porting `DoNonFlatIntegration` to GPU to accelerate scans over $\Omega_K \ne 0$; adding support for massive neutrino hierarchies and modified gravity line-of-sight sources; exploring multi-GPU and `NVSHMEM/OpenACC` multi-node offloading; benchmarking on next-generation GPUs such as H100 and RTX 5xxx; and integrating gCAMB directly as a backend for MCMC samplers so as to run hybrid CPU/GPU inference without emulator overhead [2509.25110].

These limitations clarify the present boundary of the acceleration strategy. gCAMB does not claim to GPU-port the entire Boltzmann pipeline, nor does it eliminate the serial source-function step. Its present contribution is instead to isolate and accelerate the dominant line-of-sight projection while preserving compatibility with existing CAMB-based workflows.

Source: https://www.emergentmind.com/topics/gcamb