Closed londumas closed 6 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.
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.
@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
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.
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.
@londumas Looking back at this issue, I don't understand what the problem is. eta was always a function of lambda_obs, no ?
yes, but it shouldn't be of lambda_RF
@londumas I agree... was it ever under discussion?
@ngbusca , what do you mean ?
@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?
The title talks about "lambdaRF" not lambda_obs
right, why does it talk about lambdaRF?
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.
I disagree, they show that there's something we don't fully understand.
for example, that the noise is more complicated than our simple model
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 ?
Let's keep it open, but I'll change the title to something that makes more sense.
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.
a way to investigate this would be to use the same quasars for the CIV forest and the MGII forest.
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
@londumas I can't confirm this last plot. I find good agreement between lya and lyb at low lambda_obs. Can you double check?
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
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.
I totally agree. I just did that to test. Do you need me to compute it again ?
it's not high priority, but if you confirm that there's no problem then we close the issue.
even your plot has a problem, just look at eta for lambda>4500
The last few bins contain very little statistics, I don't think that's a problem.
Here is what I get reducing to lambdaRF = 973:
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
@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?
yes, it seems to be this.
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](https://cloud.githubusercontent.com/assets/3166436/24138578/07361692-0e19-11e7-80e7-8f1f66d694b4.png)
sigmaLSS vs lambda_obs:![sigmalss_vs_lambda_obs](https://cloud.githubusercontent.com/assets/3166436/24138579/07372b86-0e19-11e7-8fbc-544562bdc082.png)
flux vs lambda_obs:![mean_flux_vs_lambda_obs](https://cloud.githubusercontent.com/assets/3166436/24138577/073460a4-0e19-11e7-8e74-7cbf467744bd.png)
flux vs lambda_RF:![mean_flux_vs_lambda_rf](https://cloud.githubusercontent.com/assets/3166436/24138576/0731fecc-0e19-11e7-8c5a-c1d5f39ac675.png)