Details
-
Type:
Story
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: pipe_tasks
-
Labels:
-
Story Points:2
-
Sprint:DRP F17-5
Description
ImageDifferenceTask currently requires the output repo to be the same repo that contains coadd templates. This requirement is restrictive for AP, which isn't usually in the business of making templates, and would like to treat templates more like external calibration data and less like an intermediate pipeline product.
This ticket is to add a command-line argument for a third repo in ImageDifferenceTask so that the user may specify the location of science images, templates, and desired output location all independently.
(Note that when GetCalexpAsTemplateTask is invoked in lieu of using a coadd as a template, ImageDifferenceTask looks for the calexp template in the input repo. This is less restrictive for AP, but the ideal case here would also be compatible with the option to specify a third repo.)
Attachments
Issue Links
Activity
I wonder if this issue should be tagged gen2-only. In Gen 3, the introduction of chained collections means the distinction between "input" and "output" collections is largely arbitrary.
Krzysztof Findeisen
added a comment - I wonder if this issue should be tagged gen2-only . In Gen 3, the introduction of chained collections means the distinction between "input" and "output" collections is largely arbitrary. If the AP team are happy with the current way that they use gen3 for this processing then closing this ticket as won't fix is a perfectly fine outcome.
Whoa, yeah, this is a very gen2 ticket. Maybe it expanded somehow in the comments over the years
, but my original gripe was gen2 destination reruns needing to be seeded with template coadds before running image differencing. This is about 20 kinds of irrelevant these days - it's no problem at all for a pipetask run to have multiple input collections, and I'm very happy about that!
If we want to talk about the possibility of processing data among multiple gen3 repos, that deserves its own ticket(s).
Closing as "won't fix."
In fact, I think this is all based on a misconception about the Gen*2* Butler (so 21 kinds of irrelevant).
This certainly needs thought in the gen3 world. We can have chained datastores (files being read from multiple distinct locations) but we can't have chained registries. Also I assume the quantum graph builder will be involved and that requires a single registry.
cc/ Jim Bosch and Kian-Tat Lim.