"Hot Pixel" failure mode for BGS/LRG targets at low redshift

[Astro-Morgan]

Reporting on an issue present in the selection shown in the figure below; SDSS redshifts vs Redrock/QNET redshifts from the DR1 AGN/QSO VAC, the failure mode being reported occurs in the approximate range SDSS_z $\in$ (0.25, 0.6) and RR_z $\in$ (0.15, 0.7). "Hot pixels" for lack of better word.

This failure mode results from a spurious emission-like feature attracting the Ha and [O III]5007 lines despite the spectrum having a clear absorption profile at a separate redshift. This feature occurs in approximately ~40% of the total cases within the above selection. I've attached some examples below showing the RR solution and the VI solution based on the absorption profile:

Here is the distribution of these hot pixels on the wavelength grid. None occur in the wavelength region that is exclusive to the B camera:

And there isn't any correlation between the hot pixel assigned redshift and the VI reshift based on the absorption profiles:

Notably, a decent amount of the other spectra in the selection that these were pulled from are legitimately multi-redshift spectra. Its possible that these hot pixels are real emission features superimposed on the targeted absorption spectrum but the corroborating features are generally very weak and/or correlated with noise even though the hot pixels themselves don't seem to show any/much correlation with noise. Dick Joyce has previously mentioned to Stephanie and I that charge transfer efficiency issues have been noticed in the red cameras so this may be an instrumentation issue related to that. I've attached a fits table for ~140 of these objects with columns ['TARGETID', 'SURVEY', 'PROGRAM', 'HEALPIX', 'FIBER', 'DELTACHI2', 'DESI_Z', 'CORRECT_Z']

hot_pixel_ticket_table.zip

[Astro-Morgan]

Following up, I checked if the errors carried over to DR2/Loa. It looks like many are resolved in Loa. I'm attaching an updated fits file with the Loa redshifts as 'LOA_Z'

hot_pixel_with_loa.zip

[sbailey]

Thanks Andy. I'll paste a subset of the rows here to provide examples that people can chase without having to download and inspect the full list:

     TARGETID     SURVEY PROGRAM HEALPIX FIBER  DESI_Z DELTACHI2 CORRECT_Z        LOA_Z       
      int64       bytes4  bytes6  int64  int64 float64  float64   float64        float64      
----------------- ------ ------- ------- ----- ------- --------- --------- -------------------
39627580013283182   main  bright   17345   237  0.6389      14.3    0.4115  0.6389231421719263
39627616268851837   main  bright   17610   246  0.2785      56.6    0.2937  0.2785537494703602
39627628973393866   main  bright   22716  3413  0.2481    2011.9    0.3013 0.24808203333427717
39627634300162853   main  bright   17611  4416  0.4413      35.7    0.4197  0.4413050868455503
39627646975350555   main  bright   23060  2046  0.3608      18.1     0.288 0.36111683946422113
39627659021386335   main  bright   23060  2912  0.2929      44.7    0.2705  0.2928762014228646
39627670392148794   main  bright   17638  3115  0.2669     130.2    0.4854  0.2669126090064643
39627700263979383   main  bright   18050    78  0.3221     282.5      0.49 0.32205385086967125
39627705808853059   main  bright   18669  1282  0.3737     439.1    0.4141 0.37366684270157036
39627706211500433   main  bright   17394  2637  0.1668    1130.8    0.3948  0.3945381738066573
              ...    ...     ...     ...   ...     ...       ...       ...                 ...
39628278570421601   main  bright   28269   647  0.3386     230.6    0.4369 0.33856671401165256
39628278570421601   main  bright   28269   647  0.3386     230.6    0.4369  0.4366422736997623
39628278583001253   main  bright   28280   108   0.428     297.9     0.358  0.4279639120524057
39628279807742606   main  bright   32429  3677   0.555     308.4    0.4784  0.5550163949660673
39628279807742606   main  bright   32429  3677   0.555     308.4    0.4784  0.4825467406734476
39628284220146775   main  bright   28269  1287  0.2609     290.7    0.3362  0.2608955517930303
39628284224342058   main  bright   28269   945  0.2562     614.2    0.4516 0.45170500011626674
39628284224342058   main  bright   28269   945  0.2562     614.2    0.4516  0.2562404032802958
39628289861488644   main  bright   28280  1155  0.6196     263.7    0.4024  0.6195857754421072
39628289861488644   main  bright   28280  1155  0.6196     263.7    0.4024 0.40244560599120954

Please confirm whether you were basing this on healpix-based redshifts or tile-based redshifts. Nominally healpix based redshifts could have the same TARGETID appears on multiple TILE,FIBER combinations so there isn't necessarily a unique FIBER for a given TARGETID on a single HEALPIX.

I'm also confused about your cases of the same TARGETID being listed twice with different LOA_Z redshifts but other parameters appearing the same, e.g.

     TARGETID     SURVEY PROGRAM HEALPIX FIBER  DESI_Z DELTACHI2 CORRECT_Z        LOA_Z       
      int64       bytes4  bytes6  int64  int64 float64  float64   float64        float64      
----------------- ------ ------- ------- ----- ------- --------- --------- -------------------
39627718345624949   main  bright   18058  1230  0.2108      56.0    0.4828 0.21079827500991724
39627718345624949   main  bright   18058  1230  0.2108      56.0    0.4828  0.4829724286415457

Please double check that bookkeeping.

I'll dig into a few cases and report back.

[sbailey]

Spot checking the first 3 cases, these are unmasked cosmics being incorrectly fit as [OIII]. e.g.

     TARGETID     TILEID  NIGHT   EXPID  FIBER
----------------- ------ -------- ------ -----
39627580013283182  23668 20211021 105506   237

     TARGETID     TILEID  NIGHT   EXPID  FIBER
----------------- ------ -------- ------ -----
39627616268851837  20173 20211119 109522   246
39627616268851837  20173 20211119 109523   246

     TARGETID     TILEID  NIGHT   EXPID  FIBER
----------------- ------ -------- ------ -----
39627628973393866  23044 20211019 105224  3413

The plots were generated with

plot_preproc -t 23668 -f 237 --specprod loa -w 8208.120
plot_preproc -t 20173 -f 246 --specprod loa -w 6403.304
plot_preproc -t 23044 -f 3413 --specprod loa -w 6250.694

where the wavelengths -w come from redshifting [OII] 5008 to the LOA_Z in your file.

This failure mode appears to be the same as #2563, but it is great to have many more examples for testing.

For the record: $CFS/desi/users/sjbailey/dev/andy_outliers/find_tilefibers.py for converting Andy's table rows to TILEID, NIGHT, EXPID, FIBER lists and plot_preproc commands to consider for Halpha and [OIII] mis-identification.

What to do

Fundamentally we need to improve our cosmic ray masking at the CCD level. Other approaches could consider overly narrow spectral features that are adjacent to already masked cosmics on the CCD and/or bad extraction PSF fits (CHI2PIX HDU of frame files).

[Astro-Morgan]

Apologies for the confusion, still learning the details of the survey so I didn't know the difference between the HEALPix and tile redshifts. The redshifts are the HEALPix redshifts for both the 'DESI_Z' and 'LOA_Z' columns. I've also fixed my previous join error so the attached table is now TARGETID, SURVEY, PROGRAM, HEALPIX, DESI_Z, CORRECT_Z, LOA_Z, DELTACHI2

ticket_table_fixed.zip