Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-834

reduce code- and object-duplication in aperture correction and PSF coaddition

    XMLWordPrintable

    Details

    • Story Points:
      8
    • Sprint:
      Science Pipelines DM-S15-6, Science Pipelines DM-W16-1, Science Pipelines DM-W16-2
    • Team:
      Alert Production

      Description

      The aperture correction code to be added on DM-833 will likely not be as closely integrated with CoaddPsf as it could be, because the original design of CoaddPsf didn't anticipate the addition of other, similar classes. We should work on allowing these classes to share code.

        Attachments

          Issue Links

            Activity

            Hide
            jbosch Jim Bosch added a comment -

            To clarify what I was looking for here a bit, I'm not absolutely sure there is a lot of opportunity for a ton of code reuse. I'm just aware that CoaddPsf and CoaddBoundedField do some very similar things, and it'd be worthwhile to look at the implementations and see what they have in common. In particular:

            • Both objects need to store a table of CCDs that went into a coadd, each with weights, a Wcs, and the auxiliary object(s) they need to combine.
            • Both objects need to be able look up which coadds contribute to a given point in coadd pixel coordinates.
            • Both objects need to persist that table of CCDs.
              I think it's also quite possible we'll have other objects in the future that follow a similar pattern, so it might be nice to have some shared utility classes to make writing such objects easier.

            My recollection is that CoaddPsf uses an internal ExposureCatalog to do most of these things, while CoaddBoundedField uses a vector of structs. I don't quite remember why I didn't just use an ExposureCatalog for CoaddBoundedField originally; I think I may have been a little disappointed by how much of CoaddPsf's functionality it didn't provide, but I think it was just mostly that I was in a hurry and I didn't want to figure out how to work it into a slightly different class, especially if that might have required small changes to ExposureCatalog.

            Show
            jbosch Jim Bosch added a comment - To clarify what I was looking for here a bit, I'm not absolutely sure there is a lot of opportunity for a ton of code reuse. I'm just aware that CoaddPsf and CoaddBoundedField do some very similar things, and it'd be worthwhile to look at the implementations and see what they have in common. In particular: Both objects need to store a table of CCDs that went into a coadd, each with weights, a Wcs, and the auxiliary object(s) they need to combine. Both objects need to be able look up which coadds contribute to a given point in coadd pixel coordinates. Both objects need to persist that table of CCDs. I think it's also quite possible we'll have other objects in the future that follow a similar pattern, so it might be nice to have some shared utility classes to make writing such objects easier. My recollection is that CoaddPsf uses an internal ExposureCatalog to do most of these things, while CoaddBoundedField uses a vector of structs. I don't quite remember why I didn't just use an ExposureCatalog for CoaddBoundedField originally; I think I may have been a little disappointed by how much of CoaddPsf's functionality it didn't provide, but I think it was just mostly that I was in a hurry and I didn't want to figure out how to work it into a slightly different class, especially if that might have required small changes to ExposureCatalog.
            Hide
            rowen Russell Owen added a comment -

            See discussion on discourse: https://community.lsst.org/t/discussion-about-unifying-coaddpsf-and-coaddboundedfield-dm-834/293

            The conclusion is that there are no alternatives to the current code design that seem sufficiently attractive to justify the effort.

            Show
            rowen Russell Owen added a comment - See discussion on discourse: https://community.lsst.org/t/discussion-about-unifying-coaddpsf-and-coaddboundedfield-dm-834/293 The conclusion is that there are no alternatives to the current code design that seem sufficiently attractive to justify the effort.

              People

              Assignee:
              rowen Russell Owen
              Reporter:
              jbosch Jim Bosch
              Watchers:
              Jim Bosch, Russell Owen
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.