Details
-
Type:
Story
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: meas_algorithms
-
Labels:
-
Story Points:8
-
Epic Link:
-
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
- has to be done after
-
DM-833 implement coaddition for aperture corrections
- Done
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:
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.