-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
I've checked that the different P1D used had almost no effect, unsurprisingly. |
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. |
So, the values of bias/beta assumed in both codes are very different. 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. |
@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 ... |
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. |
I think this prints what the 2003 paper would give for these parameters (I don’t know what it does with <F>, TDR, etc.), but that was just linearized around z=2.25, so I don’t think Fisher code uses it for redshift evolution. I think Fisher code basically fixes shape at central z and scales an overall normalization with z to approximately match measured P1D(z). At some point I checked that in practice it does a reasonably good job of this… (matching measured P1D(z), on relevant scale)
Pat
… On Oct 4, 2018, at 5:41 AM, Andreu Font-Ribera ***@***.***> wrote:
@pmcdonal <https://github.com/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 ...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACT1D7Bp3hFEmkMspqnnNwXMG_fq1y4iks5uhgH9gaJpZM4XHshT>.
|
Good to hear that. |
@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...
The text was updated successfully, but these errors were encountered: