---
title: LiteBIRD Simulation Framework
url: https://www.emergentmind.com/topics/litebird-simulation-framework
type: topic
---

# LiteBIRD Simulation Framework

Searching arXiv for recent LiteBIRD simulation framework papers and related end-to-end simulation work.
The **LiteBIRD Simulation Framework** usually refers to **LBS**, a Python package for implementing pipelines that model the outputs of the data acquisition process from the three instruments on the LiteBIRD spacecraft—**LFT**, **MFT**, and **HFT**—together with the broader ecosystem of end-to-end, map-based, and subsystem-specific simulations built on top of that package [2507.04918]. In the collaboration’s own framing, LBS is not a single monolithic simulator but a modular environment used to assemble pipelines for nominal observations, noise, sky emission, scanning, mapmaking, and selected systematic effects, while maintaining accuracy and reproducibility through explicit provenance tracking and integration with the LiteBIRD Instrument Model database (IMo) [2507.04918]. The first official simulation release built with this framework demonstrates that role at mission scale, producing 500 full-sky simulated maps at \(N_{\mathrm{side}=512}\) and one year of time-ordered data for approximately one-third of the total detectors [2507.07122].

## 1. Definition and scope

In its strict software sense, the LiteBIRD Simulation Framework is the collaboration’s Python library **LBS**, designed for the implementation of pipelines that model the outputs of the data-acquisition process for LiteBIRD’s three telescopes [2507.04918]. The framework exists because LiteBIRD requires not only full end-to-end simulations of nominal observations, but also targeted pipelines for specific effects such as Half-Wave Plate systematics, transient-source studies, and faster approximate simulations for iterative design work [2507.04918]. The framework approach therefore emphasizes reusable components rather than a single hard-coded pipeline [2507.04918].

In a broader methodological sense, the phrase “LiteBIRD Simulation Framework” also denotes the collaboration’s emerging mission-level simulation ecosystem. That ecosystem includes the official end-to-end release built with LBS [2507.07122], mission-specific science forecasts that reuse LiteBIRD specifications and component-separation outputs [2312.00717], fast scan-strategy simulators such as **Falcons.jl** for optimization in scan-parameter space [2408.03040], and subsystem studies for cosmic rays, calibration drifts, beam far sidelobes, HWP misalignment, gain calibration, and related effects [2101.08410] [2106.06005] [2312.09001] [2411.02080] [2509.03564]. This suggests a layered architecture rather than a single canonical executable.

The framework is mission-specific. It is tied to LiteBIRD’s full-sky survey from the Sun–Earth \(L_2\) point, its three-telescope architecture, its multi-band polarization measurements, and its scientific requirement of reaching a total error on the tensor-to-scalar ratio at the \(\delta r \sim 0.001\) level or better in mission-level studies [2507.07122] [2507.04918]. A plausible implication is that “LiteBIRD Simulation Framework” is best understood as both a software package and a standards-bearing infrastructure for connecting instrument assumptions to science-level forecasts.

## 2. Core software architecture of LBS

LBS is organized around a small number of central abstractions. The top-level **`Simulation`** object stores global configuration and provenance, including the IMo handle, selected instrument, scanning strategy, HWP model, random seed, simulation metadata, and references to observations [2507.04918]. Per-detector, per-sample quantities are held in one or more **`Observation`** objects, whose principal content is time-ordered data stored as \(N \times M\) matrices, with \(N\) detectors and \(M\) time samples [2507.04918]. LBS also uses **`TodDescription`** objects to describe TOD components and wraps IMo entries through classes such as **`InstrumentInfo`**, **`FreqChannelInfo`**, and **`DetectorInfo`** [2507.04918].

The framework separates simulation modules from data-reduction modules, although it includes both in practice [2507.04918]. Simulation modules cover scanning, sky observation, dipoles, noise, and selected systematics, while data-reduction modules include an internal binner and destriper, a wrapper around TOAST2 destriping, and export to Madam-compatible FITS TOD [2507.04918]. The framework is a Python library rather than a standalone program: users write scripts that assemble pipelines from these components [2507.04918].

A central design constraint is memory and parallelization. LiteBIRD’s mission duration and detector count make TOD storage intrinsically large, so LBS supports MPI distribution along the detector axis, the time axis, or both, controlled through `n_blocks_det` and `n_blocks_time`, with redistribution available through `Observation.set_n_blocks()` [2507.04918]. This matters because different algorithms prefer different layouts: detector grouping is advantageous for detector-correlated operations, while time grouping is advantageous for time-domain operations [2507.04918]. In version 0.11.0, each MPI rank writes its own HDF5 output file [2507.04918].

The main dependencies explicitly identified in the framework paper are **NumPy**, **Numba**, **AstroPy**, **Healpy**, **PySM3**, and **HDF5**, with optional interoperability with **TOAST2** [2507.04918]. Later developments mentioned in that paper include on-the-fly pointing from quaternions, separation of HWP angle from detector orientation, and integration with **Ducc** for full \(4\pi\) beam convolution, but those are described as later than version 0.11.0 [2507.04918].

## 3. Instrument model, scanning, and sky generation

LBS is explicitly coupled to the LiteBIRD **Instrument Model database (IMo)**, which supplies the instrument description used by simulations [2507.04918]. In the first official end-to-end release, the simulations used IMo version v1.3, with one year of mission time and 1678 simulated detectors out of the nominal 4508, while rescaling detector noise to mimic the nominal full-mission sensitivity [2507.07122]. The mission baseline quoted there is a full-sky survey from \(L_2\), with 15 frequency bands from 34 to 448 GHz over 3 years, using 4508 detectors sampled at 19.1 Hz and targeting an effective polarization sensitivity of \(2\ \mu\mathrm{K\text{-}arcmin}\) and an angular resolution of 31 arcmin at 140 GHz [2507.07122].

The scan strategy implemented in official simulations follows the collaboration baseline. The telescope boresight is at \(\beta = 50^\circ\) from the spin axis, and the spin axis precesses around the Sun–Earth direction at \(\alpha = 45^\circ\) [2507.07122]. The spacecraft spins at \(0.05\) rpm, corresponding to a 20-minute spin period, and precesses with a period of about 192.348 minutes [2507.07122]. Combined with the annual revolution around the Sun from \(L_2\), this yields full-sky coverage in six months [2507.07122]. Telescope-dependent HWP rotation rates are 46 rpm for LFT, 39 rpm for MFT, and 61 rpm for HFT in the first official release [2507.07122].

Pointing generation is a core capability. In LBS, the spacecraft motion is modeled as the composition of spacecraft spin, spin-axis precession, and annual motion, with rotations encoded as quaternions sampled at a lower rate and interpolated by slerp to the detector sample times [2507.04918]. In version 0.11.0, the pointing information stored per sample consists of colatitude, longitude, and orientation angle, in Ecliptic coordinates in the example pipeline [2507.04918]. The first official release likewise describes loading detector quaternions and ephemerides to compute sample-by-sample detector pointing \((\theta,\phi,\psi)\) [2507.07122].

Sky generation is modular. In LBS, the **Mbs** module wraps **PySM3** for map-based sky simulation [2507.04918]. The first official release uses PySM through LBS/MBS for Galactic diffuse components and combines this with **WebSky** and **lenspix** for extragalactic components and lensed CMB realizations [2507.07122]. The input sky in that release includes thermal dust, synchrotron, anomalous microwave emission, free-free, CO, thermal SZ, kinetic SZ, CIB, lensing convergence, and radio sources, together with 500 lensed CMB Monte Carlo realizations drawn from Planck 2018 cosmology [2507.07122]. Before scanning, CMB and foreground maps are convolved with circular Gaussian beams using the IMo beam FWHM for each channel [2507.07122].

The framework also includes dipole simulation. The LBS paper gives the relativistic dipole temperature as
\[
T(\vec\beta, \hat n) = \frac{T_0}{\gamma \bigl(1 - \vec\beta \cdot \hat n\bigr)},
\]
together with its conversion to linear thermodynamic temperature using the blackbody function \( \mathrm{BB}(\nu,T) \) and
\[
f(x)=\frac{x e^x}{e^x - 1}
\]
[2507.04918]. The first official end-to-end release generates a dipole timeline `tod_dip` for the first simulation using the LBS `TOTAL_FROM_LIN_T` model [2507.07122].

## 4. Noise, mapmaking, and official end-to-end products

LBS supports white noise and correlated \(1/f\)-type noise. The per-detector power spectral density is parameterized in the LBS paper as
\[
P(f) = \sigma^2 \left(1 + \left(\frac{f_k}{f + f_\text{min}}\right)^\alpha\right),
\]
where \(\sigma^2\) is the white-noise power, \(f_k\) the knee frequency, and \(\alpha\) the low-frequency slope [2507.04918]. That paper notes an implementation limitation in version 0.11.0: \(1/f\) coherence is not preserved across MPI process boundaries when splitting along time, because the generator uses a simplified filtered-white-noise construction [2507.04918].

The first official release instantiates this noise structure in three products: white noise only, white plus \(1/f\) with \(f_{\rm knee}=30\) mHz, and white plus \(1/f\) with \(f_{\rm knee}=100\) mHz [2507.07122]. The \(30\) mHz case is described as realistic and the \(100\) mHz case as pessimistic [2507.07122]. The release gives a frequency-domain model for the \(1/f\) realization in which the Fourier amplitudes are modulated by the standard \(1/f^\alpha\)-type scaling with \(\alpha=1\) [2507.07122].

Mapmaking in the first official release is intentionally simple. A naive binner is used to turn timelines into channel maps at \(N_{\mathrm{side}}=512\) [2507.07122]. The release also produces per-channel pixel-domain covariance matrices for the first simulation as validation products [2507.07122]. Although the generalized least-squares mapmaking equation is given in the paper,
\[
\hat{\mathbf{m}} = (\mathbf{A}^\mathrm{T}\mathbf{N}^{-1} \mathbf{A})^{-1}\mathbf{A}^\mathrm{T} \mathbf{N}^{-1}\mathbf{d},
\]
the actual release maps are binned rather than produced with a full GLS solver [2507.07122].

The output of the official release is substantial. The framework generates 500 full-sky simulated maps at \(N_{\mathrm{side}}=512\) and one year of TOD for approximately one-third of LiteBIRD’s total detectors [2507.07122]. The total storage footprint is about 35 TB, and the campaign required about 600 kcpu.h on the MARCONI-CINECA HPC facility [2507.07122]. The paper describes these products as already being used for downstream analysis readiness, including feasibility studies of fully Bayesian analysis within the Cosmoglobe framework [2507.07122] [2507.05324].

Validation in the official release is performed at several levels: inspected TOD structure, PSD consistency with the target noise model, pixel-space covariance behavior, and output-minus-input power spectra [2507.07122]. One explicit conclusion is that polarization spectra remain close to white noise because the ideal HWP shifts the polarized sky signal to higher temporal frequencies, suppressing the impact of low-frequency noise in polarization maps [2507.07122].

## 5. Science-forecast pipelines built on the framework

A major use of the LiteBIRD simulation framework is the construction of downstream science forecasts. A representative example is the LiteBIRD forecast for spectator axion–SU(2) inflation, which is explicitly described not as the paper defining the framework itself, but as a downstream science analysis using “map-based simulations with LiteBIRD specifications” and the same assumptions as section 5.2 of the LiteBIRD overview paper [2312.00717]. That study is nevertheless informative about the operational analysis stack.

In that pipeline, input CMB and Galactic foreground maps are generated in each LiteBIRD frequency channel at HEALPix resolution \(N_{\rm side}=512\), with Galactic foregrounds simulated using **PySM** model d1s1 and multifrequency skies passed through top-hat bandpasses, channel coaddition, Gaussian circular beams, and white instrumental noise [2312.00717]. A total of 1000 realizations of CMB, noise, and foregrounds are generated [2312.00717]. Component separation is performed with **FGBuster** using a parametric model with dust spectral index, dust temperature, and synchrotron spectral index, fitted patchwise on the sky [2312.00717]. FGBuster outputs residual/noise maps at \(N_{\rm side}=64\), and because those residual maps are independent of the input CMB realization, they can be added afterward to Gaussian CMB realizations from arbitrary inflationary models without rerunning the cleaning stage [2312.00717].

The power-spectrum estimation in that science forecast is hybrid: **xQML** for \(\ell<35\) and **NaMaster** pure pseudo-\(C_\ell\) estimation for \(\ell\ge 35\) [2312.00717]. The covariance is empirical, estimated from simulations, and the likelihood uses the Hamimeche–Lewis approximation augmented by an offset term and a Sellentin–Heavens correction for covariance uncertainty [2312.00717]. Parameter fits are performed with **iMinuit**, and confidence intervals on bounded feature parameters are derived by a frequentist Feldman–Cousins construction [2312.00717]. This suggests that one practical function of the framework is to support highly customized science-specific likelihood chains, rather than enforcing a single mission-wide likelihood package.

A conceptually different but still LiteBIRD-oriented pipeline is the fast end-to-end ABS–NN framework for inferring \(\tau\) and \(r\), which generates full-sky polarization simulations, performs component separation at the power-spectrum level with **Analytical Blind Separation**, and then trains neural networks to map cleaned \(EE\) and \(BB\) spectra to parameters [2511.01291]. That framework is not an official LiteBIRD pipeline, but it demonstrates that LiteBIRD simulation products can support amortized simulation-based inference as well as conventional likelihood analyses [2511.01291].

## 6. Systematics modules and specialized simulation branches

Beyond nominal mission simulation, the LiteBIRD simulation framework landscape includes a set of focused systematics studies that use framework components to inject effects and propagate them to maps, spectra, and parameter biases.

For cosmic rays, two 2021 papers contribute a detector-to-map subsystem. One paper focuses on propagating simulated cosmic-ray-only timelines through scanning, mapmaking, and \(E/B\)-mode estimation using TOAST and healpy, yielding an initial contamination estimate of
\[
C_\ell^{BB} \sim 2\times 10^{-6}\ \mu\mathrm{K}_{\mathrm{CMB}^2}
\]
for a one-year observation with 12 detectors under a provisional differential-mode noise assumption of \(1\ \mathrm{aW}/\sqrt{\mathrm{Hz}}\) [2101.08410]. The companion cosmic-ray study constructs a more explicitly physics-based chain from proton flux at \(L_2\) through wafer thermal response, TES electrothermal response, readout filtering, timeline generation, TOAST scanning, and mapmaking, thereby providing a more detailed end-to-end simulator for one specific systematic [2107.00473]. Together they show how detector-level physics can be compressed into statistical timeline models and then propagated to mission observables.

Calibration and beam systematics are treated in several papers. A TOAST-based study simulates calibration uncertainties, gain drifts, and beam asymmetry support for a LiteBIRD-like 140 GHz configuration with 48 polarization-sensitive detectors and one year of observation, and proposes a time-domain template-fitting mitigation solved by PCG [2106.06005]. In that study the leakage-reduction result is about two orders of magnitude at the power-spectrum level [2106.06005]. A separate paper on beam far side-lobes provides a genuinely end-to-end methodology starting from imperfect beam knowledge and propagating the effect through simulated observations, beam correction, harmonic-domain component separation, and cosmological bias on \(r\), finding under its assumptions that the integrated fractional power in the far side-lobes should be known at the \(\sim 10^{-4}\) level to keep \(\delta r<1.9\times10^{-5}\) [2312.09001].

HWP-related systematic studies illustrate a further branch of the framework. One paper models the coupled effect of HWP differential optical load and TES nonlinearity for MHFT channels, using one-year TOD simulations, mapmaking, HILC component separation, and Hamimeche–Lewis likelihood evaluation to derive a requirement on residual TES nonlinearity,
\[
\sigma_{g_1} < 2\times 10^{-3}\ \mathrm{K}^{-1},
\]
under the allocated systematic budget \(\delta r \le 6.5\times10^{-6}\) [2407.15294]. Another paper studies wedge-like misalignment in a reflective polarization modulator “through the LiteBIRD simulation framework (LBS),” with explicit TOD-level injection and map reconstruction using nominal pointing, and concludes that the induced \(BB\) residual is nearly flat and lensing-like rather than tensor-like [2509.03564]. This suggests that LBS is already being used as the common engine for propagating instrument-systematic perturbations from TOD to cosmological diagnostics.

The gain-calibration paper provides a map-domain example of relative polarization-gain errors propagated through blind component separation. It injects multiplicative channel-wise polarization gain factors
\[
g_\nu = 1 + \mathcal{N}(0,\Delta g_\nu)
\]
into all 22 LiteBIRD polarized channels and derives per-channel requirements under NILC, with the tightest baseline requirement at the 166 GHz channel, \(\Delta g_\nu \approx 0.16\%\) [2411.02080]. That study emphasizes that gain requirements depend strongly on the component-separation method, which is an important methodological point for the framework as a whole [2411.02080].

## 7. Scan optimization, Bayesian analysis, and reproducibility

LiteBIRD simulation work also includes specialized layers that support, rather than replace, the core end-to-end pipeline. The scan-optimization paper develops **Falcons.jl**, a fast spacecraft scanning simulator that computes pointings and cross-link factors from scan parameters [2408.03040]. It treats the six-dimensional scan-parameter space
\[
\{\alpha,\beta,T_\alpha,T_\beta,\nu_\phi,f_s\}
\]
and provides metrics for hit-map uniformity, planet visibility, cross-link factors, and null-test design [2408.03040]. The paper explicitly positions Falcons as faster than TOD-based end-to-end simulation for scan-parameter studies while acknowledging that time-dependent systematics still require full TOD simulations [2408.03040]. This suggests a division of labor in the broader framework: LBS for detailed mission-like pipelines, Falcons for scan-strategy optimization.

At the opposite end of the stack, the computational-feasibility study with **Commander3** and **Cosmoglobe** explores whether LiteBIRD TOD can be analyzed within a fully Bayesian end-to-end posterior framework [2507.05324]. That study starts from LBS-generated TOD, converts them into Commander3-compatible format, and estimates that a full three-year mission would correspond to about 238 TB raw or 70 TB after Huffman compression, with roughly 3000 CPU-hours per Gibbs sample [2507.05324]. The current feasibility run uses an idealized instrument model with correlated \(1/f\) noise as the main non-white systematic, but it demonstrates that LBS products are already compatible with downstream Bayesian pipelines that propagate uncertainties from TOD to cosmological parameters [2507.05324].

Reproducibility is a formal design principle in LBS itself. The framework records simulation metadata, IMo access, code version, git hash, and git diff in an automatically generated report, and it copies TOML parameter files into the output directory [2507.04918]. Random number generation uses PCG-64, with distinct RNGs under MPI and reproducibility guaranteed for a fixed script, seed, and number of MPI ranks [2507.04918]. The LBS paper also describes a layered testing strategy—unit tests, randomized tests, integration tests, and MPI-specific tests—which is unusual for instrument-simulation software and indicates that the framework is meant to function as shared scientific infrastructure rather than as a one-off codebase [2507.04918].

## 8. Limitations, interpretation, and current status

The framework papers are explicit that the current LiteBIRD simulation framework is not yet a final flight-level truth model. In LBS version 0.11.0, map scanning assumes perfect pencil beams and an ideal HWP, while more realistic HWP simulation and full \(4\pi\) beam convolution only appear in later versions mentioned in the paper [2507.04918]. The first official release is intentionally limited to one year instead of the nominal three, 1678 detectors instead of 4508, circular Gaussian beams, ideal detector yield, no gain drifts, no downtime, no cosmic-ray glitches, no beam asymmetries, and no HWP non-idealities [2507.07122]. The release authors explicitly describe it as a pathfinder rather than the final mission-simulation suite [2507.07122].

A second limitation is that many highly cited LiteBIRD science forecasts reuse LiteBIRD mission specifications without themselves defining the official framework. The inflation-feature paper states this directly, noting that it is best understood as a science-case application built on top of a realistic LiteBIRD forecast pipeline, not as a paper defining the LiteBIRD simulation framework [2312.00717]. This is important because it prevents conflating “LiteBIRD-based forecast pipeline” with “official framework.”

A further caveat is that some systematic studies are deliberately isolated. The HWP wedge-angle analysis, for example, uses CMB-only skies, neglects noise and foregrounds, and assumes perfectly matched detector pairs in order to isolate one geometric effect [2509.03564]. The gain-calibration requirement study works entirely in map space, with no scan strategy, mapmaking residuals, or beam mismatch [2411.02080]. These studies are therefore best read as framework modules or use cases, not as complete replacements for the collaboration’s end-to-end simulations.

The current status, as indicated by the two 2025 LBS papers, is that LiteBIRD has both a formal simulation framework paper describing LBS as a Python package [2507.04918] and a first official end-to-end release paper demonstrating that the framework is already producing mission-scale simulation products [2507.07122]. A plausible interpretation is that the framework has moved from architectural definition to operational deployment, while still retaining a modular structure that invites subsystem and science-case extensions.

## 9. Significance

Within LiteBIRD, the simulation framework functions as the bridge between instrument design, survey strategy, systematic-error control, and cosmological performance. It provides a common language for describing detectors, scanning, beams, sky emission, and maps through IMo-backed, scriptable components [2507.04918]. It also provides the basis for official end-to-end simulation campaigns [2507.07122], for design-optimization tools such as Falcons [2408.03040], for systematic-effect propagation from TOD to \(r\)-bias [2312.09001] [2407.15294] [2509.03564], and for exploratory downstream analysis paradigms such as ABS–NN inference or full Bayesian Gibbs sampling [2511.01291] [2507.05324].

The framework’s main conceptual contribution is modularity with shared assumptions. Instead of one fixed pipeline, it offers a common substrate on which LiteBIRD-specific simulators, component-separation workflows, and likelihood analyses can be built while remaining anchored to the same instrument description and reproducibility conventions [2507.04918]. In that sense, the LiteBIRD Simulation Framework is both a concrete software package and the central organizing principle of LiteBIRD’s pre-launch simulation program.

Source: https://www.emergentmind.com/topics/litebird-simulation-framework