Table of contents

1. Overview
2. Installation of core packages
3. Installation and Compilation of external modules
4. Running Examples
5. Running ML emulators
6. Creating Cosmolike projects (external readme)
7. Credits

Common questions raised by developers

8. Appendices about Conda
   1. FAQ: How can users install Conda?
   2. FAQ: How can users install cocoa conda environment via conda-lock (better reproducibility)?
   3. FAQ: How can users deal with Conda conflicts (MacOS): a possible solution
9. Appendices about Git
   1. FAQ: How can developers develop from a Git tag?
   2. FAQ: How can developers push changes to the Cocoa main branch?
10. Appendices about Cocoa run
    1. FAQ: How can users debug Cocoa Installation? Suggested steps
    2. FAQ: How can users compile a single external module (not involving Cosmolike)?
    3. FAQ: How can users install Cosmolike projects?
    4. FAQ: How can users run Cocoa with Docker?
    5. FAQ: How can users set the appropriate environment for ML?
11. Advanced Appendices
    1. FAQ: How can users download additional likelihood data? (external readme)
    2. FAQ: Where do users find common FAQs about external modules? (external readme)
    3. FAQ: Where do users find common FAQs about Cosmolike? (external readme)
    4. FAQ: Note on Planck-2018 low-ell SimAll EE and Gibbs TT likelihoods?
    5. FAQ: How can users deal with pip getting stuck during installation (Linux): a possible cause
    6. FAQ: How can users run Cocoa on Google Colab?
    7. FAQ: How can developers improve their Bash/C/C++ knowledge?

Overview

Cocoa allows users to run CosmoLike routines inside the Cobaya framework. CosmoLike can analyze data from the Dark Energy Survey and simulate future multi-probe analyses for LSST and Roman Space Telescope.

Besides integrating Cobaya and CosmoLike, Cocoa introduces shell scripts that allow users to containerize Cobaya, the Boltzmann codes, and multiple likelihoods. The container structure of Cocoa ensures that users can adopt consistent versions for the Fortran/C/C++ compilers and libraries across multiple machines. Such a systematic approach greatly simplifies the debugging process.

Our scripts never install packages or Python modules in a global folder such as $HOME/.local. Here, $HOME denotes a shell environment variable that points to the user's home folder. Doing so would force cocoa packages to be global to the user, possibly breaking environments. Our scripts enable users to work on multiple Cocoa instances simultaneously, similar to what was possible with CosmoMC.

This Readme file presents basic and advanced instructions for installing all Cobaya and CosmoLike components on Linux or macOS-arm.

We provide the Docker image whovian-cocoa to facilitate the installation of Cocoa on Windows.

Why CoCoA? CoCoA is built on the principle that computational efficiency, usability, and ease of modification can coexist in a single framework. Its successful use across multiple beyond-LCDM investigations by small groups demonstrates that efficient code can cut the immense consumption of computer resources reported for recent large-impact analyses in the literature. This benefits theoretical groups, particularly those without routine access to large-scale supercomputers like NERSC. CoCoA also integrates closely with machine learning emulators, enabling preliminary research on laptops and workstations. The table below illustrates the efficiency of CoCoA compared to alternative pipelines

Installation of core packages

Core packages include compilers and numerical libraries that users typically do not modify.

Step 0️⃣ All the commands in this README assume a Bash shell. If your terminal is using zsh, switch to Bash now by typing

bash

Step 1️⃣: Choose the Cocoa version to be installed, and download the corresponding yml file

Warning

The version chosen here must be the same Cocoa version (git tag) cloned later in the section Installation and Compilation of external modules; the options below mirror the versions offered there. From v4.11.4 on, the yml files are named cocoapy311-* and provide Python-3.11; older tags carry cocoapy310-* files that provide Python-3.10.

• Linux

  • Legacy Version

    wget https://raw.githubusercontent.com/CosmoLike/cocoa/refs/tags/v4.053/cocoapy310.yml
    

  • Stable Version

    wget https://raw.githubusercontent.com/CosmoLike/cocoa/refs/tags/v4.072/cocoapy310.yml
    

  • Testing beta release

    wget https://raw.githubusercontent.com/CosmoLike/cocoa/refs/tags/v4.11.5/cocoapy311.yml
    

• macOS (arm)

  Users on macOS may not have wget installed. If that is the case, activate your base Conda environment and install it.

  conda activate
  conda install -y wget
  

  Then, download the yml file matching the chosen version.

  • Legacy Version

    wget https://raw.githubusercontent.com/CosmoLike/cocoa/refs/tags/v4.053/cocoapy310-osxarm-base.yml
    

  • Stable Version

    wget https://raw.githubusercontent.com/CosmoLike/cocoa/refs/tags/v4.072/cocoapy310-osxarm-base.yml
    

  • Testing beta release

    wget https://raw.githubusercontent.com/CosmoLike/cocoa/refs/tags/v4.11.5/cocoapy311-osxarm-base.yml
    

Step 2️⃣: Create the Cocoa environment (if the Legacy or Stable version was chosen in the previous step, replace cocoapy311 with cocoapy310 below),

• Linux

  conda env create --name cocoa --file=cocoapy311.yml
  

• macOS (arm)

  conda env create --name cocoa --file=cocoapy311-osxarm-base.yml
  

and activate it

conda activate cocoa

Step 3️⃣: When and only when loading the conda cocoa environment for the first time, create the following symbolic links

• Linux

  ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-gcc "${CONDA_PREFIX}"/bin/gcc
  ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-g++ "${CONDA_PREFIX}"/bin/g++
  ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-gfortran "${CONDA_PREFIX}"/bin/gfortran
  ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-gcc-ar "${CONDA_PREFIX}"/bin/gcc-ar
  ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-gcc-ranlib "${CONDA_PREFIX}"/bin/gcc-ranlib
  ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-ld "${CONDA_PREFIX}"/bin/ld
  

• macOS (arm)

  ln -s "${CONDA_PREFIX}"/bin/clang "${CONDA_PREFIX}"/bin/gcc
  ln -s "${CONDA_PREFIX}"/bin/clang++ "${CONDA_PREFIX}"/bin/g++
  

Step 4️⃣: When and only when loading the conda cocoa environment for the first time, install git-lfs

git-lfs install

Users can now proceed to the next section.

Tip

We advise users to avoid repositories managed by Anaconda due to licensing restrictions. See the Appendix FAQ: How can we install Conda?

Tip

If conda create hangs or fails, there are two possible solutions.

1. Install mamba and redo the creation of the cocoa env, explicitly selecting mamba as the dependency solver (e.g., Linux version)

   conda activate base
   conda install -n base -c conda-forge mamba
   mamba env create --name cocoa --file=cocoapy311.yml
   conda activate cocoa
   

2. If the hang happens at the Installing pip dependencies step, see the appendix FAQ: How can users deal with pip getting stuck during installation (Linux): a possible cause.

Tip

During the Arizona Winter School (January 2026), we noted that some students with macOS struggled to get the conda to work (conflicts). If this is the case for you, try the steps in the appendix FAQ: How can users deal with Conda conflicts (MacOS): a possible solution

Installation and Compilation of external modules

In this section, we assume users have previously activated the Cocoa conda environment.

Step 1️⃣: Download Cocoa's latest release and go to its main folder (cocoa/Cocoa),

• Legacy Version

  git clone https://github.com/CosmoLike/cocoa.git --branch v4.053 cocoa
  

• Stable Version

  git clone https://github.com/CosmoLike/cocoa.git --branch v4.072 cocoa
  

• Testing beta release

  git clone https://github.com/CosmoLike/cocoa.git --branch v4.11.5 cocoa
  

Warning

The version cloned here must match the version of the yml file downloaded in the section Installation of core packages.

Note

Version v4.11.1 includes significant cosmolike speed-ups from refactoring non-limber/C-FASTPT/cosmo2d modules.

Note

v4.11.1 benchmark: do not include CAMB (or the Hybrid Emulator); Includes TATT in ($\xi_{\pm}, \gamma_t$) and non-limber in $w_{gg}(\theta)$. CLOE-LIB caveat: We were not able to make TATT work on CloeLib. We were also not able to speed-up cloelib with OMP_NUM_THREADS flag

CPU: Intel(R) Core(TM) i9-10940X CPU @ 3.30GHz (1/8 OpenMP cores). Times are approximate.

• LSST-Y1-Real 3x2pt: (CoCoA) 0.29/0.06s, (DESC-CCL)7.96/1.72s, (CLOE-LIB) 0.23/0.23s. CoCoA speed-up (CCL): 27/28x
• Roman-Real 3x2pt: (CoCoA) 0.45/0.095s, (DESC-CCL) 8.17/1.96s, (CLOE-LIB) 0.27/0.27s. CoCoA speed-up (CCL): 18/20x
• Roman-Fourier 3x2pt: (CoCoA) 0.08/0.03s, (DESC-CCL) 0.65/0.36s. CoCoA speed-up: 7.5/21x
• DES-Y3xPlanck 6x2pt (CoCoA) 0.40/0.075s
• DES-Y3-Real 3x2pt (des_y3 repo) (CoCoA)~0.25/0.05s

How to record benchmarks on cosmolike projects?

• Go to EXAMPLE_EVALUATE2.yaml on each repository; Turn on TATT flag (IA_model: 1),
• Set N=10 on the evaluate sampler (Timing on N=1 is highly biased due to once per chain array allocation and initialization); Remove the override YAML block. The DESC-CCL-Benchmark scripts can be found here DESC-CCL uses flat-sky for fourier -> real transformation. If you know a module that implements curved sky transformation in CCL for a more 1x1 comparison, let us know.

and

cd ./cocoa/Cocoa

Step 2️⃣: Run the script setup_cocoa.sh via

source setup_cocoa.sh

This script downloads and decompresses external modules, which require internet access (on an HPC, this typically means running setup_cocoa.sh on the login node).

Cocoa does not install all the available external modules by default. If the user needs additional packages, please refer to the appendix FAQ: How can users compile external modules?.

Step 3️⃣: Run the script compile_cocoa.sh by typing

source compile_cocoa.sh

This script compiles external modules selected for installation on set_installation_options.sh (e.g., CAMB) and does not require internet access. Code compilation is CPU-intensive; therefore, running compile_cocoa.sh on a cluster login node may violate HPC policy. Users should then run setup_cocoa.sh in a login node and compile_cocoa.sh on an interactive compute node.

Users can now proceed to the next section.

Note

When rerunning setup_cocoa.sh, Cocoa will not redownload previously installed packages. To force this behavior, use --soft, --hard, --aggressive, --extreme, or --purge flags.

• --soft: force new download of the THEORY and ML script blocks (it spares cosmolike_core and all projects)
• --hard: force new download of THEORY, ML, and LIKELIHOOD script blocks (it spares cosmolike_core and all projects)
• --aggressive: force new download of THEORY, ML, LIKELIHOOD, and CORE script blocks (it spares cosmolike_core and all projects)
• --extreme: force new download of THEORY, ML, LIKELIHOOD, CORE, and DATA script blocks (it spares cosmolike_core and all projects)
• --purge: force new download of all packages (beware of the loss of uncommitted work associated with cosmolike_core and all projects)

Note

When rerunning compile_cocoa.sh, Cocoa will not recompile previously compiled packages, except for cosmolike projects. To force this behavior, use --soft, --hard, --aggressive, --extreme flags.

• --soft: recompile THEORY, ML script blocks and all Cosmolike Projects.
• --hard: recompile THEORY, ML and LIKELIHOOD script blocks and all Cosmolike Projects.
• --aggressive: recompile THEORY, ML, LIKELIHOOD, and CORE script blocks and all Cosmolike Projects.

Running Examples

We assume that users are still in the Conda cocoa environment from the previous conda activate cocoa command, and that users switch to bash, and that you are in the cocoa main folder cocoa/Cocoa.

Step 1️⃣: Activate the private Python environment by sourcing the script start_cocoa.sh

source start_cocoa.sh

Users will see a terminal like this: $(cocoa)(.local). This is a feature, not a bug!

Note

This is a feature, not a bug! Why did we choose to work with two distinct shell environments, (cocoa) and (.local)? Our scripts enable users to work on multiple Cocoa instances, similar to what was possible with CosmoMC. In each instance, our scripts install packages at

 Cocoa/.local/bin
 Cocoa/.local/include
 Cocoa/.local/lib
 Cocoa/.local/share

Step 2️⃣: Select the number of OpenMP cores (below, we set it to 8).

• Linux

  export OMP_NUM_THREADS=8; export OMP_PROC_BIND=close; \
  export OMP_PLACES=cores; export OMP_DYNAMIC=FALSE; \
  export OPENBLAS_NUM_THREADS=1; export MKL_NUM_THREADS=1
  

• macOS (arm)

  export OMP_NUM_THREADS=8; export OMP_PROC_BIND=disabled; \
  export OMP_PLACES=cores; export OMP_DYNAMIC=FALSE; \
  export OPENBLAS_NUM_THREADS=1; export MKL_NUM_THREADS=1
  

Examples not involving Cosmolike

Step 3️⃣: The folder projects/example contains a few examples involving different likelihoods. So, run the cobaya-run on the first example following the commands below.

Warning

(Linux only) In some HPC nodes, numa can cause you problems. If that is the case, replace numa with slot

• One model evaluation:

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 1 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by numa:pe=${OMP_NUM_THREADS} \
      cobaya-run ./projects/example/EXAMPLE_EVALUATE1.yaml -f
    

  • macOS (arm)

    mpirun -n 1 --oversubscribe \
      cobaya-run ./projects/example/EXAMPLE_EVALUATE1.yaml -f
    

• MCMC (Metropolis-Hastings Algorithm):

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 4 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by numa:pe=${OMP_NUM_THREADS} \
      cobaya-run ./projects/example/EXAMPLE_MCMC1.yaml -f
    

  • macOS (arm)

    mpirun -n 4 --oversubscribe \
      cobaya-run ./projects/example/EXAMPLE_MCMC1.yaml -f
    

Examples involving Cosmolike

Cocoa provides several Cosmolike projects, not all of which are installed by default. To activate them, please refer to the appendix FAQ: How can users compile external modules?.

Step 3️⃣: The folder projects/lsst_y1 contains a dozen examples involving different combinations of two-point correlation functions. So, run the cobaya-run on the first example following the commands below.

• One model evaluation:

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 1 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by numa:pe=${OMP_NUM_THREADS} \
      cobaya-run ./projects/lsst_y1/EXAMPLE_EVALUATE1.yaml -f
    

  • macOS (arm)

    mpirun -n 1 --oversubscribe \
      cobaya-run ./projects/lsst_y1/EXAMPLE_EVALUATE1.yaml -f
    

• MCMC (Metropolis-Hastings Algorithm):

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 4 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by numa:pe=${OMP_NUM_THREADS} \
      cobaya-run ./projects/lsst_y1/EXAMPLE_MCMC1.yaml -f
    

  • macOS (arm)

    mpirun -n 4 --oversubscribe \
      cobaya-run ./projects/lsst_y1/EXAMPLE_MCMC1.yaml -f
    

Running Jupyter Notebooks

Assuming Cocoa is installed on a local (not remote!) machine, type the command below after step 2️⃣ to run Jupyter Notebooks.

 jupyter notebook --no-browser --port=8888

The terminal will then show a message similar to the following template:

 (...)
 [... NotebookApp] Jupyter Notebook 6.1.1 is running at:
 [... NotebookApp] http://f0a13949f6b5:8888/?token=XXX
 [... NotebookApp] or http://127.0.0.1:8888/?token=XXX
 [... NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).

Now go to the local internet browser and type http://127.0.0.1:8888/?token=XXX, where XXX is the previously saved token displayed on the line

 [... NotebookApp] or http://127.0.0.1:8888/?token=XXX

The project lsst-y1 contains Jupyter notebook examples located at projects/lsst_y1.

Running ML emulators

Cocoa contains a few transformer- and CNN-based neural network emulators capable of simulating the CMB, cosmolike outputs, matter power spectrum, and distances. We provide a few scripts that exemplify their API. To run them, users ensure the following lines are commented out in set_installation_options.sh before running the setup_cocoa.sh and compile_cocoa.sh. By default, these lines should be commented out, but it is worth checking.

  [Adapted from Cocoa/set_installation_options.sh shell script] 
  # insert the # symbol (i.e., unset these environmental keys  on `set_installation_options.sh`)
  #export IGNORE_EMULTRF_CODE=1              #SaraivanovZhongZhu (SZZ) transformer/CNN-based emulators
  #export IGNORE_EMULTRF_DATA=1            
  #export IGNORE_LIPOP_LIKELIHOOD_CODE=1     # to run EXAMPLE_EMUL_(EVALUATE/MCMC/NAUTILUS/EMCEE1).yaml
  #export IGNORE_LIPOP_CMB_DATA=1           
  #export IGNORE_ACTDR6_CODE=1               # to run EXAMPLE_EMUL_(EVALUATE/MCMC/NAUTILUS/EMCEE1).yaml
  #export IGNORE_ACTDR6_DATA=1         
  #export IGNORE_NAUTILUS_SAMPLER_CODE=1     # to run PROJECTS/EXAMPLE/EXAMPLE_EMUL_NAUTILUS1.py
  #export IGNORE_POLYCHORD_SAMPLER_CODE=1    # to run PROJECTS/EXAMPLE/EXAMPLE_EMUL_POLY1.yaml
  #export IGNORE_GETDIST_CODE=1              # to run EXAMPLE_TENSION_METRICS.ipynb
  #export IGNORE_TENSIOMETER_CODE=1          # to run EXAMPLE_TENSION_METRICS.ipynb

Tip

We provide a few SLURM job script examples in the projects/example/script folder that help users to run the examples below on an HPC system.

Now, users must follow all the steps below.

Step 1️⃣: Activate the private Python environment by sourcing the script start_cocoa.sh

source start_cocoa.sh

Step 2️⃣: Ensure OpenMP is OFF.

export OMP_NUM_THREADS=1; export OPENBLAS_NUM_THREADS=1; export MKL_NUM_THREADS=1

Step 3️⃣ Run cobaya-run on the first emulator example following the commands below.

• One model evaluation:

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 1 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by slot \
      cobaya-run ./projects/example/EXAMPLE_EMUL_EVALUATE1.yaml -f
    

  • macOS (arm)

    mpirun -n 1 --oversubscribe \
      cobaya-run ./projects/example/EXAMPLE_EMUL_EVALUATE1.yaml -f
    

• MCMC (Metropolis-Hastings Algorithm):

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 4 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by slot \
      cobaya-run ./projects/example/EXAMPLE_EMUL_MCMC1.yaml -r
    

  • macOS (arm)

    mpirun -n 4 --oversubscribe \
      cobaya-run ./projects/example/EXAMPLE_EMUL_MCMC1.yaml -r
    

Note

The examples below may require a large number of MPI workers. Before running them, it may be necessary to increase the limit of threads that can be created (at UofA/SBU HPC type ulimit -u 1000000), otherwise users may encounter the error libgomp: Thread creation failed

• PolyChord:

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 90 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      -x PATH -x LD_LIBRARY_PATH -x PYTHONPATH -x CONDA_PREFIX -x ROOTDIR \
      -x OMP_NUM_THREADS -x OMP_PROC_BIND -x OMP_PLACES -x OMP_DYNAMIC \
      -x OPENBLAS_NUM_THREADS -x MKL_NUM_THREADS -x CLIK_PATH -x CLIK_DATA \
      -x CLIK_PLUGIN --mca mpi_yield_when_idle 1 \
      --mca btl_tcp_if_exclude lo,docker0,virbr0,ib0 \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by slot \
      cobaya-run ./projects/example/EXAMPLE_EMUL_POLY1.yaml -r
    

  • macOS (arm)

    mpirun -n 12 --oversubscribe \
      cobaya-run ./projects/example/EXAMPLE_EMUL_POLY1.yaml -r
    

Note

Running on more than one node. The flag --mca btl vader,tcp,self works unchanged across nodes (shared memory within a node, TCP between nodes). The commands that can run on more than one node already include the flags below.

1. --mca btl_tcp_if_exclude lo,docker0,virbr0,ib0: stop TCP from selecting an interface that is not routable between compute nodes.
2. -x PATH -x LD_LIBRARY_PATH (...): forward Cocoa's environment to ranks on remote nodes (needed under ssh-based launchers; Slurm forwards it automatically).
3. --map-by numa:pe=${OMP_NUM_THREADS}: reserve, on each rank, the cores its OpenMP threads will use. On Slurm, keep ntasks-per-node × cpus-per-task within the cores per node.
4. --mca mpi_yield_when_idle 1: make waiting MPI processes give up the CPU instead of burning 100% of a core; harmless when cores are not oversubscribed.

The Nautilus, Minimizer, Profile, and Emcee scripts below contain an internally defined yaml_string that specifies priors, likelihoods, and the theory code, all following Cobaya Conventions.

• Nautilus:

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 90 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      -x PATH -x LD_LIBRARY_PATH -x PYTHONPATH -x CONDA_PREFIX -x ROOTDIR \
      -x OMP_NUM_THREADS -x OMP_PROC_BIND -x OMP_PLACES -x OMP_DYNAMIC \
      -x OPENBLAS_NUM_THREADS -x MKL_NUM_THREADS -x CLIK_PATH -x CLIK_DATA \
      -x CLIK_PLUGIN --mca mpi_yield_when_idle 1 \
      --mca btl_tcp_if_exclude lo,docker0,virbr0,ib0 \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by slot \
      python -m mpi4py.futures ./projects/example/EXAMPLE_EMUL_NAUTILUS1.py \
        --root ./projects/example/ --outroot "EXAMPLE_EMUL_NAUTILUS1"  \
        --maxfeval 450000 --nlive 2048 --neff 15000 --flive 0.01 --nnetworks 5
    

  • macOS (arm)

    mpirun -n 12 --oversubscribe \
      python -m mpi4py.futures ./projects/example/EXAMPLE_EMUL_NAUTILUS1.py \
      --root ./projects/example/ --outroot "EXAMPLE_EMUL_NAUTILUS1"  \
      --maxfeval 450000 --nlive 2048 --neff 15000 --flive 0.01 --nnetworks 5
    

Note

What if the user runs an Nautilus chain with maxeval insufficient for producing neff samples? Nautilus creates a checkpoint at chains/outroot_checkpoint.hdf5.

• Emcee:

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 21 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      -x PATH -x LD_LIBRARY_PATH -x PYTHONPATH -x CONDA_PREFIX -x ROOTDIR \
      -x OMP_NUM_THREADS -x OMP_PROC_BIND -x OMP_PLACES -x OMP_DYNAMIC \
      -x OPENBLAS_NUM_THREADS -x MKL_NUM_THREADS -x CLIK_PATH -x CLIK_DATA \
      -x CLIK_PLUGIN --mca mpi_yield_when_idle 1 \
      --mca btl_tcp_if_exclude lo,docker0,virbr0,ib0 \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by slot \
      python ./projects/example/EXAMPLE_EMUL_EMCEE1.py --root ./projects/example/ \
        --outroot "EXAMPLE_EMUL_EMCEE1" --maxfeval 80000
    

  • macOS (arm)

    mpirun -n 12 --oversubscribe \
      python ./projects/example/EXAMPLE_EMUL_EMCEE1.py \
      --root ./projects/example/ --outroot "EXAMPLE_EMUL_EMCEE1" --maxfeval 80000
    

  The number of steps per MPI worker is $n_{\mathrm{sw}} = \mathrm{maxfeval}/n_{\mathrm{w}}$, with the number of walkers being $n_{\mathrm{w}}=\mathrm{max}(3n_{\mathrm{params}},n_{\mathrm{MPI}})$. For proper convergence, each walker should traverse 50 times its autocorrelation length ($\tau$), which is provided in the header of the output chain file. A reasonable rule of thumb is to assume $\tau > 200$ and therefore set $\mathrm{maxfeval} > 10,000 \times n_{\mathrm{w}}$.

  With these numbers, users may ask when Emcee is preferable to Metropolis-Hastings? Here are a few numbers based on a Planck CMB (l < 396) + SN + BAO + LSST-Y1 chain with 38 parameters in total.

  1. MH achieves convergence with $n_{\mathrm{sw}} \sim 150,000$, but only requires four walkers.
  2. Emcee has $\tau \sim 300$, so it requires $n_{\mathrm{sw}} \sim 15,000$ when running with $n_{\mathrm{w}}=114$.

  Conclusion: Emcee requires $\sim 3$ more evaluations in this case, but the number of evaluations per MPI worker (assuming one MPI worker per walker) is reduced by $\sim 10$. Therefore, Emcee seems well-suited for cases where the evaluation of a single cosmology is time-consuming (and there is no slow/fast decomposition).

Note

What if the user runs an Emcee chain with maxeval insufficient for convergence? Emcee creates a checkpoint at chains/outroot.h5.

• Sampler Comparison

  The script that generated the plot below is provided at projects/example/scripts/EXAMPLE_PLOT_COMPARE_CHAINS.py. The Google Colab notebook Example Sampler Comparison can also reconstruct a similar version of this figure.

  

• Global Minimizer:

  Our minimizer is a reimplementation of Procoli, developed by Karwal et al (arXiv:2401.14225)

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 21 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      -x PATH -x LD_LIBRARY_PATH -x PYTHONPATH -x CONDA_PREFIX -x ROOTDIR \
      -x OMP_NUM_THREADS -x OMP_PROC_BIND -x OMP_PLACES -x OMP_DYNAMIC \
      -x OPENBLAS_NUM_THREADS -x MKL_NUM_THREADS -x CLIK_PATH -x CLIK_DATA \
      -x CLIK_PLUGIN --mca mpi_yield_when_idle 1 \
      --mca btl_tcp_if_exclude lo,docker0,virbr0,ib0 \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by slot \
      python ./projects/example/EXAMPLE_EMUL_MINIMIZE1.py \
        --root ./projects/example/ \
        --outroot "EXAMPLE_EMUL_MIN1" \
        --nstw 200
    

  • macOS (arm)

    mpirun -n 12 --oversubscribe \
      python ./projects/example/EXAMPLE_EMUL_MINIMIZE1.py \
      --root ./projects/example/ \
      --outroot "EXAMPLE_EMUL_MIN1" \
      --nstw 200
    

  The number of steps per Emcee walker per temperature is $n_{\mathrm{stw}}$, and the number of walkers is $n_{\mathrm{w}}=\mathrm{max}(3n_{\mathrm{params}},n_{\mathrm{MPI}})$. The minimum number of total evaluations is then $3n_{\mathrm{params}} \times n_{\mathrm{T}} \times n_{\mathrm{stw}}$, which can be distributed among $n_{\mathrm{MPI}} = 3n_{\mathrm{params}}$ MPI processes for faster results. Do maintain $n_{\mathrm{stw}} > 200$ for reliable convergence in LCDM (see plot below). The same rule applies to Profile and Scan codes, as they are all based on the same minimization strategy.

  The script that generated the plot below is provided at projects/example/scripts/EXAMPLE_MIN_COMPARE_CONV.py. The Google Colab notebook Test Minimizer Convergence can also reconstruct a similar version of this figure.

  

  Below we show a case with $n_{\mathrm{param}} = 38$ that illustrates the need for performing convergence tests on a case-by-case basis. In this example, the total number of evaluations for a reliable minimum is approximately $319,200$ ($n_{\mathrm{stw}} \sim 700$), distributed among $n_{\mathrm{MPI}} = 114$ processes for faster results.

  

• Profile:

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 21 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      -x PATH -x LD_LIBRARY_PATH -x PYTHONPATH -x CONDA_PREFIX -x ROOTDIR \
      -x OMP_NUM_THREADS -x OMP_PROC_BIND -x OMP_PLACES -x OMP_DYNAMIC \
      -x OPENBLAS_NUM_THREADS -x MKL_NUM_THREADS -x CLIK_PATH -x CLIK_DATA \
      -x CLIK_PLUGIN --mca mpi_yield_when_idle 1 \
      --mca btl_tcp_if_exclude lo,docker0,virbr0,ib0 \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by slot \
      python ./projects/example/EXAMPLE_EMUL_PROFILE1.py \
        --root ./projects/example/ \
        --cov 'chains/EXAMPLE_EMUL_MCMC1.covmat' \
        --outroot "EXAMPLE_EMUL_PROFILE1" \
        --factor 3 --nstw 200 --numpts 10 --profile 1 \
        --minfile "./projects/example/chains/EXAMPLE_EMUL_MIN1.txt"
    

  • macOS (arm)

    mpirun -n 12 --oversubscribe \
      python ./projects/example/EXAMPLE_EMUL_PROFILE1.py \
      --root ./projects/example/ --cov 'chains/EXAMPLE_EMUL_MCMC1.covmat' \
      --outroot "EXAMPLE_EMUL_PROFILE1" \
      --factor 3 --nstw 200 --numpts 10 --profile 1 \
      --minfile "./projects/example/chains/EXAMPLE_EMUL_MIN1.txt"
    

    Profile provides the optional argument minfile, as it is significantly faster to run the profile script with a previously provided global minimum. The profile also provides the optional argument cov. Again, it is considerably more efficient to employ a covariance matrix from a converged chain.

    The argument factor specifies the start and end of the parameter being profiled:

      start value ~ minimum value - factor*np.sqrt(np.diag(cov))
      end   value ~ minimum value + factor*np.sqrt(np.diag(cov))
    

    We advise $\mathrm{factor} \sim 3$ for parameters that are well constrained by the data when a covariance matrix is provided. If cov is not supplied, the code estimates one internally from the prior. If a parameter is poorly constrained or cov is not given, we recommend $\mathrm{factor} \ll 1$.

    The script that generated the plot below is provided at projects/example/scripts/EXAMPLE_PLOT_PROFILE1.py. The Google Colab notebook Example Profile Likelihood can also reconstruct a similar version of this figure.

    

• Profile method 2:

  If the dimensionality of the problem is not large, and the spacing between values of the parameter being profiled is small, it can be considerably faster to use a simple scipy Nelder-Mead to calculate the profile. Here, the minfile and cov options are mandatory.

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 1 \
      --mca pml ob1 --mca btl vader,tcp,self \
      -x PATH -x LD_LIBRARY_PATH -x PYTHONPATH -x CONDA_PREFIX -x ROOTDIR \
      -x OMP_NUM_THREADS -x OMP_PROC_BIND -x OMP_PLACES -x OMP_DYNAMIC \
      -x OPENBLAS_NUM_THREADS -x MKL_NUM_THREADS -x CLIK_PATH -x CLIK_DATA \
      -x CLIK_PLUGIN --mca mpi_yield_when_idle 1 \
      --mca btl_tcp_if_exclude lo,docker0,virbr0,ib0 \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by slot \
      python ./projects/example/EXAMPLE_EMUL_PROFILE_SCIPY1.py \
        --root ./projects/example/ --cov 'chains/EXAMPLE_EMUL_MCMC1.covmat' \
        --outroot "EXAMPLE_EMUL_PROFILE1M2" --factor 3 --maxfeval 5000 --numpts 10 \
        --profile 1 --minfile "./projects/example/chains/EXAMPLE_EMUL_MIN1.txt"
    

  • macOS (arm)

    mpirun -n 1 python ./projects/example/EXAMPLE_EMUL_PROFILE_SCIPY1.py \
      --root ./projects/example/ --cov 'chains/EXAMPLE_EMUL_MCMC1.covmat' \
      --outroot "EXAMPLE_EMUL_PROFILE1M2" --factor 3 --maxfeval 5000 --numpts 10 \
      --profile 1 --minfile "./projects/example/chains/EXAMPLE_EMUL_MIN1.txt"
    

  The script that generated the plot below is provided at projects/example/scripts/EXAMPLE_PLOT_PROFILE1_COMP.py

  

• Scan:

  This profile code has a different MPI strategy. It scans one parameter on the entire prior, with each MPI being assigned to one minimization (not Emcee walker!). This is a strategy when probing beyond-LCDM parameters with oscillatory behavior (e.g., Monodromic Dark Energy).

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 90 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      -x PATH -x LD_LIBRARY_PATH -x PYTHONPATH -x CONDA_PREFIX -x ROOTDIR \
      -x OMP_NUM_THREADS -x OMP_PROC_BIND -x OMP_PLACES -x OMP_DYNAMIC \
      -x OPENBLAS_NUM_THREADS -x MKL_NUM_THREADS -x CLIK_PATH -x CLIK_DATA \
      -x CLIK_PLUGIN --mca mpi_yield_when_idle 1 \
      --mca btl_tcp_if_exclude lo,docker0,virbr0,ib0 \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by slot \
        python -m mpi4py.futures ./projects/example/EXAMPLE_EMUL_SCAN1.py \
          --root ./projects/example/ --outroot "EXAMPLE_EMUL_SCAN1" \
          --nstw 200 --profile 1
    

  • macOS (arm)

    mpirun -n 12 --oversubscribe \
      python -m mpi4py.futures ./projects/example/EXAMPLE_EMUL_SCAN1.py \
      --root ./projects/example/ --outroot "EXAMPLE_EMUL_SCAN1" \
      --nstw 200 --profile 1
    

• Tension Metrics

  We provide the Jupyter Notebook and the SLURM script, located at

  projects/example/EXAMPLE_EMUL_MCMC_TENSION_METRICS/EXAMPLE_TENSION_METRICS.ipynb
  projects/example/scripts/EXAMPLE_EMUL_TM.sbatch
  

  that exemplify how emulators can be used to quickly assess the tension between data sets. All Tension metrics were computed using the package Tensiometer.

  The plot below, taken from EXAMPLE_TENSION_METRICS.ipynb, exemplifies the tension between CMB+BAO vs. Type Ia SN.

Note

What about CosmoPower? CosmoPower is a suite of popular emulators developed by Prof. Alessio Mancini and collaborators. Our Cocoa port relies on the work done by Hidde Jense @HTJense (kudos to his/their work) as well as the Simons Observatory SOLikeT code. Even though they are not the suite of AI-powered emulators adopted by Cocoa developers, we do provide limited support for running them. To set up and compile Cosmopower and also the corresponding Cobaya Wrapper, comment the following keys before running setup_cocoa.sh and compile_cocoa.sh.

[Adapted from Cocoa/set_installation_options.sh shell script]
#export IGNORE_COSMOPOWER_DATA=1  
#export IGNORE_COSMOPOWER_CODE=1
(...)
export COSMOPOWER_URL="https://github.com/SBU-COSMOLIKE/cosmopower.git"
export COSMOPOWER_GIT_COMMIT="f70fc789426847eed996d707ec67a3a93d74bbc3"
(...)
# Edit below if you have your own set of CosmoPower Emulators
export COSMOPOWER_URL_DATA="https://github.com/cosmopower-organization/jense_2024_emulators.git"
export COSMOPOWER_URL_DATA_COMMIT="4317635eed70289ee1ec6b3df828027173071e36"

Running Hybrid Cosmolike-ML emulators

Our main line of research involves emulators that simulate the entire Cosmolike data vectors, and each project (LSST, Roman, DES) contains its own README with emulator examples. The speed of such emulators is incredible, especially when GPUs are available, and our emulators do take advantage of the CPU-GPU integration on Apple MX chips. For example, the average timing of lsst-y1 cosmic shear data vector emulation is around 0.005s ($\sim$ 200828 evaluations in $\sim$ 850.5 seconds) on a macOS M2 Pro.

While the data vector emulators are incredibly fast, there is an intermediate approach that emulates only the Boltzmann outputs (comoving distance, linear and nonlinear matter power spectrum). This hybrid-ML case can offer greater flexibility, especially in the initial phases of a research project, as changes to the modeling of nuisance parameters or to the assumed galaxy distributions do not require retraining of the network.

Examples in the hybrid case all have the prefix EXAMPLE_EMUL2 (note the 2). The required flags on set_installation_options.sh are similar to what we showed in the previous emulator section.

Now, users must follow all the steps below.

Step 1️⃣: Activate the private Python environment by sourcing the script start_cocoa.sh

source start_cocoa.sh

Step 2️⃣: Select the number of OpenMP cores.

• Linux

  export OMP_NUM_THREADS=8; export OMP_PROC_BIND=close; \
  export OMP_PLACES=cores; export OMP_DYNAMIC=FALSE; \
  export OPENBLAS_NUM_THREADS=1; export MKL_NUM_THREADS=1
  

• macOS (arm)

  export OMP_NUM_THREADS=8; export OMP_PROC_BIND=disabled; \
  export OMP_PLACES=cores; export OMP_DYNAMIC=FALSE; \
  export OPENBLAS_NUM_THREADS=1; export MKL_NUM_THREADS=1
  

Step 3️⃣: Remove GPU (idea is to run emulators on the CPU!)

• Linux

  export CUDA_VISIBLE_DEVICES=""
  

Step 4️⃣ Run cobaya-run on the first emulator example, following the commands below (here we only provide lsst-y1 examples).

• One model evaluation:

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 1 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
       --bind-to core:overload-allowed --report-bindings \
       --rank-by slot --map-by numa:pe=${OMP_NUM_THREADS} \
       cobaya-run ./projects/lsst_y1/EXAMPLE_EMUL2_EVALUATE1.yaml -f
    

  • macOS (arm)

    mpirun -n 1 --oversubscribe \
      cobaya-run ./projects/lsst_y1/EXAMPLE_EMUL2_EVALUATE1.yaml -f
    

• MCMC (Metropolis-Hastings Algorithm):

  • Linux

    "${CONDA_PREFIX}"/bin/mpirun -n 4 --oversubscribe \
      --mca pml ob1 --mca btl vader,tcp,self \
      --bind-to core:overload-allowed --report-bindings \
      --rank-by slot --map-by numa:pe=${OMP_NUM_THREADS} \
      cobaya-run ./projects/lsst_y1/EXAMPLE_EMUL2_MCMC1.yaml -r
    

  • macOS (arm)

    mpirun -n 4 --oversubscribe \
      cobaya-run ./projects/lsst_y1/EXAMPLE_EMUL2_MCMC1.yaml -r
    

Details on the matter power spectrum emulator designs will be presented in the emulator_code repository. Basically, we apply standard neural network techniques to generalize the syren-new Eq. 6 of arXiv:2410.14623 formula for the linear power spectrum (w0waCDM with a fixed neutrino mass of $0.06$ eV) to new models, extended ranges, or higher precision. Similarly, we use networks to generalize the syren-Halofit LCDM nonlinear boost fit (Eq. 11 of arXiv:2402.17492).

Note

Users can decide not to correct the syren-new formula for the linear power spectrum (flag in the yaml). Although we have not conducted extensive studies of the caveats of the syren-new approximation, it appears sufficient for w0waCDM forecasts when combined with the Euclid Emulator to compute the nonlinear boost.

For back-of-the-envelope LCDM calculations (e.g., to test cosmolike features), users can also choose not to correct the syren-Halofit formula for the LCDM nonlinear boost (see figure below). In this case, the overhead on top of cosmolike computations is minimum, at the order of $0.01$ seconds on a macOS M2Pro laptop.

Credits

• Acknowledgments:

  The entire CoCoA team is deeply grateful to everyone who has contributed to the development of our code.

  Special Thanks to:

  • Profs. Tim Eifler and Elisabeth Krause for their support of this idea since its inception in 2018 and all Cosmolike-related development.
  • Profs. Antony Lewis and Jesús Torrado for helping me understand Cobaya since its early days in 2019.
  • Jonathan Gordon, Joshua Kable, João Rebouças, Evan Saraivanov, Diogo Souza, Jiachuan Xu, Yijie Zhu, and KunHao Zhong for working on CoCoA on many fruitful projects at Stony Brook Univ. and the Univ. of Arizona.
  • Evan Saraivanov, Yijie Zhu, and KunHao Zhong for developing the emulator interface within the CoCoA framework (and training emulators).
  • Victoria Loyd for developing the hybrid-emulator interface within the CoCoA framework (and training emulators).
  • Haley Bowden, Kali Cao, Nihar Dalal, Yu-Hsiu Huang, Niko, Junzhou Zhang, and members of the Roman HLIS Cosmology PIT for all Roman-specific development and testing.

The following is not an exhaustive list of the codes we use/download/adopt

• Cobaya is a framework developed by Dr. Jesus Torrado and Prof. Anthony Lewis
• Cosmolike is a framework developed by Prof. Elisabeth Krause and Prof. Tim Eifler
• CAMB is a Boltzmann code developed by Prof. Anthony Lewis
• CLASS is a Boltzmann code developed by Prof. Julien Lesgourgues and Dr. Thomas Tram
• Polychord is a sampler code developed by Dr. Will Handley, Prof. Lasenby, and Prof. M. Hobson
• CLIK is the likelihood code used to analyze Planck and SPT data, maintained by Prof. Karim Benabed
• SPT is the official likelihood of the South Pole Telescope 3G Year 1
• MFLike is the official likelihood of the Simons Observatory
• ACTLensing is the official lensing likelihood of the ACT collaboration, developed by Prof. Mathew Madhavacheril
• HiLLiPoP CMB likelihood is a multifrequency CMB likelihood for Planck data.
• Lollipop CMB likelihood is a Planck low-l polarization likelihood.

Following best practices, Cocoa scripts download most external modules from their original repositories. Although our repository includes a few likelihoods in compressed xz file format, we do not want to discourage users from cloning code and data from their original repositories. The work of those authors is extraordinary, and users must cite them appropriately.

Appendices about Conda

⁉️ FAQ: How can users install Conda?

Step 1️⃣: Download and run the Miniforge installation script.

export CONDA_DIR="/gpfs/home/XXX/miniforge" # replace this string!

and

mkdir "${CONDA_DIR:?}"

and

curl -L -O "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh"

and

/bin/bash Miniforge3-$(uname)-$(uname -m).sh -f -b -p "${CONDA_DIR:?}"

and

/bin/bash 

Step 2️⃣: After installation, users must source the conda configuration file, as shown below:

source $CONDA_DIR/etc/profile.d/conda.sh \
      && conda config --set auto_update_conda false \
      && conda config --set show_channel_urls true \
      && conda config --set auto_activate_base false \
      && conda config --prepend channels conda-forge \
      && conda config --add allowlist_channels conda-forge \
      && conda config --set channel_priority strict \
      && conda init bash

Note

The strict use of Miniforge and conda-forge packages appears to mitigate the significant licensing issue involving Anaconda packages and academic/research institutions.

Step 3️⃣: After running this command, you will see a message in the terminal that ends with the statement For changes to take effect, close and re-open your current shell. Then, type

source ~/.bashrc

After that, the conda command will be available.

⁉️ FAQ: How can users install conda env via conda-lock?

We advise users to maintain exact reproducibility (across time) of the Cocoa conda environment by installing it via conda-lock, following the slightly more convoluted instructions below.

Step 1️⃣ Install the package conda-lock in a private conda environment to avoid conflicts.

 conda create -n lockenv -c conda-forge python=3.10 conda-lock=2.* wget

and

 conda activate lockenv

Step 2️⃣ Download the appropriate conda-lock compatible yml file. As in the section Installation of core packages, replace the tag v4.11.5 in the URL with the Cocoa version that will be cloned (tags older than v4.11.4 carry the cocoapy310 prefix).

• Linux

  wget https://raw.githubusercontent.com/CosmoLike/cocoa/refs/tags/v4.11.5/cocoapy311-linux.yml
  

• macOS (arm)

  wget https://raw.githubusercontent.com/CosmoLike/cocoa/refs/tags/v4.11.5/cocoapy311-osxarm.yml
  

Step 3️⃣ Create the conda environment

• Linux

  conda-lock install -n cocoa cocoapy311-linux.yml
  

• macOS (arm)

  conda-lock install -n cocoa cocoapy311-osxarm.yml   
  

and activate it

 conda activate cocoa

⁉️ FAQ: How can users deal with Conda conflicts (MacOS): a possible solution

During the Arizona Winter School (January 2026), we noted that some students with macOS struggled to get Conda to work (conflicts). If this is the case for you, try the steps below instead

Step 1️⃣ Create a new base environment, as your base may have legacy packages that can create incompatibilities (note here slightly modified conda command)

 conda create --solver=libmamba --strict-channel-priority --override-channels -c conda-forge --name base2

and

 conda activate base2

Step 2️⃣ Now install wget and download a looser version of the yml file (note here slightly modified conda command). As in the section Installation of core packages, replace the tag v4.11.5 in the URL with the Cocoa version that will be cloned (tags older than v4.11.4 carry the cocoapy310 prefix).

 conda install -y wget --solver=libmamba --strict-channel-priority --override-channels -c conda-forge

and

 wget https://raw.githubusercontent.com/CosmoLike/cocoa/refs/tags/v4.11.5/cocoapy311-osxarm-loose.yml

Step 3️⃣ Create the cocoa conda env using a looser yml (note here slightly modified conda command)

conda env create --solver=libmamba --name cocoa -f cocoapy311-osxarm-loose.yml

Appendices about Git

⁉️ FAQ: How can developers develop from a Git tag?

A useful Git hack concerns developing Cocoa from a Git tag.

Git tags set milestones in our development, so they serve as good starting points for coding new features or implementing bug fixes. When you check out a tag, Git places you in a detached HEAD state. So, before making further commits, you must create a local branch from that tag.

Step 1️⃣ (optional) If the repository was cloned with the https URL, switch origin to the SSH-based URL address (assuming your public key is already registered on GitHub)

git remote set-url origin git@github.com:CosmoLike/cocoa.git # that would allow users to push without typing a password

Tip

This step covers the Cocoa repository itself. For the Cosmolike/Emulator repositories, set SWITCH_TO_DEV_MODE=1 on set_installation_options.sh before setup_cocoa.sh, and they are cloned via SSH from the start (see FAQ: How can users install Cosmolike projects?).

Step 2️⃣ (optional) check the names of remote branches so you can create a unique branch name from the checked-out tag

git remote set-branches origin '*'

and

git fetch origin -v

This will display all remote branches in the terminal. The output will resemble the following snippet

[Adapted from the terminal output of git fetch origin -v] 
(...)
From https://github.com/CosmoLike/cocoa
 = [up to date]        CMB_bp        -> origin/CMB_bp
 = [up to date]        cocoa_emu     -> origin/cocoa_emu
 = [up to date]        demu          -> origin/demu
 = [up to date]        dev           -> origin/dev

Step 3️⃣ Create a new local working branch from the checked-out tag:

git switch -c xyzlocdev

Choose a unique name that does not already exist as a branch in the remote repository. A practical convention is to use your initial, followed by suffix such as locdev.

Now, all subsequent commits will be associated with the xyzlocdev local branch.

Step 4️⃣ The developer has two options at the end of development. They can either

• Create a new remote branch

  git push origin xyzlocdev # run on the xyzlocdev branch
  

• Fetch and download the already existing remote xyzdev branch, which will later absorb the changes made on xyzlocdev

  git switch -c xyzdev origin/xyzdev # run on the xyzlocdev branch
  

  Then, squash-merge the changes made on xyzlocdev.

  git merge --squash xyzlocdev # run on the xyzdev branch
  

  If this merge does not create any merge conflicts, then type

  git push origin xyzdev # run on the xyzdev branch
  

⁉️ FAQ: How can developers push changes to the Cocoa main branch?

The main branch is protected: a commit in the main branch should contain an atomic change that takes code from one working state to another working state with meaningful and well-tested improvements. Therefore, developers should propose changes to the main branch in larger chunks (via squash commits), as shown below.

Note

In a developer branch, users are encouraged to make small commits so that work can be tracked easily. Our policy regarding squash atomic changes only applies to the main branch.

• ⁉️ How to apply squash commits?

Step 1️⃣: create a development branch. Do not call the development branch dev, as dev is reserved for work done by the leading Cocoa developers. For concreteness, let's name the new branch xyzdev

git switch -c xyzdev  # run on the main branch

Tip

The use of developers' initials followed by dev helps make the branch easily identifiable.

Tip

If the branch xyzdev already exists, use the git switch command without the -c flag.

Step 2️⃣: develop the proposed changes. We advise developers to commit frequently. In your branch, a commit does not need to be atomic, changing the code from one working state to another well-tested, meaningful working state. Developers can push to the server via the command.

git push -u origin xyzdev   # run on the xyzdev branch

Step 3️⃣: Once the developers have created an atomic, meaningful, and well-tested improvement to Cocoa, the developer needs to merge any subsequent changes made in main.

git merge main   # run on the xyzdev branch

This step may create conflicts that must be addressed before step four.

Step 4️⃣: Once the developers have merged recent changes made on the main branch, they must push to the main branch the modifications made on the xyzdev branch by first squashing all your changes into a single commit, as shown below

git switch main  # run on the xyzdev branch

and

git merge --squash xyzdev   # run on the main branch

and

git commit -m "merge xyzdev branch"  # run on the main branch

and

git push origin main  # run on the main branch

Appendices about Cocoa run

⁉️ FAQ: How can users debug Cocoa Installation? Suggested steps

Step 1️⃣: define the COCOA_OUTPUT_VERBOSE and COSMOLIKE_DEBUG_MODE flags on set_installation_options.sh to obtain a more detailed output, as shown below (for even more output, define COCOA_OUTPUT_DEBUG as well)

  [Adapted from Cocoa/set_installation_options.sh shell script] 
  # ------------------------------------------------------------------------------
  # VERBOSE AS DEBUG TOOL --------------------------------------------------------
  # ------------------------------------------------------------------------------
  export COCOA_OUTPUT_VERBOSE=1
  #export COCOA_OUTPUT_DEBUG=1 # turn on bash strict mode (set -exo pipefail) on  
                               # instalation_scripts/setup/compile_x.sh scripts 
  # ------------------------------------------------------------------------------
  # If set, COSMOLIKE will compile with DEBUG flags ------------------------------
  # ------------------------------------------------------------------------------
  export COSMOLIKE_DEBUG_MODE=1
  (...)

Step 2️⃣: restart the Cocoa private environment by rerunning source start_cocoa.sh (every time users edit set_installation_options.sh, they must reload the (.local) environment by rerunning start_cocoa.sh).

Step 3️⃣: rerun setup_cocoa.sh and compile_cocoa.sh.

⁉️ FAQ: How can users compile a single external module (not involving Cosmolike)?

To download and compile only a single module (e.g., CAMB), users must directly run the associated bash scripts in Cocoa/installation_scripts/ directly (e.g., setup_camb.sh and compile_camb.sh).

Users must also ensure the appropriate keys in set_installation_options.sh are unset, as shown below.

 [Adapted from Cocoa/set_installation_options.sh shell script]
 # ------------------------------------------------------------------------------
 # The flags below allow users to skip downloading specific datasets ------------
 # ------------------------------------------------------------------------------
 #export IGNORE_ACTDR6_DATA=1                  # ACT-DR6 likelihood data
 (...)
 #export IGNORE_SIMONS_OBSERVATORY_CMB_DATA=1  # SO likelihood data
 (...)
 # ------------------------------------------------------------------------------
 # The keys below control which packages will be installed and compiled 
 # ------------------------------------------------------------------------------
 #export IGNORE_SIMONS_OBSERVATORY_LIKELIHOOD_CODE=1     # SO likelihood code
 (...)
 #export IGNORE_ACTDR6_CODE=1                            # ACT-DR6 likelihood code

Whenever users edit set_installation_options.sh, they must reload the Cocoa private environment (.local) by sourcing start_cocoa.sh (even if (.local) is already active). To do that, follow the commands below.

 cd ./cocoa/Cocoa

and

 source start_cocoa.sh # even if (.local) is already active, users must run start_cocoa.sh again to update bash environment values

Similar to setup_cocoa.sh and compile_cocoa.sh, each package contains its own setup script that downloads it from the internet and compile scripts that compile it. For example, the ACT-DR6 likelihood code can be downloaded and installed via the bash commands

 source ./installation_scripts/setup_act_dr6.sh                # download likelihood code

and

 source ./installation_scripts/compile_act_dr6.sh              # compile likelihood code

In addition to setup and compile scripts, Cocoa contains unxv scripts that download large data sets. For instance, to download the ACT-DR6 data, users must source the script

 source ./installation_scripts/unxv_act_dr6.sh                 # download and unpack likelihood data

⁉️ FAQ: How can users install Cosmolike projects?

The script set_installation_options.sh includes instructions for installing several Cosmolike-based projects; the keys below are commented out by default, meaning all projects are installed. To skip a project, remove the symbol # from its corresponding key.

 [Adapted from Cocoa/set_installation_options.sh shell script]
 # ------------------------------------------------------------------------------
 # The keys below control which cosmolike projects will be installed and compiled
 # ------------------------------------------------------------------------------
 #export IGNORE_COSMOLIKE_LSST_Y1_CODE=1
 #export IGNORE_COSMOLIKE_DES_Y3_CODE=1
 #export IGNORE_COSMOLIKE_DESXPLANCK_CODE=1
 #export IGNORE_COSMOLIKE_ROMAN_FOURIER_CODE=1
 #export IGNORE_COSMOLIKE_ROMAN_REAL_CODE=1
 #export IGNORE_COSMOLIKE_ROMAN_KL_CODE=1
 (...)
 # ------------------------------------------------------------------------------
 # OVERWRITE_EXISTING_XXX_CODE=1 -> setup_cocoa overwrites existing PACKAGES ----
 # overwrite: delete the existing PACKAGE folder and install it again -----------
 # redownload: delete the compressed file and download data again ---------------
 # These keys are only relevant if you run setup_cocoa multiple times -----------
 # ------------------------------------------------------------------------------
 (...)
 export OVERWRITE_EXISTING_COSMOLIKE_CODE=1 # dangerous (possible loss of uncommitted work)
                                            # If unset, users must manually delete cosmolike projects
 (...)
 # ------------------------------------------------------------------------------
 # Cosmolike projects below -------------------------------------------
 # ------------------------------------------------------------------------------
 (...)
 export ROMAN_REAL_URL="https://github.com/CosmoLike/cocoa_roman_real.git"
 export ROMAN_REAL_NAME="roman_real"
 #Pin the project version with at most one of the keys below (COMMIT, BRANCH, or TAG).
 #If more than one is set, COMMIT wins over BRANCH, and BRANCH wins over TAG.
 #If none is set, Cocoa loads the latest commit on the repository default branch.
 #export ROMAN_REAL_GIT_BRANCH="main"
 #export ROMAN_REAL_GIT_COMMIT="abc"
 export ROMAN_REAL_GIT_TAG="v4.10.9"

Note

The https URLs are the right choice for almost all users. Developers with write access to the Cosmolike/Emulator repositories can clone them via SSH keys instead by setting the key below on set_installation_options.sh.

[Adapted from Cocoa/set_installation_options.sh shell script]
# ------------------------------------------------------------------------------
# If set, clone Cosmolike/Emulator repos via SSH (developers with write access)
# ------------------------------------------------------------------------------
#export SWITCH_TO_DEV_MODE=1

Once more, anytime set_installation_options.sh is modified, we need to reload (.local) by rerunning start_cocoa.sh. Then, run the following commands:

  cd ./cocoa/Cocoa

and

  source start_cocoa.sh # even if (.local) is already active, users must run start_cocoa.sh again to update bash environment values

Now, to download and compile all Cosmolike projects, type

  source ./installation_scripts/setup_cosmolike_projects.sh   # download all cosmolike projects  

and

  source ./installation_scripts/compile_all_projects.sh       # compile all cosmolike projects

Note

In case users need to rerun setup_cocoa.sh (or setup_cosmolike_projects.sh) , Cocoa will not download previously installed cosmolike projects (this avoids loss of uncommitted work), unless the following key is set on set_installation_options.sh

[Adapted from Cocoa/set_installation_options.sh shell script]
#export OVERWRITE_EXISTING_COSMOLIKE_CODE=1 # dangerous (possible loss of uncommitted work)
                                            # if unset, users must manually delete cosmolike projects

In case users only want to compile a single Cosmolike project (let's say the roman_real project)

  source ./projects/roman_real/scripts/compile_roman_real.sh

⁉️ FAQ: How can users run Cocoa with Docker?

We provide the Docker image whovian-cocoa to facilitate installing Cocoa on Windows and macOS. This appendix assumes that users have already installed the Docker Engine on their local PC. For instructions on installing the Docker engine on specific operating systems, refer to Docker's official documentation.

Step 1️⃣: Create a folder and go to the location on the host computer where you want to provide access to the Docker container, as shown below.

 mkdir -p cocoa_docker
 cd ./cocoa_docker

Step 2️⃣: Download the Docker image whovian-cocoa, name the associated container cocoa2025 (flag --name cocoa2025 in the command below), and run the container for the first time, type:

docker run --platform linux/amd64 --hostname cocoa --name cocoa2025 -it -p 8888:8888 -v $(pwd):/home/whovian/host/ -v ~/.ssh:/home/whovian/.ssh:ro vivianmiranda/whovian-cocoa:thin

Warning

There is a weird bug on macOS that Mathplotlib does not work unless you add the flags -e EXPERIMENTAL_DOCKER_DESKTOP_FORCE_QEMU=1 -e PYTHONUNBUFFERED=1 right after docker run --platform linux/amd64

This is a large image, approximately 13GB, as it already contains the conda cocoa environment. Users can now proceed to the Installation and Compilation of external modules section to continue the installation.

Tip

Once installation is complete, the user must learn how to start and exit the Docker container. Assuming the user maintained the container name cocoa2025 set on the flag --name cocoa2025, type:

 docker start -ai cocoa2025

to restart the container.

Tip

To run Jupyter Notebooks within the whovian-cocoa Docker container installed on a local machine, type the following command:

 jupyter notebook --no-browser --port=8888

The terminal will show a message similar to the following template:

 [... NotebookApp] Writing notebook server cookie secret to /home/whovian/.local/share/jupyter/runtime/notebook_cookie_secret
 [... NotebookApp] WARNING: The notebook server is listening on all IP addresses and not using encryption. This is not recommended.
 [... NotebookApp] Serving notebooks from local directory: /home/whovian/host
 [... NotebookApp] Jupyter Notebook 6.1.1 is running at:
 [... NotebookApp] http://f0a13949f6b5:8888/?token=XXX
 [... NotebookApp] or http://127.0.0.1:8888/?token=XXX
 [... NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).

Now go to the local internet browser and type http://127.0.0.1:8888/?token=XXX, where XXX is the previously saved token displayed on the line

[... NotebookApp] or http://127.0.0.1:8888/?token=XXX  

Tip

To run the Jupyter Notebook on the whovian-cocoa docker container installed on a remote server, adjust the command below

ssh your_username@your_sever.com -L 8888:localhost:8888

before typing http://127.0.0.1:8888/?token=XXX on the local desktop/laptop. This will bind the server port 8888 to the local port 8888.

[... NotebookApp] or http://127.0.0.1:8888/?token=XXX  

Tip

To delete a particular container, assuming the container name cocoa2025, type

 docker rm -f cocoa2025

Tip

The flag -v $(pwd):/home/whovian/host/ in the docker run command ensures that files in the host computer located within the folder where the Docker container was initialized are accessible inside the container.

Warning

Do not allow the Docker container to have system-wide access to your files. Accidents happen, especially when dealing with dangerous bash commands such as rm (deletion).

Note

The recipe of the whovian-cocoa image is maintained at cocoa_installation_libraries/docker/. To rebuild and publish the image (developers only), type

cd ./cocoa/cocoa_installation_libraries/docker

and

docker build . --build-arg COCOA_TAG=v4.11.5 -t vivianmiranda/whovian-cocoa # replace the tag with the Cocoa version whose yml seeds the conda env

and

docker push vivianmiranda/whovian-cocoa

To publish the :thin variant, run the container, install and compile Cocoa inside it, and type

docker commit <containerid> vivianmiranda/whovian-cocoa:thin # docker ps -a shows the container id

and

docker push vivianmiranda/whovian-cocoa:thin

⁉️ FAQ: How can users set the appropriate environment for ML?

By default, Cocoa installs several machine-learning-related libraries via pip; the keys below control this installation. To skip the GPU-based ML libraries, uncomment IGNORE_EMULATOR_GPU_PIP_PACKAGES. GPU users must also select the CUDA generation that matches their hardware.

[Adapted from Cocoa/set_installation_options.sh shell script] 
# ------------------------------------------------------------------------------
# If not set, pip_core_packages.sh will install several ML packages ------------
# ------------------------------------------------------------------------------
#export IGNORE_EMULATOR_GPU_PIP_PACKAGES=1
# New GPUs require cuda 13 / Old GPUs may still require cuda 11.8 --------------
#export ML_BLEEDING_EDGE_LIBS=1
#export ML_LEGACY_LIBS=1
(...)

If users have already run setup_cocoa.sh prior to commenting these flags, run the command.

source start_cocoa.sh # even if (.local) is already active, users must run start_cocoa.sh again to update bash environment values

and

source ./installation_scripts/setup_pip_core_packages.sh

Additional Appendices

⁉️ FAQ: Note on Planck-2018 low-ell SimAll EE and Gibbs TT likelihoods

Cocoa does not adopt Cobaya's Python reimplementation of SimAll EE and Gibbs TT likelihoods. Therefore, we patch the files.

cobaya/cobaya/likelihoods/planck_2018_lowl/TT.py
cobaya/cobaya/likelihoods/planck_2018_lowl/EE.py

to call the original Planck-2018 Clik likelihoods, as shown below.

[Adapted from Cocoa/cobaya/cobaya/likelihoods/planck_2018_lowl/TT.py]
from cobaya.likelihoods.base_classes import Planck2018Clik

#COCOA BEGINS
#class TT_clik(Planck2018Clik):
class TT(Planck2018Clik):
#COCOA ENDS
    r"""
    Low-$\ell$ temperature-only likelihood of Planck's 2018 data release
    """
    pass

and

[Adapted from Cocoa/cobaya/cobaya/likelihoods/planck_2018_lowl/EE.py]
from cobaya.likelihoods.base_classes import Planck2018Clik

#COCOA BEGINS
#class EE_clik(Planck2018Clik):
class EE(Planck2018Clik):
#COCOA ENDS
    r"""
    Low-$\ell$ EE likelihood of Planck's 2018 data release
    """

This ensures backward consistency in our code, as TT.py and EE.py used to point to Planck-2018 Clik before Cobaya's authors moved them to EE_clik.py and TT_clik.py.

⁉️ FAQ: How can users deal with pip getting stuck during installation (Linux): a possible cause

On some machines, the step Installing pip dependencies hangs (mamba shows repeated Failed to establish a new connection warnings). A possible cause: pip is configured with the retired NVIDIA index pypi.ngc.nvidia.com, planted by the nvidia-pyindex package (which Cocoa's machine-learning setup installed before v4.11.4). If that is the case, follow the steps below.

Step 1️⃣: Locate the pip configuration files

python3 -m pip config list -v

Step 2️⃣: Remove the extra-index-url and trusted-host entries that point to pypi.ngc.nvidia.com

sed -i '/extra-index-url/,+1d; /trusted-host/,+1d' ~/.pip/pip.conf ~/.config/pip/pip.conf

Step 3️⃣: Remove the pip.conf files located on older Cocoa installations (they take priority whenever that (.local) environment is active)

rm -f <old cocoa>/Cocoa/.local/pip.conf

Step 4️⃣: In case the interrupted installation already finished the conda stage, rerun only the pip stage

conda env update --name cocoa --file=cocoapy311.yml

⁉️ FAQ: How can users run Cocoa on Google Colab?

Google Colab provides a convenient platform for users to run MCMCs, likelihood minimizations, and profiles, as long as Machine-Learning Emulators are used to compute the data vectors. In the repository CoCoAGoogleColabExamples, we provide a few examples along with explanatory notes.

Installing Cocoa requires time and also strains our limited Git-LFS quota, which is especially relevant given that the entire local drive is wiped when a Colab notebook is disconnected. To prevent this problem, we provide instructions for saving and loading Cocoa immediately after the initial installation.

There are a few differences users should be aware of when running Cocoa on Google Colab.

• Running Colab Notebook for the first time

  • Cell 1️⃣: Connect the notebook to your Google Drive account (will be important later)

    from google.colab import drive
    drive.mount('/content/drive')
    

  Below, we provide instructions on how to install Cocoa. Google Colab does provide direct terminal access if users prefer to follow the standard installation procedure

  • Cell 2️⃣: Install Miniforge (Similar to our documentation in section FAQ: How can users install Conda?)

    %%bash
    export CONDA_DIR="/content/conda"
    mkdir "${CONDA_DIR:?}"
    curl -L -O "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh"
    /bin/bash Miniforge3-$(uname)-$(uname -m).sh -f -b -p "${CONDA_DIR:?}"
    /bin/bash
    source $CONDA_DIR/etc/profile.d/conda.sh \
          && conda config --set auto_update_conda false \
          && conda config --set show_channel_urls true \
          && conda config --set auto_activate_base false \
          && conda config --prepend channels conda-forge \
          && conda config --add allowlist_channels conda-forge \
          && conda config --set channel_priority strict \
          && conda init bash
    source ~/.bashrc
    

  • Cell 3️⃣: Install Conda cocoa env (similar to our documentation in section Installation of core packages)

    %%bash
    source "/content/conda/etc/profile.d/conda.sh"
    conda create -y -n lockenv -c conda-forge python=3.10 conda-lock=2.* wget
    conda activate lockenv
    wget https://raw.githubusercontent.com/CosmoLike/cocoa/refs/tags/v4.11.5/cocoapy311-linux.yml
    conda-lock install -n cocoa cocoapy311-linux.yml
    conda activate cocoa 
    ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-gcc "${CONDA_PREFIX}"/bin/gcc
    ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-g++ "${CONDA_PREFIX}"/bin/g++
    ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-gfortran "${CONDA_PREFIX}"/bin/gfortran
    ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-gcc-ar "${CONDA_PREFIX}"/bin/gcc-ar
    ln -s "${CONDA_PREFIX}"/bin/x86_64-conda-linux-gnu-gcc-ranlib "${CONDA_PREFIX}"/bin/gcc-ranlib
    git-lfs install
    

  • Cell 4️⃣: Clone CoCoA (similar to our documentation in section Installation and Compilation of external modules)

    %%bash
    source "/content/conda/etc/profile.d/conda.sh"
    conda activate cocoa                                  
    git clone https://github.com/CosmoLike/cocoa.git --branch v4.11.5 cocoa # replace the tag with the Cocoa version being installed (it must match the yml downloaded on Cell 3)
    

  • Cell 5️⃣: run setup_cocoa.sh

     %%bash
     source "/content/conda/etc/profile.d/conda.sh" 
     conda activate cocoa
     cd ./cocoa/Cocoa/
     source setup_cocoa.sh
    

  • Cell 6️⃣: run compile_cocoa.sh

    %%bash
    source "/content/conda/etc/profile.d/conda.sh"
    conda activate cocoa
    cd ./cocoa/Cocoa/
    source compile_cocoa.sh
    

  • Cell 7️⃣: Save Cocoa on Drive (does not work with local runtime)

    %%bash
    DEST="/content/drive/MyDrive/ColabBackups"
    ARCHIVE="$DEST/colab_basic_cocoa.tar.gz"
    if [[ -f "$ARCHIVE" ]]; then
      echo "Backup already exists: $ARCHIVE — skipping."
      exit 0
    fi
    mkdir -p "$DEST"
    tar -czf "$DEST/colab_basic_cocoa.tar.gz" \
      --exclude='/content/drive' \
      --exclude='**/__pycache__' \
      --exclude='**/.ipynb_checkpoints' \
      /content
    echo "Created: $ARCHIVE"
    

• Running Colab Notebook with Cocoa pre-installed, loaded from Drive (does not work with local runtime)

  • Cell 1️⃣: Connect the notebook to your Google Drive account

    from google.colab import drive
    drive.mount('/content/drive')
    

  • Cell 2️⃣: Load Cocoa from Drive

    %%bash
    DEST="/content/drive/MyDrive/ColabBackups"
    ARCHIVE="$DEST/colab_basic_cocoa.tar.gz"
    SENTINEL="/content/conda/etc/profile.d/conda.sh"  # exists when your env is restored
    if [[ -e "$SENTINEL" ]]; then
      echo "Found $SENTINEL — environment already restored. Skipping untar."
      exit 0
    fi
    test -f "$ARCHIVE"
    tar -xzf "$ARCHIVE" -C /
    

Note

From now on, users must start every subsequent shell with

   %%bash
   source "/content/conda/etc/profile.d/conda.sh"
   conda activate cocoa
   cd ./cocoa/Cocoa/
   source start_cocoa.sh

• Saving/Loading checkpoints

  Not reserving time to copy the /content folder to the user's Google Drive —an expensive operation —can result in up to 24 hours of lost computation. To prevent such a catastrophe, the code below creates and loads checkpoints that users can add after computationally intensive cells.

  This solution is not valid when running Colab with local runtime (see Google documentation for additional information on how to link notebooks to local resources). The good news here is that local storage is persistent, so there is no need to create backups on Google Drive.

  • Saving checkpoints: compress and copy the /content folder from the local disk to the user's Drive

    %%bash
    ROOT="colab_name_notebook"
    DEST="/content/drive/MyDrive/ColabBackups"
    mkdir -p "$DEST"
    ARCHIVE="$DEST/${ROOT}_$(date +%F_%H-%M).tar.gz"
    tar -czf "$ARCHIVE" \
        --exclude='/content/drive' \
        --exclude='**/__pycache__' \
        --exclude='**/.ipynb_checkpoints' \
        /content
    echo "Created: $ARCHIVE"
    

  • Loading checkpoints: decompress and copy the /content folder from the user's Drive to the local disk

    %%bash
    SENTINEL="/content/conda/etc/profile.d/conda.sh"  # exists when your env is restored
    if [[ -e "$SENTINEL" ]]; then
      echo "Found $SENTINEL — environment already restored. Skipping untar."
      exit 0
    fi
    ARCHIVE="CHECKPOINT_FILE" # replace this string!
    test -f "$ARCHIVE"
    tar -xzf "$ARCHIVE" -C /
    

⁉️ FAQ: How can developers improve their Bash/C/C++ knowledge?

A working knowledge of Python is required to understand the Cobaya framework at the developer level. Users must also be familiar with the Bash language to understand Cocoa's scripts. Proficiency in C and C++ is also needed to manipulate Cosmolike and the C++ Cobaya-Cosmolike C++ interface. Finally, users need to understand the Fortran-2003 language to modify CAMB.

Learning all these languages can be overwhelming, so to enable new users to do research that demands modifications on the inner workings of these codes, we include here a link to approximately 600 slides that provide an overview of Bash (slides ~1-137), C (slides ~138-371), and C++ (slides ~372-599). In the future, we aim to add lectures about Python and Fortran.