LiteBIRD Simulation Framework
- LiteBIRD Simulation Framework is a Python library designed to assemble modular pipelines that model data acquisition from LiteBIRD’s three telescopes.
- It integrates end-to-end, map-based, and subsystem-specific simulations with reproducibility, efficient MPI parallelization, and IMo integration.
- The framework produces mission-scale outputs—full-sky maps, time-ordered data, and noise/systematic models—to support robust cosmological forecasts.
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 (Tomasi et al., 7 Jul 2025). 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) (Tomasi et al., 7 Jul 2025). The first official simulation release built with this framework demonstrates that role at mission scale, producing 500 full-sky simulated maps at and one year of time-ordered data for approximately one-third of the total detectors (Bortolami et al., 8 Jul 2025).
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 (Tomasi et al., 7 Jul 2025). 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 (Tomasi et al., 7 Jul 2025). The framework approach therefore emphasizes reusable components rather than a single hard-coded pipeline (Tomasi et al., 7 Jul 2025).
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 (Bortolami et al., 8 Jul 2025), mission-specific science forecasts that reuse LiteBIRD specifications and component-separation outputs (Campeti et al., 2023), fast scan-strategy simulators such as Falcons.jl for optimization in scan-parameter space (Takase et al., 2024), and subsystem studies for cosmic rays, calibration drifts, beam far sidelobes, HWP misalignment, gain calibration, and related effects (Tominaga et al., 2021, Puglisi et al., 2021, Leloup et al., 2023, Carralot et al., 2024, Stellati et al., 3 Sep 2025). 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 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 level or better in mission-level studies (Bortolami et al., 8 Jul 2025, Tomasi et al., 7 Jul 2025). 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 (Tomasi et al., 7 Jul 2025). Per-detector, per-sample quantities are held in one or more Observation objects, whose principal content is time-ordered data stored as matrices, with detectors and time samples (Tomasi et al., 7 Jul 2025). LBS also uses TodDescription objects to describe TOD components and wraps IMo entries through classes such as InstrumentInfo, FreqChannelInfo, and DetectorInfo (Tomasi et al., 7 Jul 2025).
The framework separates simulation modules from data-reduction modules, although it includes both in practice (Tomasi et al., 7 Jul 2025). 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 (Tomasi et al., 7 Jul 2025). The framework is a Python library rather than a standalone program: users write scripts that assemble pipelines from these components (Tomasi et al., 7 Jul 2025).
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() (Tomasi et al., 7 Jul 2025). 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 (Tomasi et al., 7 Jul 2025). In version 0.11.0, each MPI rank writes its own HDF5 output file (Tomasi et al., 7 Jul 2025).
The main dependencies explicitly identified in the framework paper are NumPy, Numba, AstroPy, Healpy, PySM3, and HDF5, with optional interoperability with TOAST2 (Tomasi et al., 7 Jul 2025). 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 beam convolution, but those are described as later than version 0.11.0 (Tomasi et al., 7 Jul 2025).
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 (Tomasi et al., 7 Jul 2025). 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 (Bortolami et al., 8 Jul 2025). The mission baseline quoted there is a full-sky survey from , 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 and an angular resolution of 31 arcmin at 140 GHz (Bortolami et al., 8 Jul 2025).
The scan strategy implemented in official simulations follows the collaboration baseline. The telescope boresight is at from the spin axis, and the spin axis precesses around the Sun–Earth direction at 0 (Bortolami et al., 8 Jul 2025). The spacecraft spins at 1 rpm, corresponding to a 20-minute spin period, and precesses with a period of about 192.348 minutes (Bortolami et al., 8 Jul 2025). Combined with the annual revolution around the Sun from 2, this yields full-sky coverage in six months (Bortolami et al., 8 Jul 2025). Telescope-dependent HWP rotation rates are 46 rpm for LFT, 39 rpm for MFT, and 61 rpm for HFT in the first official release (Bortolami et al., 8 Jul 2025).
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 (Tomasi et al., 7 Jul 2025). 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 (Tomasi et al., 7 Jul 2025). The first official release likewise describes loading detector quaternions and ephemerides to compute sample-by-sample detector pointing 3 (Bortolami et al., 8 Jul 2025).
Sky generation is modular. In LBS, the Mbs module wraps PySM3 for map-based sky simulation (Tomasi et al., 7 Jul 2025). 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 (Bortolami et al., 8 Jul 2025). 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 (Bortolami et al., 8 Jul 2025). Before scanning, CMB and foreground maps are convolved with circular Gaussian beams using the IMo beam FWHM for each channel (Bortolami et al., 8 Jul 2025).
The framework also includes dipole simulation. The LBS paper gives the relativistic dipole temperature as
4
together with its conversion to linear thermodynamic temperature using the blackbody function 5 and
6
(Tomasi et al., 7 Jul 2025). 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 (Bortolami et al., 8 Jul 2025).
4. Noise, mapmaking, and official end-to-end products
LBS supports white noise and correlated 7-type noise. The per-detector power spectral density is parameterized in the LBS paper as
8
where 9 is the white-noise power, 0 the knee frequency, and 1 the low-frequency slope (Tomasi et al., 7 Jul 2025). That paper notes an implementation limitation in version 0.11.0: 2 coherence is not preserved across MPI process boundaries when splitting along time, because the generator uses a simplified filtered-white-noise construction (Tomasi et al., 7 Jul 2025).
The first official release instantiates this noise structure in three products: white noise only, white plus 3 with 4 mHz, and white plus 5 with 6 mHz (Bortolami et al., 8 Jul 2025). The 7 mHz case is described as realistic and the 8 mHz case as pessimistic (Bortolami et al., 8 Jul 2025). The release gives a frequency-domain model for the 9 realization in which the Fourier amplitudes are modulated by the standard 0-type scaling with 1 (Bortolami et al., 8 Jul 2025).
Mapmaking in the first official release is intentionally simple. A naive binner is used to turn timelines into channel maps at 2 (Bortolami et al., 8 Jul 2025). The release also produces per-channel pixel-domain covariance matrices for the first simulation as validation products (Bortolami et al., 8 Jul 2025). Although the generalized least-squares mapmaking equation is given in the paper,
3
the actual release maps are binned rather than produced with a full GLS solver (Bortolami et al., 8 Jul 2025).
The output of the official release is substantial. The framework generates 500 full-sky simulated maps at 4 and one year of TOD for approximately one-third of LiteBIRD’s total detectors (Bortolami et al., 8 Jul 2025). The total storage footprint is about 35 TB, and the campaign required about 600 kcpu.h on the MARCONI-CINECA HPC facility (Bortolami et al., 8 Jul 2025). The paper describes these products as already being used for downstream analysis readiness, including feasibility studies of fully Bayesian analysis within the Cosmoglobe framework (Bortolami et al., 8 Jul 2025, Aurvik et al., 7 Jul 2025).
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 (Bortolami et al., 8 Jul 2025). 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 (Bortolami et al., 8 Jul 2025).
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 (Campeti et al., 2023). 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 5, 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 (Campeti et al., 2023). A total of 1000 realizations of CMB, noise, and foregrounds are generated (Campeti et al., 2023). 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 (Campeti et al., 2023). FGBuster outputs residual/noise maps at 6, 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 (Campeti et al., 2023).
The power-spectrum estimation in that science forecast is hybrid: xQML for 7 and NaMaster pure pseudo-8 estimation for 9 (Campeti et al., 2023). 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 (Campeti et al., 2023). Parameter fits are performed with iMinuit, and confidence intervals on bounded feature parameters are derived by a frequentist Feldman–Cousins construction (Campeti et al., 2023). 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 0 and 1, 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 2 and 3 spectra to parameters (Santos et al., 3 Nov 2025). 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 (Santos et al., 3 Nov 2025).
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 4-mode estimation using TOAST and healpy, yielding an initial contamination estimate of
5
for a one-year observation with 12 detectors under a provisional differential-mode noise assumption of 6 (Tominaga et al., 2021). The companion cosmic-ray study constructs a more explicitly physics-based chain from proton flux at 7 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 (Stever et al., 2021). 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 (Puglisi et al., 2021). In that study the leakage-reduction result is about two orders of magnitude at the power-spectrum level (Puglisi et al., 2021). 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 8, finding under its assumptions that the integrated fractional power in the far side-lobes should be known at the 9 level to keep 0 (Leloup et al., 2023).
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,
1
under the allocated systematic budget 2 (Micheli et al., 2024). 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 3 residual is nearly flat and lensing-like rather than tensor-like (Stellati et al., 3 Sep 2025). 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
4
into all 22 LiteBIRD polarized channels and derives per-channel requirements under NILC, with the tightest baseline requirement at the 166 GHz channel, 5 (Carralot et al., 2024). 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 (Carralot et al., 2024).
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 (Takase et al., 2024). It treats the six-dimensional scan-parameter space
6
and provides metrics for hit-map uniformity, planet visibility, cross-link factors, and null-test design (Takase et al., 2024). 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 (Takase et al., 2024). 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 (Aurvik et al., 7 Jul 2025). 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 (Aurvik et al., 7 Jul 2025). The current feasibility run uses an idealized instrument model with correlated 7 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 (Aurvik et al., 7 Jul 2025).
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 (Tomasi et al., 7 Jul 2025). Random number generation uses PCG-64, with distinct RNGs under MPI and reproducibility guaranteed for a fixed script, seed, and number of MPI ranks (Tomasi et al., 7 Jul 2025). 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 (Tomasi et al., 7 Jul 2025).
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 8 beam convolution only appear in later versions mentioned in the paper (Tomasi et al., 7 Jul 2025). 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 (Bortolami et al., 8 Jul 2025). The release authors explicitly describe it as a pathfinder rather than the final mission-simulation suite (Bortolami et al., 8 Jul 2025).
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 (Campeti et al., 2023). 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 (Stellati et al., 3 Sep 2025). The gain-calibration requirement study works entirely in map space, with no scan strategy, mapmaking residuals, or beam mismatch (Carralot et al., 2024). 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 (Tomasi et al., 7 Jul 2025) and a first official end-to-end release paper demonstrating that the framework is already producing mission-scale simulation products (Bortolami et al., 8 Jul 2025). 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 (Tomasi et al., 7 Jul 2025). It also provides the basis for official end-to-end simulation campaigns (Bortolami et al., 8 Jul 2025), for design-optimization tools such as Falcons (Takase et al., 2024), for systematic-effect propagation from TOD to 9-bias (Leloup et al., 2023, Micheli et al., 2024, Stellati et al., 3 Sep 2025), and for exploratory downstream analysis paradigms such as ABS–NN inference or full Bayesian Gibbs sampling (Santos et al., 3 Nov 2025, Aurvik et al., 7 Jul 2025).
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 (Tomasi et al., 7 Jul 2025). 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.