Known Data Quality Issues -- Release 2009.07.07

(Up to PS1 Science Processing Status (20090705)) (Up to IPP for PS1)

Here is a list known data quality issues with the Medium Deep field data from April, May, and June 2009, released starting 2009.07.07 (processing tags MD0[678].20090[678].v1)

Detrending

  • Dark Correction: The camera temperatures have been changing more than expected this summer. We found in Run 2 that our dark corrections were over- or under-correcting the dark current based on the reported temperature changes for the devices. We attributed this to the detector temperatures, which are measured on the package some distance from the actual silicon wafer, failing to measure the device silicon temperatures very reliably. We decided to limit the dark current model to a function of exposure time, and ignore the temperature. However, it now appears that the overall camera temperature changes are large enough that they cause significant extra dark current. We are pursuing a strategy of using a median camera temperature to guide the dark correction for all chips. The data in this release does not yet reflect that change.
  • y-band fringing: The new y filter appears to produce a much stronger y-band fringe pattern. Since we were not expecting y-band fringes, they are not measured and corrected. We are now generating y-band fringe masters, and will apply the correction in future data releases.

Calibration

  • Astrometry: Based on reports from Doug Finkbeiner and Eddie Schlafly, we have recently realized that the reference astrometry and photometry DVO database is in an older format with RA & DEC, taken from 2MASS, represented as floats. As a result, there are systematic errors on the scale of 0.1 arcsec in localized areas, and additional scatter in the range of 50 mas or so. Note that the systematic offsets are consistent for large areas, but change over the sky. We are updating the reference database to use doubles and future releases will use the improved calibration.
  • Photometry: the photometric calibration is based on the synthetic grizy generated from a combination of 2MASS, USNO-B, and Tycho photometry. In practice, the photometry is dominated by the extrapolation from 2MASS. Eric Bell has shown that the photometry has systematic trends relative to SDSS. Further exploration suggests that the photometry may be most reliable at bright magnitudes, but may have systematic biases for fainter magnitudes. The effect is most pronounced it the g-band. The photometric calibration probably depends on the collection of input reference stars used. We are looking into using either an empirical correction or simply a brighter subset of the reference stars. Our expectation is that the 2MASS-based synthetic photometry can potentially yield zero points which are good to 5% or so. However, until these biases are understood, the calibration should be used with care, and is probably no better than several tenths of magnitudes.

Other

  • Astrometry keywords: Several issues with the astrometry keywords have been reported. We are aware that the headers of the CHIP data have both CDi_j style WCS keywords and PC00i00j style keywords. Not surprisingly, FITS readers are confused by multiple, conflicting representations. We have also had reports from Nigel Metcalf that the stack headers are missing both EQUINOX and RADECSYS keywords, causing trouble for various readers. Finally, the CHIP astrometry is linearized from our high-order model. On the scale of a chip, the distortion is sufficiently large that the linear version will perform poorly. We have not yet chosen one of the non-linear WCS options.
  • FITS Compression, BSCALE & BZERO: We have found a bug in the routines that convert from the 32bit float internal representation to the 16bit integer output format. The effect of this bug is that the data values as written have a constant offset of a small number of DN.
  • Missing chips / warps / etc: there is a bug in a portion of the photometry code which occasionally results in an unexpected failure to detect stars. These images are treated as if they were blank, and are assigned a poor data quality. As a result, individual chips or skycells may be missing from an exposure.