To get consistent chi2 and chi2_prior with action=4

[JussiValiviita]

When using action=4 (test likelihoods and produce C_ell) or action=2 (minimizer), one gets inconsistent total chi2 and chi2_prior, if demanding BaseParams%varying(i)=T or this%varying(i)=T as was in the previous versions of the code. Think of a situation where one wants, e.g., to use minimizer with a fixed Planck calibration (cal0) and to compare to a situation where cal0 is varied (and a gaussian prior imposed on it). Another example: one wants to check that the code really used the reported parameters in MCMC or that there was no openMP mess-up in CAMB during the MCMC run. So, one picks a random sample from an MCMC chain and wants to reproduce its chi2 with action=4. The requested modifications allow for this produce a consistent chi2 compared to the full MCMC. (Earlier versions of the code added only those gaussian priors that were combinations of more than one parameters, while ignoring all single-parameter gaussian priors.) The modifications do create a minimal overhead in MCMC runs in those cases where some parameters are fixed, but at least this way one gets a consistent chi2 no matter what action one uses.

[cmbant]

Thanks for this. There are other cases where you might not want the prior in. E.g. if comparing chi2 for different fixed values of cal0, one probably would not want to confuse the comparison by including the Gaussian prior. One solution would be a boolean parameter "include_priors_on_fixed_parameters".

This change probably also changes the results for test*.ini, so those files may need updating for new likelihood comparison check numbers?

[JussiValiviita]

Hi cmbant, I did think about your first point, but in my opinion, if one does not want a gaussian prior for some parameter(s), then one should comment out these priors, e.g., in batch2/plik_v18_priors.ini. Naturally, one may not want to edit directly this file, but since the if-sentence in the code is if(BaseParams%GaussPriors%std(i)/=0), one can also override those 14 priors (or even more for TTTEEE) in test.ini by giving a zero std. Then the mean would be irrelevant, so e.g. a line prior[cal0]=0 0 in test.ini should disable the cal0 prior. This way it would be explicit for the user whether he/she wants to include the gaussian priors or not. For example, a separate GLOBAL flag (include_gaussian_priors=T/F) is not a good solution, because you may want to disable only some of the priors while keeping some!

Anyway, currently the code produces an inconsistent chi2 with action=4 (and with other actions if a parameter is fixed), since out of 14 priors for TT, 13 are ignored, but one is (un)intentionally(???) included**). Namely prior[SZComb] = 9.5 3 is always reported in chi2_piror and always added to the total chi2 (even if the relevant params aksz and asz143 are not varied), while the other 13 priors are ignored with action=4 (and with action=2 or 1 if one fixes some of these nuisance parameters). An example: my colleague sent me the parameters of his bestfit model and his bestfit chi2 (found with CLASS). I plugged those parameters into my test.ini, and found with action=4 a TOTALLY different chi2, which made me to use several days to look for a bug in my modified version of CAMB. In reality, the only reason for the BIG difference was the unintentional ignorance of priors.

I don't find any "likelihood check comparison numbers" for the priors. So, I guess your last point does not prevent a bug fix.

**) In my solution the combined priors (currently only SZComb) can be ignored, for example, by putting prior[SZComb] = 0 0 in test.ini.

[cmbant]

Yes, I think linear_combination priors have to be explicitly zeroed to be ignored, since they in general involve arbitrary linear combinations of parameters (and fixing one would typically have a non-trivial implications for the likelihood of another).

Having a "include_priors_on_fixed_parameters" parameter wouldn't preclude also individually overriding priors?

If you run test_planck.ini, it checks against the "test_check_compare = 5859.141" number in .ini file, which I guess has changed if priors are now being included?

[JussiValiviita]

Both points are true - I had never even noticed test_planck.ini. Adding "include_priors_on_fixed_parameters" is a larger modification. I'll see if I find time some other day (aka some other month).

[cmbant]

I have added a option "include_fixed_parameter_priors", hope this works for you.

(but action=4 run in itself does not change which parameters are varying, so even with include_fixed_parameter_priors=F result should be consistent with minimization unless you explicitly fix one or more parameters when running action=4)