igmhub / picca

set of tools for continuum fitting, correlation function calculation, cosmological fits...
GNU General Public License v3.0
29 stars 22 forks source link

For a given lambda_obs, eta is different for different data samples #80

Closed londumas closed 6 years ago

londumas commented 7 years ago

The results for eta should be the same across forests since it only depends on the error of precision calibration at a given wavelength. In other words, eta is a function of lambdaOBS not of lambdaRF.

It is very stable between the MGII, SIIV and CIV forests. (first plot)

It is getting different for the Lya and the Lyb forests. (first plot)

Maybe this is linked to issue 48 (https://github.com/igmhub/pyLyA/issues/48) (third plot)

Anyway, this is not that important, but it would be nice to understand the reason.

Eta vs lambda_obs: eta_vs_lambda_obs

sigmaLSS vs lambda_obs: sigmalss_vs_lambda_obs

flux vs lambda_obs: mean_flux_vs_lambda_obs

flux vs lambda_RF: mean_flux_vs_lambda_rf

andreufont commented 7 years ago

Eta is a way of describing extra variance as a correction of the noise variance, right?

If so, you could have extra variance in the spectra coming from other things, and you think you need to correct the noise variance when may be the noise was ok.

For instance, think about continuum errors. If your model don't take these into account, you will measure some extra large variance, and you will hide under the rug (eta).

It might be that what you are seeing is that different parts of the spectrum (in rest frame wavelength) have different amount of continuum errors.

ngbusca commented 7 years ago

I disagree, eta is (intended to be) a correction for the noise miscalibration which is a function of lambda_obs. In your plot there's a very good match up to ~5500. I can't say there's a disagreement above since there are no errorbars.

londumas commented 7 years ago

@andreufont I disagree with you, this effect should reflect more on sigma_pow2_LSS.

@ngbusca I agree with you, to see if what I see is significant, we should plot the error. For now, the code doesn't give any, I will think on a cleaver way to get it and store it

andreufont commented 7 years ago

May be I wasn't clear: I was not suggesting that the noise correction should depend on rest frame wavelength, this wouldn't make sense. I was suggesting that if there was a dependence of eta on the rest-frame range used, it could be explained by extra variance not present in your model, like for instance variance in the continuum.

ngbusca commented 7 years ago

I agree with @andreufont , but note that a dependence of eta vs lambda_rf is expected since not all bins in lambda_rf correspond to the same mean lambda_obs. So one should look for an evolution with lambda_rf beyond what's expected from the known evolution with lambda_obs.

ngbusca commented 6 years ago

@londumas Looking back at this issue, I don't understand what the problem is. eta was always a function of lambda_obs, no ?

londumas commented 6 years ago

yes, but it shouldn't be of lambda_RF

ngbusca commented 6 years ago

@londumas I agree... was it ever under discussion?

londumas commented 6 years ago

@ngbusca , what do you mean ?

ngbusca commented 6 years ago

@londumas the title of the issue is "eta is a function of lambdaRF". Eta was always a function of lambda_obs, and we all agree that's the way it should be. So what is this issue about?

londumas commented 6 years ago

The title talks about "lambdaRF" not lambda_obs

ngbusca commented 6 years ago

right, why does it talk about lambdaRF?

londumas commented 6 years ago

do we agree that if eta takes care of errors of the pipeline it should only be a function of lambda_Obs ? Not a function of lambda_RF ? But the first plot shows that it is a function of lambda_RF since the blue and green and other curves are different.

ngbusca commented 6 years ago

I disagree, they show that there's something we don't fully understand.

ngbusca commented 6 years ago

for example, that the noise is more complicated than our simple model

londumas commented 6 years ago

ok, so we agree. Our simple model is good but not good enough. You think this isn't the place to try to solve this issue ?

ngbusca commented 6 years ago

Let's keep it open, but I'll change the title to something that makes more sense.

londumas commented 6 years ago

After the addition of the "fudge" term, the eta obtained in different forest are very similar. The only difference seems to be a normalization for the MGII forest. It would be interesting to know why.

eta_lambdaobs

sigma2lss_lambdaobs

fudge_lambdaobs

flux_lambdarf

londumas commented 6 years ago

a way to investigate this would be to use the same quasars for the CIV forest and the MGII forest.

londumas commented 6 years ago

The last eta plot was wrong. The difference of eta from the different forests was only because I did no rebinning for the LYA, CIV, SiIV forests but rebin 2 in the MGII forest. Using the same rebining gives the basically the same results for eta across all forests. The only difference are for Lya and Lyb. It might be linked to degeneracies between sigma_LSS and eta

eta_lambdaobs_samebinning

ngbusca commented 6 years ago

@londumas I can't confirm this last plot. I find good agreement between lya and lyb at low lambda_obs. Can you double check?

image

londumas commented 6 years ago

It is just a defintion of Lyb, what is yours ? Mine is:

--lambda-min 3600.0
--lambda-max 7235.0
--lambda-rest-min 800.0
--lambda-rest-max 1020.0
ngbusca commented 6 years ago

I use

--lambda-max 4590 --lambda-rest-min 973 --zqso-max 3.5

I wouldn't go below lambda-rest-min 973 because then you have the lyman-gamma and other forests mixed.

londumas commented 6 years ago

I totally agree. I just did that to test. Do you need me to compute it again ?

ngbusca commented 6 years ago

it's not high priority, but if you confirm that there's no problem then we close the issue.

londumas commented 6 years ago

even your plot has a problem, just look at eta for lambda>4500

ngbusca commented 6 years ago

The last few bins contain very little statistics, I don't think that's a problem.

londumas commented 6 years ago

Here is what I get reducing to lambdaRF = 973: capture d ecran de 2017-11-13 23-11-19

londumas commented 6 years ago

I agree that there seems to be no bug anymore in picca. But the differences between DR12Q and DR14Q for the eta(l) and var_lss(l) plots show that there are bugs in DR14Q

ngbusca commented 6 years ago

@londumas you are including qsos with z>3.5. We know those have a large contamination with lowz quasars in DR14Q. Is this what you are talking about?

londumas commented 6 years ago

yes, it seems to be this.