Known Issues

Repeat Sources Due to Check-pointing

The legacypipe code applied a series of check-points in case of failures during processing. Unfortunately, when the code resumed after a check-point failure, it sometimes produced a duplicate of the same source. These duplicates can be identified because they have identical coordinates and fluxes but a different OBJID. An example repeated source is here:

https://www.legacysurvey.org/viewer-dev?ra=215.8471&dec=0.0805&zoom=16&layer=decals-dr5&sources-dr5&bricks

This source has the following attributes in catalog-level DR5 data:

(i.e. fluxes and coordinates are identical but OBJID is different).

In DR4, we estimate that there are a few hundred duplicates, based on finding 23 repeat sources in a scan of 4500 of the 58,341 DR4 bricks.

MzLS Repeat Observations

Due to a bug in the MzLS scheduling code, approximately 3500 MzLS exposures were unintentionally repeated between February 2nd, 2017 and March 27, 2017. Certain MzLS fields have therefore been covered more than the expected ~3-4 times. In fact, about 100 fields were observed of order 10 times.

Galdepth

Due to a bug in PSF fitting, columns related to GALDEPTH are incorrect in DR4. Corrupted files and entries include:

Tractor catalogues (all)

• galdepth_{g,r}

• apflux_resid_{g,r}

Tractor catalogues (large blobs only)

• ra_ivar

• dec_ivar

• fracdev_ivar

• flux_ivar_{g,r}

• fracflux_{g,r}

• fracin_{g,r}

• fracmasked_{g,r}

• rchi2_{g,r}

• shapeexp_{r,e1,e2}_ivar

• shapedev_{r,e1,e2}_ivar

Coadd images (all)

• legacysurvey-*-model-{g,r}.fits

• legacysurvey-*-chi2-{g,r}.fits

• legacysurvey-*-model.jpg

• legacysurvey-*-resid.jpg

Survey-bricks-dr4.fits.gz (all)

• galdepth_{g,r}

In the PSFEx configuration file for BASS images, we set PSF_SAMPLING to auto (0.0) rather than to fixed (1.0). PSFEx then automatically chooses a pixel scale (0.455″ per pixel times a factor roughly between 0.8 and 1.2), which is then mis-interpreted by legacypipe. For various reasons, legacypipe using a different set of code for model rendering (e.g. coadd model images) and model fitting (e.g. convolving a PSFEx and galaxy model) so the incorrect pixel scale in used in different cases.

In the first case, model rendering uses the incorrect PSFEx pixel scale, so all g,r-band "coadd" images are wrong. This happens for:

• legacysurvey-*-model-{g,r}.fits

• legacysurvey-*-chi2-{g,r}.fits

• legacysurvey-*-model.jpg

• legacysurvey-*-resid.jpg

Model rendering is also used to compute the galdepth and apflux_resid columns in tractor catalogues, so all tractor catalogues have incorrect:

• galdepth_{g,r}

• apflux_resid_{g,r}

Finally, "survey-bricks-dr4.fits.gz" tabulates galdepth_* using the tractor catalogues, so all of its corresponding columns are incorrect:

• galdepth_{g,r}

In the second case, model fitting (for optimization reasons) uses slightly different code for sub-images (roughly the size of the blob that contains possible sources) that are small (height or width \(< 400\) pixels) versus large (height and width \(> 400\) pixels). The threshold for large versus small is hardcoded so that large sub-images correspond to blobs larger than \(400 \times 0.455 / 0.262 \sim 694\) pixels. Sources in small blobs use the correct pixel scale and have no further issues; however, sources in large blobs use the incorrect pixel scale and end up with incorrect values for:

• ra_ivar

• dec_ivar

• fracdev_ivar

• flux_ivar_{g,r}

• fracflux_{g,r}

• fracin_{g,r}

• fracmasked_{g,r}

• rchi2_{g,r}

• shapeexp_{r,e1,e2}_ivar

• shapedev_{r,e1,e2}_ivar

Note, a "quick" fix was possible for the values of galdepth in the "depth" and "galdepth" fits files. So these values were remade and are correct for all bands:

• coadd/*/*/legacysurvey-*-ccds.fits

• coadd/*/*/legacysurvey-*-depth.fits

• coadd/*/*/legacysurvey-*-galdepth-*.fits.gz

"Infs" and "NaNs" in Tractor Catalogues

There are three places where "Inf" or "NaN" can occur in the tractor catalogues. Note, any Inf or Nan in flux_ivar measurements were replaced with "0".

• {RA,DEC,*shape*}_IVAR: "Inf", 37 bricks, object's center is a masked pixel, in some cases "Inf" appears in the corresponding {shape}_IVAR. See https://github.com/legacysurvey/legacypipe/issues/148

• {D,R}CHISQ: "NaN", 7 bricks, occurs near boundary with masked region, at the boundary the image is fine but the model is rendered with very positive or negative outliers. See https://github.com/legacysurvey/legacypipe/issues/147

• MJD_{MIN,MAX}: "NaN", 3,024 bricks, object is at a CCD edge, we could remove quite a few cutting on "sum(NOBS_*) = 0" but not for all of the cases. The fix in "legacypipe" would be to compute NOBS and MJD_MIN/MAX consistently. Currently, NOBS are derived from the pixel in resampled brick space, while MJD_MIN/MAX are derived from the pixel in the CCD image. See https://github.com/legacysurvey/legacypipe/issues/154