Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-438

Use Rings SkyMap by default for all cameras

    XMLWordPrintable

    Details

    • Type: RFC
    • Status: Adopted
    • Resolution: Unresolved
    • Component/s: DM
    • Labels:
      None

      Description

      For DESC's DC2 processing, Nicolas Chotard and I have been discussing the right SkyMap for them to use to best anticipate what we might use in production.

      My recommendation was to use the Rings SkyMap that is currently the default for HSC, but to set the pixel scale to match LSST's native pixel scale and possibly make the tracts larger (by decreasing the numRings parameter) to make them approximately match LSST's focal plane size (the HSC tract size roughly matches the smaller HSC focal plane size).

      I am not at all certain that these are the parameters or skymap we will use in the future - while the HSC configuration has been fine, we've stuck with it mostly because we haven't had a good reason to change it, rather than because we did an exhaustive search for the best parameters based on some criteria.

      That said, I do think it is harmful right now to have different default SkyMaps for different cameras for essentially no reason, and I think it'd be best if we adopted the HSC approach in the other packages by:

      • Making the Rings skymap the default in obs_base/pipe_tasks.
      • Removing obs_* package overrides for the skymap type, and have them only update the pixel scale, numRings, and possibly the tract overlap fraction.

      We would also update the coadd ID calculations attached to the mappers appropriately. The fact that we do this in the mappers rather than the skymap is a bug (should be addressed in Gen3); it means the coadd ID calculations can only be appropriate for the default skymap for that camera, and hence you really can't get away with just changing the skymap via configuration.

        Attachments

          Issue Links

            Activity

            Hide
            ktl Kian-Tat Lim added a comment -

            Given a skymap, it seems that it would be possible for a generic _computeCoaddExposureId method to be written, as well as the number of bits to be computed.  Nevertheless, moving this to the skymap seems reasonable, as it is not clear that the mapper should have direct knowledge of the skymap.

            Show
            ktl Kian-Tat Lim added a comment - Given a skymap, it seems that it would be possible for a generic _computeCoaddExposureId method to be written, as well as the number of bits to be computed.  Nevertheless, moving this to the skymap seems reasonable, as it is not clear that the mapper should have direct knowledge of the skymap.
            Hide
            rowen Russell Owen added a comment -

            I'm neutral. My recollection is that Andrew Connolly was keen on having tracts large enough that they could contain any two overlapping fields. The design document for SkyWcs would have more detail, but that was on Trac and I can't find it there. I have no idea if it was migrated.

            Show
            rowen Russell Owen added a comment - I'm neutral. My recollection is that Andrew Connolly was keen on having tracts large enough that they could contain any two overlapping fields. The design document for SkyWcs would have more detail, but that was on Trac and I can't find it there. I have no idea if it was migrated.
            Hide
            ktl Kian-Tat Lim added a comment -
            Show
            ktl Kian-Tat Lim added a comment - The Trac design document is https://dev.lsstcorp.org/trac/wiki/DM/SAT/SkyMap
            Hide
            nchotard Nicolas Chotard added a comment -

            Should we consider that development can now be made in order to have a standard sky-map for the obs_* packages, starting with an implementation of that changes in obs_base? Or does some else would like to comment on the topic?

            Show
            nchotard Nicolas Chotard added a comment - Should we consider that development can now be made in order to have a standard sky-map for the obs_* packages, starting with an implementation of that changes in obs_base? Or does some else would like to comment on the topic?
            Hide
            jbosch Jim Bosch added a comment -

            I'm sorry, Nicolas Chotard, I somehow made the end-date of this RFC much later than I had intended, and then forgot about it.  I've reset it to this Thursday, and will try to make sure I've addressed all of the potential concerns raised so far by then.

            Show
            jbosch Jim Bosch added a comment - I'm sorry, Nicolas Chotard , I somehow made the end-date of this RFC much later than I had intended, and then forgot about it.  I've reset it to this Thursday, and will try to make sure I've addressed all of the potential concerns raised so far by then.
            Hide
            nchotard Nicolas Chotard added a comment -

            Ok, thanks Jim Bosch.

            Show
            nchotard Nicolas Chotard added a comment - Ok, thanks Jim Bosch .
            Hide
            jbosch Jim Bosch added a comment - - edited

            I took a look through the old SkyMap design document Kian-Tat Lim linked to above.

            Some of the specifications/analyses there don't make much sense in retrospect:

            • Even a fractional variation of 0.6 in pixel area over a tract (what we get with DodecaSkyMap, the current default for obs_lsstSim) seems much higher than we'd like, especially considering how many of our configuration parameters and other processing criteria are specified in pixel units.  I don't think it's a formal problem - I think the only formal requirement on pixel areas/shapes is that we be able to map the pixel grid at any point on the tract to a local tangent plane via an affine transformation.  But a variation this large is certainly inconvenient.
            • The apparently empirical statement that we want a pixel area half the size of the native pixel area does not make sense from a sampling-theory standpoint, unless it is just a statement that given a fractional pixel area variation of 0.6, we need to have approximately twice the pixel sampling in other areas to get at least the native pixel sampling everywhere on the tract.  Using coadd pixels much smaller than the native pixel scale will not carry extra information and will probably make the covariance structure worse.

            As a result, I'm inclined to regard our previous selection of our particular configuration of DodecaSkyMap as almost certainly premature.

            Of the other things discussed on that page, the only constraint that the Rings configuration HSC uses does not meet is the same one Russell Owen mentioned above: the desire to make tract overlaps large enough to fit a full focal plane (and by extension make the tracts much larger than the full focal plane).  I didn't see much reasoning for this constraint in the trac document, but I suspect it's much more relevant for the regions in which we do jointcal-style operations than the regions we coadd, which do not need to be the same (though they are at present, and there is certainly some convenience benefit to making them the same).  It's also conceivable that background matching would also benefit from having large areas, though I think we'd be much better off in terms of how we parallelize that operation if we develop an algorithm that doesn't need to simultaneously process extremely large areas of sky.

            Overall, I didn't see anything that makes me value that very preliminary design work over the practical experience we now have with the Rings SkyMap (and the Pan-STARRS experience with Rings that builds on).  It's quite possible that the Rings (or the particular configuration(s) we go with now) will not be what we use in operations, but I do think it's the best choice right now.

            Show
            jbosch Jim Bosch added a comment - - edited I took a look through the old SkyMap design document Kian-Tat Lim linked to above. Some of the specifications/analyses there don't make much sense in retrospect: Even a fractional variation of 0.6 in pixel area over a tract (what we get with DodecaSkyMap, the current default for obs_lsstSim) seems much higher than we'd like, especially considering how many of our configuration parameters and other processing criteria are specified in pixel units.  I don't think it's a formal problem - I think  the only formal requirement on pixel areas/shapes is that we be able to map the pixel grid at any point on the tract to a local tangent plane via an affine transformation.  But a variation this large is certainly inconvenient. The apparently empirical statement that we want a pixel area half the size of the native pixel area does not make sense from a sampling-theory standpoint, unless it is just a statement that given a fractional pixel area variation of 0.6, we need to have approximately twice the pixel sampling in other areas to get at least the native pixel sampling everywhere on the tract.  Using coadd pixels much smaller than the native pixel scale will not carry extra information and will probably make the covariance structure worse. As a result, I'm inclined to regard our previous selection of our particular configuration of DodecaSkyMap as almost certainly premature. Of the other things discussed on that page, the only constraint that the Rings configuration HSC uses does not meet is the same one Russell Owen mentioned above: the desire to make tract overlaps large enough to fit a full focal plane (and by extension make the tracts much larger than the full focal plane).  I didn't see much reasoning for this constraint in the trac document, but I suspect it's much more relevant for the regions in which we do jointcal-style operations than the regions we coadd, which do not need to be the same (though they are at present, and there is certainly some convenience benefit to making them the same).  It's also conceivable that background matching would also benefit from having large areas, though I think we'd be much better off in terms of how we parallelize that operation if we develop an algorithm that doesn't need to simultaneously process extremely large areas of sky. Overall, I didn't see anything that makes me value that very preliminary design work over the practical experience we now have with the Rings SkyMap (and the Pan-STARRS experience with Rings that builds on).  It's quite possible that the Rings (or the particular configuration(s) we go with now) will not be what we use in operations, but I do think it's the best choice right now.
            Hide
            jbosch Jim Bosch added a comment -

            Adopting as originally proposed.

            Show
            jbosch Jim Bosch added a comment - Adopting as originally proposed.

              People

              Assignee:
              jbosch Jim Bosch
              Reporter:
              jbosch Jim Bosch
              Watchers:
              Jim Bosch, John Swinbank, Kian-Tat Lim, Nicolas Chotard, Russell Owen
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Planned End:

                  Jenkins

                  No builds found.