CobayaSampler / cobaya

Code for Bayesian Analysis
http://cobaya.readthedocs.io/en/latest/
Other
126 stars 125 forks source link

Modifying plik multipole range via model wrapper #303

Closed joshua-benabou closed 1 year ago

joshua-benabou commented 1 year ago

Hello,

The documentation for the Planck likelihoods that may be installed with cobaya (specifically, data/planck_2018/readme_baseline.md) claims that the planck_2018_highl_plik.TTTEEE likelihood the may be modified "using the optional tools in the code package" to cover any multipole range between the default lmin and lmax values.

It is unclear which optional tools are being referred to, so my question is if it is indeed possible , when using the cobaya model wrapper (as described in https://cobaya.readthedocs.io/en/latest/cosmo_model.html), to define a parameter to the info dictionary which would restrict the multipole range over which the planck_2018_highl_plik.TTTEEE likelihood is calculated to all \ell < lmax for some lmax (and hence also the multipole range over which Cl's are computed by the CMB theory code). Further, would this also possible for planck_2018_highl_plik.TTTEEE_lite, or planck_2018_highl_plik.TTTEEE_lite_native ?

In other words, can any such optional parameter be indicated instead of None below?

info['likelihood']={ 'planck_2018_highl_plik.TTTEEE': None} ?

Looking at the output of model = get_model(info, debug=True), there does not appear to be any such parameter, so I am not sure what is meant by the documentation here?

cmbant commented 1 year ago

No, you need to use the clik Planck package tools.

Sent from Outlook for iOShttps://aka.ms/o0ukef


From: Joshua Benabou @.> Sent: Sunday, July 23, 2023 10:51:29 AM To: CobayaSampler/cobaya @.> Cc: Subscribed @.***> Subject: [CobayaSampler/cobaya] Modifying plik multipole range via model wrapper (Issue #303)

Hello,

The documentation for the Planck likelihoods that may be installed with cobaya (specifically, data/planck_2018/readme_baseline.md) claims that the planck_2018_highl_plik.TTTEEE likelihood the may be modified "using the optional tools in the code package" to cover any multipole range between the default lmin and lmax values.

It is unclear which optional tools are being referred to, so my question is if it is indeed possible , when using the cobaya model wrapper (as described in https://cobaya.readthedocs.io/en/latest/cosmo_model.html), to define a parameter to the info dictionary which would restrict the multipole range over which the planck_2018_highl_plik.TTTEEE likelihood is calculated to all \ell < lmax for some lmax (and hence also the multipole range over which Cl's are computed by the CMB theory code). Further, would this also possible for planck_2018_highl_plik.TTTEEE_lite ?

In other words, can any such optional parameter be indicated instead of None below?

info['likelihood']={ 'planck_2018_highl_plik.TTTEEE': None} ?

Looking at the output of model = get_model(info, debug=True), there does not appear to be any such parameter, so I am not sure what is meant by the documentation here?

— Reply to this email directly, view it on GitHubhttps://github.com/CobayaSampler/cobaya/issues/303, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA6GQI45BBRBUHASK4PX7H3XRTQZDANCNFSM6AAAAAA2UMBUFM. You are receiving this because you are subscribed to this thread.Message ID: @.***>

joshua-benabou commented 1 year ago

Hello,

Thanks for your reply.

I installed the clik code and I see that there are two python tools to do multipole cuts on the Planck likelihoods:

So it looks like in principle all that is needed is to do a multipole cut on an existing Planck likelihood and then change the clik file path when setting up the cobaya model object.

However,neither of the above two tools can be used for the nuisance-free 'lite' likelihood (i.e the one installed automatically by cobaya in data/planck_2018/baseline/plc_3.0/hi_l/plik_lite/plik_lite_v22_TTTEEE.clik ), so is there any easy way to restrict the l-range for this likelihood?

cmbant commented 1 year ago

For planck_2018_highl_plik.TTTEEE_lite_native you can do cuts via cobaya's dataset_params parameters in the yaml (see the .dataset file itself for options); for clik files you'd need to consonnsult the clik documentation (nothing to do with Cobaya).

joshua-benabou commented 1 year ago

Ah, thanks for that info!

In the planck_2018_pliklite_native/plik_lite_v22.datasetbelow,

use_cl = TT TE EE

#List of bins to actually use
use_bins = 

#Tuple giving min and max L to actually use
bins_for_L_range =

#total bins in data file and covariance
nbintt=215
nbinte=199
nbinee=199

lmax=2508 

data = cl_cmb_plik_v22.dat

bin_lmin_offset = 30
blmin = blmin.dat
blmax = blmax.dat
weights = bweight.dat

#cov_file = plik_lite_cov.dat
cov_file_binary = c_matrix_plik_v22.dat

I naively tried changing to lmax=250 , however that gave an array shape mismatch error when calling model.loglikes :

ValueError('shapes (7,) and (9,) not aligned: 7 (dim 0) != 9 (dim 0)

So I am guessing that, to restrict to multipoles up to l=250, all that is needed is

use_bins = 0 250

Is that correct, or does anything else need to be changed?

Its unclear to me because while model.loglikes runs without error and gives a different answer relative to not leaving use_bins undefined, model.requested()still shows that the theory code is requested to compute multipoles up to 2508.

if you could confirm this would be very helpful and Ill close the issue as this solves my probem.

cmbant commented 1 year ago
joshua-benabou commented 1 year ago

Sorry, yes I meant bins_for_L_range . Ok, great!

joshua-benabou commented 1 year ago

Sorry,

can you clarify , modifying bins_for_L_range = 0 250 , model_requested() still shows that multipoles up to 2508 are requested. Are the multipoles above 250 then just requested but not used?

cmbant commented 1 year ago

Yes, because bins can map non-locally to L, cutting bins does not automatically cut L requested. You can also change lmax.

joshua-benabou commented 1 year ago

Changing lmax as well, i.e

bins_for_L_range = 0 250
lmax = 250

produces this error however:

ValueError('shapes (7,) and (9,) not aligned: 7 (dim 0) != 9 (dim 0)

?

cmbant commented 1 year ago

I suggest you just look at the code yourself and debug, that’s all I was doing to answer Qs so far