Spurious satellite track always masked in same place on mosaic CCD3

[djschlegel]

A “long streak” (DQ=8) is masked in the OOD images in almost exactly the same place in the lower-right of mosaic CCD3 for the night CP20170409. I found 99 of the 204 exposures for that night had this mask feature, where I'm attaching a list of those exposures. I have not looked to see if this happens on other nights.

mosaic-spurious-streaks.txt

[djschlegel]

Dustin notes we are paying attention to and masking DQ=8 pixels for 90prime & mosaic:
https://github.com/legacysurvey/legacypipe/blob/master/py/legacypipe/bok.py#L62
https://github.com/legacysurvey/legacypipe/blob/master/py/legacypipe/mosaic.py#L39
and not masking those in decam:
https://github.com/legacysurvey/legacypipe/blob/master/py/legacypipe/decam.py#L120

[djschlegel]

I'm very, very confused comparing the mosaic OOD files between V4.1 (used for DR8) and V4.3 (latest for DR9). In a random sampling of 100 exposures across all nights from V4.1, cosmics (DQ=5) were always included in the masks. For those same files in V4.3 (latest for DR9), about half have cosmics (DQ=5) and no long streaks (DQ=8), about half have it the other way around, and only a handful have both. I had thought the intention was to mark cosmics and not long streaks, same as for DR8.

Here are examples from 2017-04-09 where masks looked good in V4.1, and have long streaks but no cosmics in V4.3:
mosaic/CP/V4.3/CP20170409/k4m_170410_100714_ood_zd_ls9.fits.fz
mosaic/CP/V4.3/CP20170409/k4m_170410_100930_ood_zd_ls9.fits.fz
mosaic/CP/V4.3/CP20170409/k4m_170410_101148_ood_zd_ls9.fits.fz

Here are examples from 2017-04-09 where masks looked good in V4.1, and have both cosmics and long streaks in V4.3:
mosaic/CP/V4.3/CP20170409/k4m_170410_083938_ood_zd_ls9.fits.fz
mosaic/CP/V4.3/CP20170409/k4m_170410_084156_ood_zd_ls9.fits.fz
mosaic/CP/V4.3/CP20170409/k4m_170410_084413_ood_zd_ls9.fits.fz

[dstndstn]

Hi David, For what it's worth, in DECam we previously discovered that there were some versions (not exactly captured by PLVER, but always <= 4.8.0) where the satellite masking and cosmic ray codes were confused (so we ignore both): https://github.com/legacysurvey/legacypipe/blob/master/py/legacypipe/decam.py#L115 But I wasn't aware of there being a similar problem for Mosaic. cheers, --dustin

…

On Sat, Aug 8, 2020 at 11:53 AM David Schlegel ***@***.***> wrote: I'm very, very confused comparing the mosaic OOD files between V4.1 (used for DR8) and V4.3 (latest for DR9). In a random sampling of 100 exposures across all nights from V4.1, cosmics (DQ=5) were always included in the masks. For those same files in V4.3 (latest for DR9), about half have cosmics (DQ=5) and no long streaks (DQ=8), about half have it the other way around, and only a handful have both. I had thought the intention was to mark cosmics and not long streaks, same as for DR8. Here are examples from 2017-04-09 where masks looked good in V4.1, and have long streaks but no cosmics in V4.3: mosaic/CP/V4.3/CP20170409/k4m_170410_100714_ood_zd_ls9.fits.fz mosaic/CP/V4.3/CP20170409/k4m_170410_100930_ood_zd_ls9.fits.fz mosaic/CP/V4.3/CP20170409/k4m_170410_101148_ood_zd_ls9.fits.fz Here are examples from 2017-04-09 where masks looked good in V4.1, and have both cosmics and long streaks in V4.3: mosaic/CP/V4.3/CP20170409/k4m_170410_083938_ood_zd_ls9.fits.fz mosaic/CP/V4.3/CP20170409/k4m_170410_084156_ood_zd_ls9.fits.fz mosaic/CP/V4.3/CP20170409/k4m_170410_084413_ood_zd_ls9.fits.fz — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#644 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIEH7ML7L4BEEXITPQNLHTR7VYF3ANCNFSM4PYGH2NA> .

[djschlegel]

There are also problems with the 90prime masks. For both 90prime and mosaic, these problems appear to be new to the versions used for DR9, they weren't there in the versions used for DR8.

[djschlegel]

It doesn't look like the behavior for any given exposure can be determined from PLVER or PLRPOCID. For the example night CP20170409, all files have PLVER=V4.3, PLPROCID=95b798e, yet all of the different behaviors are exhibited.

[fvaldes]

Notes as I look into this.

1. The absence of CR codes (5) is when the estimated seeingp is less than 4 pixels (in the last reprocessing) in both MzLS and BASS.
2. The streak occurs because the angle corner is detected as a large thin source. Because of the angle the position angle of the source is not 0 or 90 but, in this case, 82, which is accepted as the streak.
3. Anyway, the detection of the edge as a source is from some obscure bug that is dropping the initial edge masking when doing segmentation in quadrants. My intention is to workaround the bug since it is buryed quite deep in complex masking system.