Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: obs_lsst
-
Story Points:5
-
Epic Link:
-
Team:Data Release Production
-
Urgent?:No
Description
The investigation on PREOPS-885 has highlighted the need to pay attention to the quality of the SFM processing PSF modeling and to impose criteria on certain metrics such that those calexps that fail to meet them do not get included in the coadds. Such a guard is available via the PsfWcsSelectImagesTask and is, in fact, in use in HSC processing via the retargeting of the selection task in the makeWarp step of the DRP.yaml pipeline in obs_subaru here. This PSF quality filtering should be activated for LSSTCam-imSim processing as well (ideally in time for the coaddition processing phase for the DP0.2 run!) Some thought should be made as to the appropriate values of the two thresholds – maxEllipResidual and maxScaledSizeScatter -- to set for these data (this will be provided on this ticket for currently available data).
Attachments
Issue Links
Activity
I ran Lauren MacArthur's notebook to generate similar plots for some of the Merian survey DECam data we've recently been reducing. Plots attached below:
These data reductions took place on the tiger2-sumire machine at Princeton, using w_2022_02 and the $OBS_SUBARU_DIR/pipelines/DRP.yaml pipeline. The above plots make use of data in the DECam/runs/merian/w_2022_02/202111 collection.
For these data, it seems the maxEllipResidual and maxScaledSizeScatter thresholds are perfectly reasonable for DECam data processing - at least in the two narrow-bands (N540 and N708) explored here. If more DECam bands become available, it might be useful to check this again at that time.
That's awesome (and a huge relief)! Thanks for looking into this so quickly, Lee Kelvin !!
We now have the SFP outputs for the full DP0.2 dataset (PREOPS-905), so I have created the distribution plots for them:
Seen in this full context, I'm feeling like the thresholds may be a bit tight, but not alarmingly so. In the most extreme case (g-band psfScaledDeltaSizeScatter), we are loosing ~3% of the detectors for a given band. By contrast, our highest rejection fraction in the HSC-RC2 dataset is ~6%.
Yusra AlSayyad had some concern (in the context of "bestSeeing" selections) that the failures would be preferentially selecting away the "good seeing" images. The initial trends from the smaller datasets indicated this should not be a worry, but it's definitely worth looking into this for the full DP0.2 dataset. The following shows the PSF metrics as a function of psfSigma. The shaded area represents the detectors that will get rejected with current thresholds:
Again, we see a slight trend of worse psfStarScaledDeltaSizeScatter with smaller psfSigma, but we are certainly not loosing a vast majority of the best seeing data, so I don't think this should be a worry.
To dig slightly deeper, the following shows the distribution of various parameters with RA/Dec. The rows are by band and the columns are for different parameters. Note that for all but the zeroPoint and skyBg panels (rightmost two columns) the colourbars are matched, so one can directly discern trends with bandpass. Of particular note here, I set the maximum value for the medianE and psfStarScaledDeltaSizeScatter (middle two columns) to their thresholds such that those not passing are in red. I sorted the tables by the latter, so the failures really "rise to the top" on those panels.
They seem to be reasonably distributed on the sky, so I don't think we will disproportionally lose depth in a given area of the sky (I do note that g-band is a real outlier in psfStarScaledDeltaSizeScatter failures).
Here is the same but as a function of Focal Plane coordinates:
Again, they seem to be reasonably distributed.
A community post announcing this change has been added.