DM-39858: Integrate new CalibrateImageTask with AP pipeline

[parejkoj]

No description provided.

[kfindeisen]

Changes look better, but I'm worried about whether we want to measure the source count metrics using the old code. Would like to discuss before approving.

[kfindeisen]

I wonder if this file should be a diff on Conversions.yaml (or vice versa, given future plans), given that the only tasks that are different are writeSourceTable and consolidateVisitSummary.

[kfindeisen]

Given that initial_stars does not contain all sources, is this actually still a valid measurement of numSciSources as defined in our specs? Granted, the description that's in there right now is obviously typoed (it would imply fracDiaSourcesToSciSources ≡ 1).

[parejkoj]

Just chatted with @ebellm about this (he happened to be nearby): it's fine that numSciSources will have a different meaning now (and fracDiaSourcesToSciSources will be quite different, too, and potentially > 1!). We should either fix that description, or rename it to be what the description says. If we are going to report such a value, it would have to come from an afterburner-style detection and measurement catalog, a la RFC-938, which we don't have yet.

[kfindeisen]

I think I'd prefer renaming, just so that the same metric always means the same thing and there's no confusion/ambiguity.

So what exactly are "initial stars", and what is the significance of their number?

[parejkoj]

initial_stars is defined as Catalog of unresolved sources detected on the calibrated exposure. As currently designed, it's the list of isolated S/N>10 psf-like sources that are used for astrometric and photometric calibration. The significance of their number tells you something about how many good isolated sources there are on the science image, but I don't know if that's something we really care about as a metric. What was the purpose of numSciSources as it was implemented here?

If we rename this, numSciSources would be None until we get that afterburner implemented.

[kfindeisen]

What was the purpose of numSciSources as it was implemented here?

@ebellm is probably the better source for that, but I assumed it's a measure of how crowded the field is (whereas numInitialStars will be minimized for both very sparse and very dense fields?) And presumably the number of DiaSources we expect is proportional to the total number of sources, not just the isolated ones.

If we rename this, numSciSources would be None until we get that afterburner implemented.

Exactly what I had in mind.

[parejkoj]

Would this be worth spending a few minutes discussing at the Monday AP meeting? "What is the purpose of this metric" is something we should probably have written down in their descriptions (in addition to making sure the description is actually correct!).

[kfindeisen]

The very 🏃 meeting discussion seemed to agree that we don't particularly care about counting the initial stars.

I suppose that means all the "derived" metrics would also be removed? (We really should have had a standalone "number of DiaSources" metric and done the math in Chronograf, but we didn't appreciate that at the time, and it was before DMTN-085 made that the policy.)

[parejkoj]

Per AP meeting discussion today, I've removed all four of these "sci sources" metrics.

Yeah, we probably should have a "number of diaSources" metric. It may be worthwhile to have "number of calibration sources" as well (i.e. the output of this new task). I think that's work for another ticket, though.

[kfindeisen]

Looks good, one last comment about the imports between the old-style and *CalibrateImage.yaml files.