Source-linked AI summary
CosmoSIS: modular cosmological parameter estimation
Joe Zuntz, Marc Paterno, Elise Jennings, Douglas Rudd, Alessandro Manzotti, Scott Dodelson, Sarah Bridle, Saba Sehrish, James Kowalkowski
TL;DR
Precision cosmology increasingly requires analyses that handle complex systematics, many parameters, alternative models, and multiple computational methods. CosmoSIS addresses this need with a modular architecture connecting interchangeable calculations and existing code. The framework provides extensible modules and samplers, while its modular design requires validation and can be more vulnerable to misuse than rigid monolithic code.
Problem
Next-generation cosmological analyses face nonlinear multi-probe systematics, larger parameter spaces, alternative cosmologies, and heterogeneous code that complicate robust parameter estimation.
Method
CosmoSIS connects distinct physics, likelihood, and sampler modules through a plug-in architecture that supports multiple programming languages and existing community code.
Results
CosmoSIS provides a freely available, flexible, and extendable modular framework with standard cosmological modules, samplers, and runnable analysis examples.
Takeaways & Limitations
The framework's value lies in extensibility, enabling existing or new cosmological inference code to be wrapped and contributed as modules.
Takeaways & Limitations
Modular data exchange can require interpolation that introduces inaccuracy and places validation burdens on users, while modular pipelines are more vulnerable to misuse than rigid monolithic code.
Abstract
from arXiv · showhide
Cosmological parameter estimation is entering a new era. Large collaborations need to coordinate high-stakes analyses using multiple methods; furthermore such analyses have grown in complexity due to sophisticated models of cosmology and systematic uncertainties. In this paper we argue that modularity is the key to addressing these challenges: calculations should be broken up into interchangeable modular units with inputs and outputs clearly defined. We present a new framework for cosmological parameter estimation, CosmoSIS, designed to connect together, share, and advance development of inference tools across the community. We describe the modules already available in CosmoSIS, including CAMB, Planck, cosmic shear calculations, and a suite of samplers. We illustrate it using demonstration code that you can run out-of-the-box with the installer available at http://bitbucket.org/joezuntz/cosmosis
1. Introduction
Cosmological parameter estimation turns compressed observations into constraints on cosmological model parameters, typically using Bayesian likelihoods and sampling. The paper introduces CosmoSIS as a modular framework for connecting existing inference code to address increasingly complex precision-cosmology analyses.
- Cosmological parameter estimation transforms compressed data, such as power spectra or supernova brightnesses, into constraints on cosmological model parameters.
- Bayesian CPE evaluates observed data under proposed theories and parameters, then varies parameters within priors using samplers such as Markov Chain Monte Carlo.
- The resulting posterior distribution is commonly summarized by best-fit parameter values and uncertainties given the model and data.
- New surveys probe nonlinear, multi-probe regimes where complex systematics, added physics, and statistical correlations make parameter estimation difficult.
- CosmoSIS uses a plug-in architecture to connect distinct calculations across languages and extend physics, likelihood, and sampler libraries.
- The paper presents CosmoSIS, outlines its structure and collaborative-development model, and demonstrates its features through runnable examples.
2. Challenges
Current and future cosmological analyses face correlated systematics, larger parameter spaces, alternative cosmologies, computational costs, heterogeneous legacy code, and collaboration challenges. These requirements motivate a framework that supports interchangeable models, sampling methods, existing code, and geographically distributed development.
- Nonlinear multi-probe data make correlated physical and analysis systematics dominant, requiring consistent modeling across measurements and inferred statistics.
- Richer physical models increase parameter counts and computational costs; Planck required about 20 nuisance parameters for physical and instrumental systematics.
- Analyses must test alternative systematic models because systematics are dominant and poorly understood, but inflexible frameworks can become overwhelmingly complicated.
- Alternative cosmologies such as modified gravity and dynamical dark energy are difficult to explore when analyses and calibration methods assume ΛCDM throughout.
- Slow likelihood evaluations increase the need for advanced, easily changeable samplers, especially parallel methods for multicore and multi-node platforms.
- A useful framework must integrate heterogeneous existing code while making it easier for geographically distributed collaborations to share and compare methods.
3. Modularity
CosmoSIS applies modularity to cosmological parameter estimation by separating calculations into replaceable units with explicit data interfaces. This structure supports flexible pipelines, model and sampler replacement, clearer verification, and collaboration, while introducing overheads, interpolation risks, and greater scope for misuse or over-complexity.
- Modularity: Modularity breaks complex calculations into modules with specific tasks, explicit inputs and outputs, and no direct access to other modules’ data.Modules communicate through controlled interfaces and a shared datablock rather than global variables or direct data access.
- Modularity: A likelihood becomes a sequential pipeline whose modules can be replaced at runtime without affecting the others.This enables systematic models and alternative cosmologies to be explored within the same framework.
- Modularity: CosmoSIS demonstrates modular galaxy-power-spectrum calculations from linear and non-linear matter spectra through bias modelling, window integration, and likelihood evaluation.The example uses a Boltzmann code for P(k, z), Halofit or another model for PNL(k, z), then compares predictions with measurements.
- Benefits: The architecture makes it easier to switch models through configuration, test individual modules, expose assumptions, combine contributions, and reuse pipelines with different samplers or languages.It also supports incorporating legacy code as modules and makes shared physics and systematics explicit through the common datablock.
- Costs: Modularity adds connection overhead, can require interpolation that introduces inaccuracy, may forgo tightly coupled efficiencies, and remains vulnerable to misuse and over-complicated pipelines.Existing code may also need modification to fit the framework, while explicit runtime settings help preserve reproducibility and clarify assumptions.
4. CosmoSIS structure
CosmoSIS represents parameter estimation as a pipeline of modular calculations connected through a shared DataBlock. Its runtime supports interchangeable physics and likelihood modules, multiple samplers, configuration files, and multi-language extensions.
- Components: A pipeline is a sequence of calculations that computes a joint likelihood from a series of parameters.
- Components: Modules perform separate physics, interpolation, or likelihood steps, and users can write and include additional modules.
- DataBlock: For each parameter set, module inputs are read from the DataBlock and outputs are written back to it.
- Samplers: CosmoSIS defines samplers broadly as procedures that generate parameter sets, run the pipeline, and process the results; available options include test, grid, and MCMC samplers.
- Implementation: The framework connects multi-language modules through shared-library or Python interfaces and uses configuration files to initialize and override pipeline settings.
- Example architecture: CAMB and Planck can form a simple pipeline, with CAMB supplying spectra and distances and Planck reading spectra to produce likelihoods.
5. Examples
CosmoSIS demonstrations apply its pipelines to theory outputs, likelihood slices, parameter constraints, optimization, MCMC, and grid sampling. The examples also show automated post-processing and a dimensionality limit for grid searches.
- Basic pipeline: The first demo runs CAMB and halofit without likelihoods, saving cosmological outputs that can be analyzed and plotted afterward.
- Likelihoods: Adding Planck and BICEP2 likelihoods produces a pipeline whose test sampler reports output likelihood values.
- Likelihood slice: A grid sampler evaluates a line through the BICEP2 likelihood in r and produces constraints with normalized-likelihood plots and 68% and 95% contours.
- MCMC: The JLA example uses emcee to constrain the Hubble parameter h and supernova magnitude parameter ∆M, with CosmoSIS generating the 1D and 2D plots.
- Cosmic shear: The CFHTLenS example chains six modules for cosmic-shear likelihood calculations, but uses the test sampler because the process is slow.
- Grid sampling: The BOSS example runs a parallel-capable 2D grid over growth-rate and σ8 constraints, with postprocessing automatically generating grid plots and marginalizing other sampled parameters.
- Grid sampling: Above about 4 dimensions, grid sampling becomes infeasible because the sample count scales as (ngrid)^ndim.
6. Sharing CosmoSIS modules
CosmoSIS organizes reusable inference modules into shared and user-managed libraries, enabling collaboration, replacement, and contribution across cosmological analyses.
- The CosmoSIS standard library includes CAMB, Planck and CFHTLenS likelihoods, mass functions, bias parameterizations, and source-count calculations.
- Users and collaborations can create module libraries that augment or replace the standard library for theory-, experiment-, or paper-specific calculations.Examples include adding systematic effects or substituting an improved mass function.
- 6.1. Module repositories: Version-controlled repositories organize module collections and support code storage, synchronization, review, and sharing among individuals, teams, and the wider community.
- 6.2. Contributing to the standard library: The standard library welcomes contributed modules subject to distribution permission, public data, general usefulness, and accuracy, quality, and documentation standards.CosmoSIS does not enforce a specific coding technology, but encourages tests and provides a mechanism to run them.
- 6.2. Contributing to the standard library: YAML files document each module’s name, authorship, purpose, assumptions, inputs, and outputs in human- and machine-readable form.
7. Discussion
CosmoSIS presents modularity as a flexible, extensible framework for constructing, testing, and extending cosmological parameter-estimation pipelines.
- 7. Discussion: CosmoSIS’s core claim is that modularity may be vital for keeping cosmological parameter estimation accessible across the community.The framework is presented as freely available, flexible, and extendable for observers, analysts, and theorists.
- A pipeline is assembled by selecting ordered modules, defining parameter inputs and ranges, checking execution with the test sampler, choosing a sampler, and post-processing outputs.
- The framework supports theory predictions as well as likelihood production, including predictions generated with tools such as CAMB.
- Each module’s required inputs must come from earlier modules or sampler settings, while conflicting outputs are disallowed unless explicitly overwritten.
- Modular pipelines allow systematic-error steps to be added later, such as inserting weak-lensing shape-measurement scaling during analysis development.
- Pipeline execution is checked by saving module-generated data, which can be compared with expected values to verify operation.
Appendix A.5. Choosing a sampler
CosmoSIS offers samplers for testing, optimization, grid exploration, and Monte Carlo inference, alongside development pathways for extending pipelines and modules.
- Appendix A.5. Choosing a sampler: The grid sampler provides straightforward post-processing and no convergence question, but is generally impractical beyond four dimensions.It is recommended for visualizing one- or two-dimensional likelihood slices.
- Appendix A.5. Choosing a sampler: For standard problems, CosmoSIS recommends starting with maxlike to find the probability peak, then running emcee from that starting point.The maxlike sampler can output an ini file centered on its best fit for other samplers.
- Appendix A.5. Choosing a sampler: All samplers use the same executable interface, while grid and emcee can use MPI parallelism through a command-line option.
- Appendix A.5. Choosing a sampler: The test sampler evaluates a pipeline at one parameter-space point, making it useful for configuration checks and theoretical predictions.
- Appendix A.5. Choosing a sampler: The emcee sampler’s practical accuracy can be assessed using acceptance fractions between 0.2-0.5 and estimated autocorrelation times.Increasing the number of walkers can improve poor acceptance fractions.
- CosmoSIS development includes modifying, adding, or inserting modules, creating pipelines, adding likelihoods, and implementing new samplers.New modules can separate calculation code from the CosmoSIS interface and can wrap existing external code.
Appendix B.4. Adding samplers
CosmoSIS supports interchangeable samplers and modular pipeline changes for CFHTLenS likelihood calculations. Its pipeline separates cosmological predictions, survey modeling, and likelihood evaluation into replaceable, appendable, or insertable modules.
- Adding samplers: New samplers can be added through a Python-callable interface, including samplers implemented in C, C++, Fortran, or Python.Sampler subclasses use a common base-class interface.
- Adding samplers: Sampler subclasses implement configuration, execution of sampling chunks, and convergence testing, while CosmoSIS repeats execution until convergence.Parallel samplers additionally maintain process pools with separate pipeline instances.
- CFHTLenS pipeline: The CFHTLenS example computes likelihoods through six stages, from linear and nonlinear matter power spectra to redshift distributions, shear spectra, correlation functions, and likelihood evaluation.The pipeline is illustrated schematically in Figure C.8.
- Pipeline modifications: Figure C.8 illustrates three modular modifications: replacing a nonlinear-power module, appending the Planck likelihood, and inserting a photometric-redshift systematic model.The Planck addition can introduce nuisance parameters through the sampler input values.
- Pipeline modifications: Photometric CFHTLenS redshifts require modeling the actual redshift distribution in each bin rather than relying only on nominal redshifts.The stated reason is that photometric redshifts are approximate.
Appendix C.3. Pipeline implementation
A CosmoSIS pipeline consists of modules that exchange inputs and outputs through a shared DataBlock. The implementation separates one-time setup from repeated execution for each sampled cosmology.
- Module structure: Each CosmoSIS module performs one calculation, reads a small collection of DataBlock inputs, and writes its outputs back to the block.The configuration file specifies the sampler, modules, extracted likelihoods, parameter values, and module options.
- Module structure: The demonstrated correlation-function module converts shear angular power spectra into correlation functions using Bessel-function integration.It is implemented in Python, while the same interface principles apply to other supported languages.
- Initial setup: The setup function runs once, reads angular-range options, constructs the theta grid, and passes configuration data to later executions.The returned configuration contains the theta vector used for correlation calculations.
- Repeated execution: For each new cosmological parameter set, execute reads sampler and upstream results from the input block, then saves correlation outputs in the shear_xi section.The inputs include ell and bin-pair angular power spectra from the shear_cl section.
Appendix D.1. DataBlocks
CosmoSIS DataBlocks provide a language-independent container for theoretical predictions and sampled parameters. They organize values by section and name, with APIs for multiple scalar, vector, and array types.
- DataBlock organization: A DataBlock maps a section name and value name to a generic stored value.Sections can contain cosmological parameters, CMB spectra, or intrinsic-alignment parameters, among other information.
- DataBlock organization: Modules and samplers use native DataBlock APIs available in C, Fortran, C++, and Python to read and write stored data.Introspection functions allow modules to choose context-dependent calculations based on available values.
- Sampler interface: Samplers connect to CosmoSIS through a base class that exposes the pipeline, configuration input, and output files, while subclasses implement setup, execution, and convergence checks.The architecture is presented as making new sampler contributions straightforward.
- API operations: Values are accessed through get, put, and replace operations keyed by section and name, with defaults and allocation options available for some types.C functions generally return a DATABLOCK_STATUS value.
- Language bindings: Language bindings preserve the same DataBlock model while adapting syntax: Fortran uses C bindings, Python uses DataBlock methods, and C++ uses templated methods.The examples include datablock_get_double, Python get/set syntax, and a templated put_val method.
Appendix F. Improving 2D KDE
CosmoSIS uses kernel density estimation to smooth MCMC samples for constraint plots, then modifies two-dimensional contour levels so their enclosed sample counts match the intended fractions.
- KDE method: Kernel density estimation smooths MCMC samples by placing a kernel over each sample and summing the kernels into a likelihood surface.The kernel covariance matrix or one-dimensional width is the main smoothing choice.
- KDE limitation: Standard KDE contours may enclose incorrect sample fractions such as 68% or 95% even when intended to represent the posterior surface.This mismatch is identified as an objection to KDE.
- CosmoSIS improvement: CosmoSIS retains the two-dimensional KDE shape but sets contour sizes by interpolating to enclose the correct number of MCMC samples.The procedure uses the KDE for contour shape and the samples for contour size.
Appendix G. Parameter consistency & alternate specifications
CosmoSIS supports alternate parameter specifications by deriving simple arithmetic relationships among parameters from any sufficient user-provided combination. Its iterative consistency checks detect conflicting recalculations or under-specified models.
- Parameterization choices affect prior specification and sampling efficiency, particularly when parameters have approximately Gaussian posteriors.
- CosmoSIS derives remaining parameters from any sufficient combination of user-specified parameters using an explicit relation set.This addresses simple arithmetic relationships; complex calculations such as deriving σ8 from As are distinguished separately.
- The algorithm represents parameter relationships as strings, identifies calculable parameters, and initializes unknown values as NaN before iterative evaluation.
- Each iteration fills newly calculable parameters and checks that recalculated values agree with existing values, raising an error on disagreement.
- If repeated evaluation leaves parameters unresolved, CosmoSIS reports that the model is under-specified and raises an error.