Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compare code vs C++ version used in Font-Ribera et al. 2014 #3

Open
andreufont opened this issue Oct 4, 2018 · 7 comments
Open

Compare code vs C++ version used in Font-Ribera et al. 2014 #3

andreufont opened this issue Oct 4, 2018 · 7 comments

Comments

@andreufont
Copy link
Contributor

@julienguy - I'm trying to go through the differences between this code and the C++ version form @pmcdonal

From what I remember, the main difference in the code is that I do a simplified version of the integrals, closer to what is written in McDonald & Eisenstein (2007), while the C++ code does a more complex average over pixel redshifts and quasar redshifts. I don't remember the details, but I'll dig into them. This approximation makes the python code considerably much faster, though, so I'd like to leave that one for last.

Other differences are the way we are treating the quasar LF (see the other issue) and the way we are treating different, isolated pieces, like the predicitons for the 1D power. In the python version we are using the analytical formula from Palanque-Delabrouille et al. (2013), while in the c++ by default it uses the P1D inferred from the 3D power spectrum in McDonald 2003 simulations. The c++ code has the option to use P-D 2013 instead, so I'm re-running with that now to see the effect.

I'll keep you posted...

@andreufont
Copy link
Contributor Author

I've checked that the different P1D used had almost no effect, unsurprisingly.

@andreufont
Copy link
Contributor Author

There are other differences that are a bit trickier to compare: to compute effective densities, noise levels and similar, one needs to choose a (k,mu) point to evaluate P3D. This is set in Mpc/h in the c++ code, but in km/s - deg in the python code, so you can not quite match all redshifts. But I think this is a small difference (these points are quite arbitrary anyway).

Another difference is the value assumed for P3D. I'm looking into this now.

@andreufont
Copy link
Contributor Author

andreufont commented Oct 4, 2018

So, the values of bias/beta assumed in both codes are very different.

bias_z

beat_z

In the python code we assume that the 3D power goes like (1+z)^3.8, i..e, in an EdS the bias goes like (1+z)^2.9. This is what we call alpha=2.9.

But in the c++ the evolution of the bias is better described by alpha=1.25, i.e., the power evolves like (1+z)^0.5 !

In the python code we assume no evolution for beta, while the c++ code has some evolution.

@andreufont
Copy link
Contributor Author

@pmcdonal - I got the c++ numbers by calling PrintBiasBeta(z) at different redshifts, from within the main forecast code (to make sure the settings were the same).

I guess it is not too surprising that the redshift evolution is a bit different, since McDonald 2003 didn't look very carefully at the redshift evolution (that's why the neutrino constraints stop at z=2.7 or so), but I'm surprised they are that different...

On the other hand, the value of (1+z)^3.8 was motivated by the evolution of the 1D power, and that is not the same as the evolution of the 3D power. And Palanque-Delabrouille et al. (2013) claims it is better described by (1+z)^3.5. But you have to change it a lot to go to (1+z)^0.5 ...

@andreufont
Copy link
Contributor Author

Note that even with that change the BAO forecasts are still very different. I'll try to compare the uncertainty in band power measurements, so that I don't need to dig into the BAO implementation.

@pmcdonal
Copy link

pmcdonal commented Oct 4, 2018 via email

@andreufont
Copy link
Contributor Author

Good to hear that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants