Update for new DeblendCoaddSourcesTask #62
Conversation
| butler=butler) | ||
| measureInputSchema = afwTable.Schema(self.deblendCoaddSources.schema) | ||
| else: | ||
| measureInputSchema = afwTable.Schema(self.mergeCoaddDetections.schema) |
There was a problem hiding this comment.
Does this if/else (line 165 and 185) exist to make this new multiBandDriver backward-compatible with older data products generated with an older Stack?
In other words, for running multiBandDriver.py consistently with a post-DM-15104 Stack, shouldn't self.config.measureCoaddSources.inputCatalog.startswith("deblended") always be true?
There was a problem hiding this comment.
On second look, maybe this part was added to make multiBandDriver more configurable?
There was a problem hiding this comment.
No, this is not always true. Just like before when it was possible to turn the deblender off with doDeblend, it is now possible to skip deblending using inputCatalog="mergeDet".
| self.deblenderOutput.append("deblendedFlux") | ||
| if self.measurementInput not in self.deblenderOutput: | ||
| err = "Measurement input '{0}' is not in the list of deblender output catalogs '{1}'" | ||
| raise ValueError(err.format(self.measurementInput, self.deblenderOutput)) |
There was a problem hiding this comment.
Do lines 166-178 do more than checking if things are configured correctly? The comment suggested so to me. If so, this whole block can practically be removed, right? I'm a bit uneasy such checking lives in pipe_drivers; it looks like introducing additional logics beyond stitching tasks into a workflow.
There was a problem hiding this comment.
You are correct that they only check whether or not the output from the deblender is consistent with the input to the measurements. I feel like it's important to check that the tasks are consistent before running them, otherwise the user would have to wait for the entire deblending task to complete before crashing, and the error might not be obvious.
There was a problem hiding this comment.
I agree with Fred here, there are may times when people are developing things and run pipe drivers either for the data output or to test code. It is always a shame when something you set up to run over night or over a weekend crashes a few hours in. This test is cheap and really help developers from falling into this trap accidentally.
There was a problem hiding this comment.
Could this validation be moved to MultiBandDriverConfig.validate?
The list comprehensions in the mapping functions were using a variable from above loops instead of the local comprehension variable. This change fixes that.
No description provided.