Euclid preparation. Cosmology Likelihood for Observables in Euclid (CLOE). 2. Code implementation

Abstract

We provide a description of the code implementation and structure of Cosmology Likelihood for Observables in Euclid (CLOE), developed by members of the Euclid Consortium. CLOE is a modular Python code for computing the theoretical predictions of cosmological observables and evaluating them against state-of-the-art data from galaxy surveys such as Euclid in a unified likelihood. This primarily includes the core observables of weak gravitational lensing, photometric galaxy clustering, galaxy-galaxy lensing, and spectroscopic galaxy clustering, but also extended probes such as the clusters of galaxies and cross-correlations of galaxy positions and shapes with the cosmic microwave background. While CLOE has been developed to serve as the unified framework for the parameter inferences in Euclid, it has general capabilities that can serve the broader cosmological community. It is different from other comparable cosmological tools in that it is written entirely in Python, performs the full likelihood calculation, and includes both photometric and spectroscopic observables. We will focus on the primary probes of Euclid and will describe the overall code structure, rigorous code development practices, extensive documentation, unique features, speed optimization, and future development plans. CLOE is publicly available at https://github.com/cloe-org/cloe.

Figures (15)

• Figure 1: Illustration of how the cosmological parameter constraints are obtained. The bottom-right inset is adapted from the forecasted results in Mellier24, produced with the cosmological inference pipeline CLOE.
• Figure 2: Illustration of the different types of CLOE users and their approaches to the code. The square brackets indicate that the argument is optional.
• Figure 3: Illustration of a subset of the configurations to be selected by the user as part of the theory and likelihood calculation, as described in Sect. . We note that the entries of a given key will be distinct for a given version of CLOE.
• Figure 4: Illustration of the structure of the interface between CLOE and Cobaya, encoded in cobaya_interface.py. The color coding takes on the following form: red denotes the CLOE module, pink denotes the CLOE class, gray denotes the Cobaya-required methods of the class, green denotes additional methods of the class, cyan denotes methods existing in other CLOE classes, and brown denotes Cobaya. The arrows represent the flow of information passed, for instance, from one method to another.
• Figure 5: Illustration of the structure of the interface between CLOE and CosmoSIS, encoded in cosmosis_interface.py. The color coding and arrows follow that of Fig. .