Details
-
Type:
Story
-
Status: Invalid
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: meas_base
-
Labels:
-
Epic Link:
-
Team:Data Release Production
-
Urgent?:No
Description
Production multiband logs are full of lines of the form:
84166 WARN 2017-05-17T20:50:00.807-0400 multiBandDriver.measureCoaddSources.mea
|
surement: Error in ext_convolved_ConvolvedFlux.measure on record 385455791349444
|
17:
|
File "src/CoaddPsf.cc", line 259, in virtual std::shared_ptr<lsst::afw::image:
|
:Image<double> > lsst::meas::algorithms::CoaddPsf::doComputeKernelImage(const Po
|
int2D&, const lsst::afw::image::Color&) const
|
Cannot compute CoaddPsf at point (32315, 728); no input images at that point
|
. {0}
|
lsst::pex::exceptions::InvalidParameterError: 'Cannot compute CoaddPsf at point
|
(32315, 728); no input images at that point.'
|
This error occurs for any measurement algorithm that uses the PSF, and does not get silenced as other errors do. The chatter from such errors makes it difficult to spot bona fide errors in the logs. And the logs are huge: a few gigabytes per tract.
The problem is that CoaddPsf (correctly) throws an InvalidParameterError rather than a MeasurementError (which would get swallowed), but the boilerplate for handling that correctly (catch the exception, re-throw as a MeasurementError with the appropriate type) is a pain. Perhaps a convenience method in the Algorithm class would be helpful?
Attachments
Issue Links
- mentioned in
-
Page Loading...
Activity
I'm sure you'll be able to think of something more clever, then. I don't think we can rely on all measurement algorithms incorporating boilerplate to catch CoaddPsf errors, so I think there has to be something baked into the framework.
Paul Price
added a comment - I'm sure you'll be able to think of something more clever, then. I don't think we can rely on all measurement algorithms incorporating boilerplate to catch CoaddPsf errors, so I think there has to be something baked into the framework. I don't think we see this problem anymore, but I'd like to try to reproduce before closing.
FWIW, the following from the w_2021_10 RC2 run returns zero results:
$ grep "CoaddPsf" /datasets/hsc/repo/rerun/RC/w_2021_10/DM-29074/logs/08_multiBandDriver/* |
(but the limited dataset may not cover this "edge").
I actually couldn't find any examples of existing log files (including the DM-23243 PDR2 run) that return any results.
Rethrowing as MeasurementError properly requires setting up a per-algorithm specialized flag for the error, which requires code in the algorithm constructor as well as its measure method. I'm a bit skeptical that we'll be able to refactor that into shared code.