Sogo Mineo (NAOJ) recently uncovered some bugs in the RingsSkyMap, which is the default skymap (which divides the sky into tracts and patches) for HSC and perhaps some other cameras. This has been fixed while maintaining backward compatibility so as to preserve the utility of data processed with the broken skymap. However, users should not create a new RingsSkyMap (e.g., with makeSkyMap.py) and expect that it will correspond to existing data (at least, for the tracts at RA=0) as the new skymap will be created with the fixed version rather than the broken version that the processed data requires: always use the same skymap that you used for the processing.
Details
The idea of RingsSkyMap comes from Tamas Budavari (JHU), and it was used for the Pan-STARRS project; we reimplemented it in the LSST stack for LSST/HSC. In our implementation, the sky is divided into a configurable number of rings in declination, and then those rings are divided in Right Ascension such that the tracts so formed are square.
There were some long-standing off-by-one errors in assigning tracts near the RA=360 line, such that those tracts are in the wrong ring. A side effect of this is that the first and last tracts in the first (southernmost) ring were identical, and the first tract in the last (northernmost) ring was missing. These numbering problems meant that finding tracts near RA=360 didn’t work correctly, which meant that the detect_isPrimary assignment was wrong for these tracts.
We have fixed these problems, while maintaining backward compatibility so as to preserve the utility of skymaps persisted to disk and the associated coadd products that rely on them. Backward compatibility is maintained through the use of version numbers: a RingsSkyMap created with the old code has version=0; new ones will have version=1. These version numbers are automatically set, and are saved when the skymap is persisted; the user should not need to bother about setting a version number under normal circumstances.
version=0 maintains the old (incorrect) tract numbering, but that means that it also maintains the duplicated tract (the first tract in the first ring) and the missing tract (the first tract in the last ring). However, those tracts are a small fraction of the sky, so I have reason to hope that no-one is using them. The position-based lookup methods (findTract/findAllTracts) have been fixed to work with the old/incorrect numbering. Here’s an example of the old (incorrect) tract numbering:
Note that tract 1 (in cyan at 0, -0.75) is identical with tract 10, and there is no tract covering RA=0 in the northernmost ring.
version=1 uses the fixed (correct) tract numbering. The only tracts for which the numbers change are at RA=0. Here’s an example of the fixed (correct) tract numbering, using the same configuration as before:
If you have existing coadds processed with an existing skymap, do not overwrite the skymap with a new skymap, as that would be a new version of the RingsSkyMap with the tracts along the RA=0 line renumbered relative to the old version, and hence there would be a mismatch between the skymap and the coadds. Always use the same persisted skymap that you used for the coadd/multiband processing, and you will get the correct numbering.