xcorr: add CLASS compatability

[itrharrison]

I should fix the xcorr compatibility with CLASS, which I think should only be a case of translating variable and function names where necessary.

[cmbant]

There shouldn't be any direct dependence on class or camb if using Cobaya or CCL?

[itrharrison]

At the moment in xcorr I am using things like theory.get_Pk_interpolator provider.get_comoving_radial_distance provider.get_param('omegam')

and using theory: camb: in the info specified in the test.

Is there a better way where I don't have to use variable and method names like those in the likelihood?

[cmbant]

Those are all general cobaya functions not CAMB. (theory can be replaced with provider).

camb would need to be an explicit dependency of the test (have to choose some theory code to actually run), but not the likelihood.

Not sure if "omegam" may be an issue, if CLASS calls it something else.

[itrharrison]

@cmbant thanks for being patient with me getting back on this.

Having use_renames: True in the theory specification solves most of the problems.

However, there are still a couple of things.

zstar

camb has zstar (i.e. can provider.get_param('zstar')) but there is no equivalent in the classy cobaya theory. I can see how to get it in classy from classy.get_current_derived_parameters('z_star') but it isn't clear how to get at this in a cobaya likelihood.

redshift grid

The way the list of required redshifts is treated seems to be different between camb and classy cobaya theories. If the requirements includes e.g. "Hubble": {"z": self.zbgdarray} then with the camb theory I can get_Hubble at any redshift within the range:

(Pdb) self.zbgdarray
array([0.00000000e+00, 4.44444444e-01, 8.88888889e-01, 1.33333333e+00,
       1.77777778e+00, 2.22222222e+00, 2.66666667e+00, 3.11111111e+00,
       3.55555556e+00, 4.00000000e+00, 1.10000000e+03])
(Pdb) self.provider.get_Hubble(self.zbgdarray)
array([7.00000000e+01, 8.86654801e+01, 1.15506621e+02, 1.48715926e+02,
       1.86980454e+02, 2.29464908e+02, 2.75627926e+02, 3.25098255e+02,
       3.77605958e+02, 4.32944621e+02, 1.60518977e+06])
(Pdb) self.provider.get_Hubble(0.5)
array([115.50662117])
(Pdb) self.provider.get_Hubble(np.linspace(0, 4.0, 5))
array([ 70.        , 148.71592569, 229.46490835, 325.09825547,
       432.94462087])

but in the classy theory the get_Hubble works at the points in the array in the requirements:

(Pdb) self.zbgdarray
array([0.00000000e+00, 4.44444444e-01, 8.88888889e-01, 1.33333333e+00,
       1.77777778e+00, 2.22222222e+00, 2.66666667e+00, 3.11111111e+00,
       3.55555556e+00, 4.00000000e+00, 1.10000000e+03])
(Pdb) self.provider.get_Hubble(self.zbgdarray)
array([7.00000000e+01, 8.93332454e+01, 1.16963886e+02, 1.51020687e+02,
       1.90178321e+02, 2.33601914e+02, 2.80751645e+02, 3.31256908e+02,
       3.84847572e+02, 4.41316510e+02, 1.62955702e+06])

but returns an empty array at any other value:

(Pdb) self.provider.get_Hubble(0.5)
array([], dtype=float64)
(Pdb) self.provider.get_Hubble(np.linspace(0, 4.0, 5))
array([ 70.        , 441.31650979])

Is this the intended behaviour? I could work around it with some intermediate interpolation (of the galaxy dndz onto the self.zbgdarray points), I am sure, but it created a bit of a gotcha when the two behaved differently.

[cmbant]

For Hubble CAMB is just finding and returning closest value that is calculated and stored. So they are both intended behaviour in the sense that z has to be requested in advance to get a valid value for it. But there may be a case for some more explicit error report when an invalid z value is requested.

Why do you need z_star? I guess the classy wrapper would have to be updated if you need it (probably in _get_derived_all, though classy is not my domain...)

[cmbant]

PS. I would be more worried that the values are you are getting for Hubble are different between the codes!

[itrharrison]

I use z_star to get chistar for the kappa kernels. I will have a look at adding it to the cobaya classy wrapper.

The differences in Hubble turned out to be due to different defaults for neutrino masses. It goes away when explicitly setting "mnu" : 0. for camb.