# Logs are full of "Cannot compute CoaddPsf at point"

XMLWordPrintable

#### Details

• Type: Story
• Status: Invalid
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
• 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::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?

#### Activity

Hide
Jim Bosch added a comment -

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.

Show
Jim Bosch added a comment - 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.
Hide
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.

Show
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.
Hide
Jim Bosch added a comment -

I don't think we see this problem anymore, but I'd like to try to reproduce before closing.

Show
Jim Bosch added a comment - I don't think we see this problem anymore, but I'd like to try to reproduce before closing.
Hide
Lauren MacArthur added a comment -

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. Show Lauren MacArthur added a comment - 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.
Hide
Jim Bosch added a comment -

Good enough for me; thanks for looking into it!

Show
Jim Bosch added a comment - Good enough for me; thanks for looking into it!

#### People

Assignee:
Unassigned
Reporter:
Paul Price
Watchers:
Jim Bosch, Lauren MacArthur, Paul Price