John Swinbank and Jim Bosch the CalibrateTask rewrite is happening. More specifically, ProcessCcdTask and all its sub-tasks are being reworked to be more modular and to simplify conceptual flow. I don't understand exactly what is being asked for, but it sounds like this should be covered by the requirements and design on clo.

Can I close this and link it back to the ticket with the refactor implementation work in it, DM-4692?

This ticket is requesting an afterburner CmdLineTask that transforms icSrc quantities to absolute units (ra/dec, magnitudes). We already have afterburners for src and some coadd datasets. These afterburners are needed before database ingest, since we no longer transform units during ingest.

So what's required on this ticket in detail would certainly change with the CalibrateTask rewrite, but it still involves functionality that doesn't exist in the old CalibrateTask, and will still be needed after the CalibrateTask rewrite. I'll leave it to you whether to include that work in your other CalibrateTask issues or leave it on this issue.

I see. I'll leave it hear for now, but I think we'll probably move it to a different epic when all is said and done. On a related, but side note, should we need afterburners for this, or is this something that should exist in the task? I guess I'm wondering if you think this is the final solution for this sort of thing, or should we schedule some work to do more design on this?

I do find the current system a bit messy. The challenge is that it isn't something we want to run at the same time we run the main task that generates the raw-unit outputs, but it is something that needs to know a bit about the details of the main task, so it's a parallel hiearchy, and it's always a pain to do that without a lot of boilerplate and code duplication. From a user standpoint, I think we'd want these afterburners to appear like different top-level commands that belong to the same task ("processCcd run" vs "processCcd transform", for instance), but I'm not sure from an implementation standpoint whether they should actually be methods of the same class, given that they don't need all the same instance variables.

O.K. Thanks for the thoughts. I'll keep this in mind.

Superceded by DM-14568