Status: To Do
Fix Version/s: None
Team:Data Release Production
When running SingleFrameMeasurmentTask, the input exposure is modified by the noise replacer but is not reset properly, leaving only the last footprint in the exposure when it is returned.
- mentioned in
Talk about a blast from the past! My apologies for the brief (and not very informative) description. I vaguely remember this ticket and what I was doing to discover it in the first place, maybe Nate Lust remembers it better? I remember that I was looking into making measurements on the deblender that would eventually become scarlet, and that there was some condition that caused this to happen. I wasn't sure if it was something I was doing wrong, since I was still pretty naive about how the stack worked at that point, or if it was a true bug, so I ran it by Nate and he confirmed that it was not expected behavior.
I feel like it had something to do with having an exposure, running `SingleFrameMeasurementTask` on it (maybe a subset of the full mergedDet catalog?), and then trying to make a different set of measurements directly on the original coadds. But the second set of measurments returend garbage, so I finally looked at the coadds and that's when I saw that they were all noise except for the last footprint in the catalog that was deblended. When I get back next week I'll look through my old notebooks and see if I can find the one where I discovered this. Then I can hopefully give more information as to how to reproduce this behavior, if the bug still exists.
I think we'd be much more aware of this ticket if this problem was still happening and it happened all the time (as opposed to when an exception interrupts the usual logic). And certainly the code looks like the image would not be restored if an exception propagates through the body of SingleFrameMeasurementTask.run. But I also know that the plugin code run there is already guarded by a try/catch block that transforms more errors into flags and/or warnings.
So, unless Fred Moolekamp can remember more about exactly what the problem is, I think we keep this ticket around to add a try/finally block near https://github.com/lsst/meas_base/blob/72414d6ab44132d4f093a206c2065f67789314a4/python/lsst/meas/base/sfm.py#L324 (that line would be the finally content). But I don't think it's a very high priority.