spacetelescope / jwst

Python library for science observations from the James Webb Space Telescope
https://jwst-pipeline.readthedocs.io/en/latest/
Other
569 stars 167 forks source link

Underestimated uncertainties in NIRSpec Level 1 rate files #7362

Open mmaseda opened 1 year ago

mmaseda commented 1 year ago

[Note: this issue has also been raised to the helpdesk. I'm bringing it up here as well to get as many viewpoints as possible]

When @jhennawi and I were first looking at the pipeline-produced level 3 NIRSpec files, we noticed that the quoted uncertainties were a bit low compared to the actual variation in the data. In tracing this backwards, we noticed that this is present already in level 1. Namely, the quoted uncertainties in the rate files do not seem to explain the pixel-to-pixel variations. In the attached plot, I'm showing data from the area of one of the fixed slits (which does not contain a target). I'm taking the difference between two exposures at the same nodding position and comparing the difference to the quoted uncertainties in the pixels. If everything is working well, this should be a normal distribution with a sigma of 1. But as you can see, this is not the case and NRS2 even seems to be offset slightly. I've looked a several different datasets and noticed the same effect, also while using several versions of the pipeline (this plot shows the result from the pipeline with the latest CRDS). This is also not unique to the fixed slit region of the detector.

One proposed solution to this is that the pipeline isn't properly accounting for the 1/f noise. While this may be true, the sky background in this region is surely much larger than the 1/f noise and the distributions are still a single gaussian.

Thanks in advance

noise_fixedslit

jdavies-st commented 1 year ago

So uncertainties are propagated for per-pixel readnoise and for shot noise (poisson) in calwebb_detector1. Sources of noise that are not specifically propagated are:

The poisson variance is computed based on the slope (signal), gain and number of groups.

https://github.com/spacetelescope/stcal/blob/acfd88ef117dcdd72ce829cba4d2efe308a78b5a/src/stcal/ramp_fitting/utils.py#L569-L574

And the readnoise variance is computed based on the readnoise per read and the number of reads.

https://github.com/spacetelescope/stcal/blob/acfd88ef117dcdd72ce829cba4d2efe308a78b5a/src/stcal/ramp_fitting/utils.py#L588-L589

Neither explicitly account for anything listed above, and I don't know the levels.

And it definitely does not take into account IPC, as it is correlated across pixels once corrected by the IPC kernel. I.e. the signal in a pixel is not just temporally dependent, but also spatially dependent - it depends on the flux of its neighboring pixels.

Some discussion of this for NIRSpec is here

https://ntrs.nasa.gov/api/citations/20080047752/downloads/20080047752.pdf

And they imply that the true variance is likely ~10% higher due to this IPC correlation once corrected, see eq 9.

There is some more discussion of IPC in these 2k IR detectors here

https://arxiv.org/abs/2209.01831

relating the Euclid, whose detectors are almost identical to those on JWST.

jdavies-st commented 1 year ago

Tagging @karllark and @mwregan2 here as well, as I think they have a better understanding of the magnitudes of these effects and possible future intent to account for them.

karllark commented 1 year ago

Not surprised that empirical noise estimates are larger than the pipeline propagated uncertainties. As already stated, the only noise sources that are included in the pipeline uncertainties are photon and read noise from the ramp fitting and flat field noise from the flat field step. The flat field step requires that the flat field reference file includes uncertainties. It may be worth checking if this is the case for NIRSpec where the flat field reference file is created on the fly from the instrument model (if my understanding is correct).

Not sure which of the effects/steps in the pipeline that are not included are the cause of the differences note above, there are a few for sure (see @jdavies-st response). My suspicion is that it would be the 1/f noise that is partially accounted for by the reference pixels. If the 1/f noise could be quantified, then it is something that could be added to the pipeline propagated uncertainties.

jhennawi commented 1 year ago

@karllark this is only a question of the level1 uncertainties. I don't see why flat fielding uncertainties should matter here. We are using an empirical estimate for the same pixels so flat fielding issues do not enter, and it was my understanding that the level1 pipeline was not attempting to deal with flat-fielding errors (which it should not, since one just wants to know the photon rates). I think the key point is that level1 is not properly accounting for the photon statistics and that this is a very big effect ~ 30%. The aperture in question is clearly background limited, so I don't think this an issue of not understanding some of the subtle effects that @jdavies-st refers to. I've done these sorts of tests with Hawaii-II detectors for ground based NIR spectrographs and we always obey Poisson statistics to better than 10% and most often to a few percent. Given how off things are here (~30%) this smells to be like a serious bug in the ramp fitting for NIRSPEC, or possibly that the gain of the detectors is not well measured.

karllark commented 1 year ago

Interesting. Have you had a chance to look at the docs and/or code to see if you can identify where the bug and/or conceptual issue might be? Having someone with your clear expertise look things over and give your impressions would be great. Thanks!

Totally agree that the flat field uncertainties are not important for this question. I had not realized that you were only considering the stage 1 results (rate files).

mwregan2 commented 1 year ago

These are interesting results and to be honest better than what I would have expected. To track down the source of the underestimate we need to know the contribution of Poisson and read noise to the total noise. If one of them is the dominant effect, it greatly simplifies the debugging. If Poisson noise dominates, the only source of the error would be the gain reference file. I know that when I did the gain calculations for NIRSpec detectors my results were 10-20% off the GSFC values. In general, this is true for most photon transfer calculations. It's possible to do better but you have to be careful. If read noise dominates then it could be that that the read noise reference file is off, or that there is another term that sets a read noise floor that is not included (see James' comment above). The pipeline does give you the two terms (Poisson variance and Read Noise variance). How do they compare for these pixels?

jdavies-st commented 1 year ago

Putting a link here to @mmaseda's nice paper out on the arxiv now describing Lyman-α Emitters.

https://arxiv.org/abs/2304.08511

The paper has a nice discussion of the Appendix B shows largely what we see in the figure above but with more context on the input data and the methods.

Would be nice to continue to try to understand where the discrepancy is coming from, as I expect if there's an underestimate in the readnoise or differences in the gain estimate, that would have a big impact not only on the random, as reported here, but also have a significant impact in the ability of the 2-point difference method to detect jumps as well.

hbushouse commented 1 year ago

Note that if this is in fact due to an underestimate of readnoise or inaccurate gain estimate, it's not a cal pipeline issue. That's an issue to be raised with the NIRSpec instrument team, who provide the instrument calibration data to the pipeline.

jhennawi commented 1 year ago

@hbushouse I think the read up the ramp code is not working correctly. That is my opinion. It is pretty easy to get the gain and read noise of a detector correct here. But the complicated part is the ramp fitting. My guess is that the errors that are reported there are just incorrect.

mwregan2 commented 1 year ago

Joseph, Determining the gain of an HgCdTe detector is not trivial. The inherent non-linearity of the detector means that the error in NL correction is propagated into the gain calculation. Even so, we should only be off by ~20% at the most. There are significant errors in some of the read noise reference files. Mike Regan

From: Joseph Hennawi @.> Reply-To: spacetelescope/jwst @.> Date: Thursday, April 27, 2023 at 2:00 PM To: spacetelescope/jwst @.> Cc: Michael Regan @.>, Mention @.***> Subject: Re: [spacetelescope/jwst] Underestimated uncertainties in NIRSpec Level 1 rate files (Issue #7362)

@hbushousehttps://urldefense.com/v3/__https:/github.com/hbushouse__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!2jy5aGTjAUIaf8c29Mpql1NpgPk71U55DnTOGDTa_ntJsB4DgDltelZKalh_CYSA4-eb9uuzlZBxCfdgi0qRqGI$ I think the read up the ramp code is not working correctly. That is my opinion. It is pretty easy to get the gain and read noise of a detector correct here. But the complicated part is the ramp fitting. My guess is that the errors that are reported there are just incorrect.

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/spacetelescope/jwst/issues/7362*issuecomment-1526107517__;Iw!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!2jy5aGTjAUIaf8c29Mpql1NpgPk71U55DnTOGDTa_ntJsB4DgDltelZKalh_CYSA4-eb9uuzlZBxCfdgdaW9KY0$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AF6KJLTRVXBS7BOWU2VVGKDXDKX3NANCNFSM6AAAAAASF5PT5Q__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!2jy5aGTjAUIaf8c29Mpql1NpgPk71U55DnTOGDTa_ntJsB4DgDltelZKalh_CYSA4-eb9uuzlZBxCfdgzYnYLF4$. You are receiving this because you were mentioned.Message ID: @.***>

jhennawi commented 1 year ago

@mwregan2 what you are saying here does not add up to me. In the PypeIt project https://pypeit.readthedocs.io/en/release/spectrographs/spectrographs.html we support seven different near-IR spectrographs using the same detector technology and we have tested our noise models and they are typically good to better than 10%. And that is using the gain and read noise values simply published on telescope websites. The main differences compared to JWST data processing are possibly detector read out electronics (but the seven different spectrographs also have heterogenous electronics) and I think most importantly, the software to average the non-destructive reads. Ground based spectrographs do not employ any sophisticated ramp fitting software, whereas JWST does. That is why I strongly suspect that the Spec1 code that goes from the _uncal files to the _rate files is the source of the problem in the noise modeling. The pipeline is simply not correctly counting the number of photons, which the example that @mmaseda posted here makes abundantly clear. For that test, we intentionally focused on a wide NIRSPEC slit that is obviously background limited, so read noise cannot be the issue.

mwregan2 commented 1 year ago

Joseph,

I totally agree that the uncertainties are not correct. I've tested the ramp fit code and the output slopes are correct for a variety of permutations of flux, time, and number of cosmic rays. Fitting the slope is not inherently hard but the code becomes complicated due to the large number of permutations of groups, cosmic rays, and other detector effects that causes groups to be ignored for the fit.

I also totally agree that the weighting that is being used could be sub-optimal in the read noise dominated regime. But, I also know for a fact that the read noise and gain reference files have not be a high priority for the instrument teams and that for several cases they are significantly off.

Mike


From: Joseph Hennawi @.***> Sent: Friday, April 28, 2023 12:27:20 PM To: spacetelescope/jwst Cc: Michael Regan; Mention Subject: Re: [spacetelescope/jwst] Underestimated uncertainties in NIRSpec Level 1 rate files (Issue #7362)

@mwregan2https://urldefense.com/v3/__https://github.com/mwregan2__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!3tP6Y4oybl56LIwwviSb4up2eu_cb1jVch-SWY90V37fl8B5WkMr8EhnHKvktPpHVET0-MgL9qbbh_xJJ1KHHqo$ what you are saying here does not add up to me. In the PypeIt project https://pypeit.readthedocs.io/en/release/spectrographs/spectrographs.htmlhttps://urldefense.com/v3/__https://pypeit.readthedocs.io/en/release/spectrographs/spectrographs.html__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!3tP6Y4oybl56LIwwviSb4up2eu_cb1jVch-SWY90V37fl8B5WkMr8EhnHKvktPpHVET0-MgL9qbbh_xJN5HzlKg$ we support seven different near-IR spectrographs using the same detector technology and we have tested our noise models and they are typically good to better than 10%. And that is using the gain and read noise values simply published on telescope websites. The main differences compared to JWST data processing are possibly detector read out electronics (but the seven different spectrographs also have heterogenous electronics) and I think most importantly, the software to average the non-destructive reads. Ground based spectrographs do not employ any sophisticated ramp fitting software, whereas JWST does. That is why I strongly suspect that the Spec1 code that goes from the _uncal files to the _rate files is the source of the problem in the noise modeling. The pipeline is simply not correctly counting the number of photons, which the example that @mmasedahttps://urldefense.com/v3/__https://github.com/mmaseda__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!3tP6Y4oybl56LIwwviSb4up2eu_cb1jVch-SWY90V37fl8B5WkMr8EhnHKvktPpHVET0-MgL9qbbh_xJ4wdkaX0$ posted here makes abundantly clear. For that test, we intentionally focused on a wide NIRSPEC slit that is obviously background limited, so read noise cannot be the issue.

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/spacetelescope/jwst/issues/7362*issuecomment-1527803365__;Iw!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!3tP6Y4oybl56LIwwviSb4up2eu_cb1jVch-SWY90V37fl8B5WkMr8EhnHKvktPpHVET0-MgL9qbbh_xJAX8SFC8$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AF6KJLTL6EPZHQSOREKNLGDXDPVWRANCNFSM6AAAAAASF5PT5Q__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!3tP6Y4oybl56LIwwviSb4up2eu_cb1jVch-SWY90V37fl8B5WkMr8EhnHKvktPpHVET0-MgL9qbbh_xJjvjyc1o$. You are receiving this because you were mentioned.Message ID: @.***>