| 8 | | * Detrending: |
| 9 | | * Dark Correction : The camera temperatures have been changing more |
| 10 | | than expected this summer. We found in Run 2 that our dark |
| 11 | | corrections were over- or under-correcting the dark current based |
| 12 | | on the reported temperature changes for the devices. We |
| 13 | | attributed this to the detector temperatures, which are measured |
| 14 | | on the package some distance from the actual silicon wafer, |
| 15 | | failing to measure the device silicon temperatures very |
| 16 | | reliably. We decided to limit the dark current model to a |
| 17 | | function of exposure time, and ignore the temperature. However, |
| 18 | | it now appears that the overall camera temperature changes are |
| 19 | | large enough that they cause significant extra dark current. We |
| 20 | | are pursuing a strategy of using a median camera temperature to |
| 21 | | guide the dark correction for all chips. The data in this |
| 22 | | release does not yet reflect that change. |
| 23 | | * y-band fringing. The new y filter appears to produce a much |
| 24 | | stronger y-band fringe pattern. Since we were not expecting |
| 25 | | y-band fringes, they are not measured and corrected. We are now |
| 26 | | generating y-band fringe masters, and will apply the correction |
| 27 | | in future data releases. |
| | 8 | == Detrending == |
| | 9 | * '''Dark Correction:''' The camera temperatures have been changing more |
| | 10 | than expected this summer. We found in Run 2 that our dark |
| | 11 | corrections were over- or under-correcting the dark current based |
| | 12 | on the reported temperature changes for the devices. We |
| | 13 | attributed this to the detector temperatures, which are measured |
| | 14 | on the package some distance from the actual silicon wafer, |
| | 15 | failing to measure the device silicon temperatures very |
| | 16 | reliably. We decided to limit the dark current model to a |
| | 17 | function of exposure time, and ignore the temperature. However, |
| | 18 | it now appears that the overall camera temperature changes are |
| | 19 | large enough that they cause significant extra dark current. We |
| | 20 | are pursuing a strategy of using a median camera temperature to |
| | 21 | guide the dark correction for all chips. The data in this |
| | 22 | release does not yet reflect that change. |
| | 23 | * '''y-band fringing:''' The new y filter appears to produce a much |
| | 24 | stronger y-band fringe pattern. Since we were not expecting |
| | 25 | y-band fringes, they are not measured and corrected. We are now |
| | 26 | generating y-band fringe masters, and will apply the correction |
| | 27 | in future data releases. |
| 29 | | * Calibration |
| 30 | | * Astrometry: Based on reports from Doug Finkbeiner and Eddie |
| 31 | | Schlafly, we have recently realized that the reference astrometry |
| 32 | | and photometry DVO database is in an older format with RA & DEC, |
| 33 | | taken from 2MASS, represented as floats. As a result, there are |
| 34 | | systematic errors on the scale of 0.1 arcsec in localized areas, |
| 35 | | and additional scatter in the range of 50 mas or so. Note that |
| 36 | | the systematic offsets are consistent for large areas, but change |
| 37 | | over the sky. We are updating the reference database to use |
| 38 | | doubles and future releases will use the improved calibration. |
| 39 | | * Photometry: the photometric calibration is based on the synthetic |
| 40 | | grizy generated from a combination of 2MASS, USNO-B, and Tycho |
| 41 | | photometry. In practice, the photometry is dominated by the |
| 42 | | extrapolation from 2MASS. Eric Bell has shown that the |
| 43 | | photometry has systematic trends relative to SDSS. Further |
| 44 | | exploration suggests that the photometry may be most reliable at |
| 45 | | bright magnitudes, but may have systematic biases for fainter |
| 46 | | magnitudes. The effect is most pronounced it the g-band. The |
| 47 | | photometric calibration probably depends on the collection of |
| 48 | | input reference stars used. We are looking into using either an |
| 49 | | empirical correction or simply a brighter subset of the reference |
| 50 | | stars. Our expectation is that the 2MASS-based synthetic |
| 51 | | photometry can potentially yield zero points which are good to 5% |
| 52 | | or so. However, until these biases are understood, the |
| 53 | | calibration should be used with care, and is probably no better |
| 54 | | than several tenths of magnitudes. |
| | 29 | == Calibration == |
| | 30 | * '''Astrometry:''' Based on reports from Doug Finkbeiner and Eddie |
| | 31 | Schlafly, we have recently realized that the reference astrometry |
| | 32 | and photometry DVO database is in an older format with RA & DEC, |
| | 33 | taken from 2MASS, represented as floats. As a result, there are |
| | 34 | systematic errors on the scale of 0.1 arcsec in localized areas, |
| | 35 | and additional scatter in the range of 50 mas or so. Note that |
| | 36 | the systematic offsets are consistent for large areas, but change |
| | 37 | over the sky. We are updating the reference database to use |
| | 38 | doubles and future releases will use the improved calibration. |
| | 39 | * '''Photometry:''' the photometric calibration is based on the synthetic |
| | 40 | grizy generated from a combination of 2MASS, USNO-B, and Tycho |
| | 41 | photometry. In practice, the photometry is dominated by the |
| | 42 | extrapolation from 2MASS. Eric Bell has shown that the |
| | 43 | photometry has systematic trends relative to SDSS. Further |
| | 44 | exploration suggests that the photometry may be most reliable at |
| | 45 | bright magnitudes, but may have systematic biases for fainter |
| | 46 | magnitudes. The effect is most pronounced it the g-band. The |
| | 47 | photometric calibration probably depends on the collection of |
| | 48 | input reference stars used. We are looking into using either an |
| | 49 | empirical correction or simply a brighter subset of the reference |
| | 50 | stars. Our expectation is that the 2MASS-based synthetic |
| | 51 | photometry can potentially yield zero points which are good to 5% |
| | 52 | or so. However, until these biases are understood, the |
| | 53 | calibration should be used with care, and is probably no better |
| | 54 | than several tenths of magnitudes. |
| 56 | | * Other |
| 57 | | * Astrometry keywords. Several issues with the astrometry keywords |
| 58 | | have been reported. We are aware that the headers of the CHIP |
| 59 | | data have both CDi_j style WCS keywords and PC00i00j style |
| 60 | | keywords. Not surprisingly, FITS readers are confused by |
| 61 | | multiple, conflicting representations. We have also had reports |
| 62 | | from Nigel Metcalf that the stack headers are missing both |
| 63 | | EQUINOX and RADECSYS keywords, causing trouble for various |
| 64 | | readers. Finally, the CHIP astrometry is linearized from our |
| 65 | | high-order model. On the scale of a chip, the distortion is |
| 66 | | sufficiently large that the linear version will perform poorly. |
| 67 | | We have not yet chosen one of the non-linear WCS options. |
| 68 | | * FITS Compression, BSCALE & BZERO: We have found a bug in the |
| 69 | | routines that convert from the 32bit float internal |
| 70 | | representation to the 16bit integer output format. The effect of |
| 71 | | this bug is that the data values as written have a constant |
| 72 | | offset of a small number of DN. |
| 73 | | * Missing chips / warps / etc: there is a bug in a portion of the |
| 74 | | photometry code which occasionally results in an unexpected |
| 75 | | failure to detect stars. These images are treated as if they |
| 76 | | were blank, and are assigned a poor data quality. As a result, |
| 77 | | individual chips or skycells may be missing from an exposure. |
| | 56 | == Other == |
| | 57 | * '''Astrometry keywords:''' Several issues with the astrometry keywords |
| | 58 | have been reported. We are aware that the headers of the CHIP |
| | 59 | data have both CDi_j style WCS keywords and PC00i00j style |
| | 60 | keywords. Not surprisingly, FITS readers are confused by |
| | 61 | multiple, conflicting representations. We have also had reports |
| | 62 | from Nigel Metcalf that the stack headers are missing both |
| | 63 | EQUINOX and RADECSYS keywords, causing trouble for various |
| | 64 | readers. Finally, the CHIP astrometry is linearized from our |
| | 65 | high-order model. On the scale of a chip, the distortion is |
| | 66 | sufficiently large that the linear version will perform poorly. |
| | 67 | We have not yet chosen one of the non-linear WCS options. |
| | 68 | * '''FITS Compression, BSCALE & BZERO:''' We have found a bug in the |
| | 69 | routines that convert from the 32bit float internal |
| | 70 | representation to the 16bit integer output format. The effect of |
| | 71 | this bug is that the data values as written have a constant |
| | 72 | offset of a small number of DN. |
| | 73 | * '''Missing chips / warps / etc:''' there is a bug in a portion of the |
| | 74 | photometry code which occasionally results in an unexpected |
| | 75 | failure to detect stars. These images are treated as if they |
| | 76 | were blank, and are assigned a poor data quality. As a result, |
| | 77 | individual chips or skycells may be missing from an exposure. |
