DECam has inter-CCD crosstalk, which requires resolving https://jira.lsstcorp.org/browse/DM-17169

Here is a proposal that Tim Jenness and I came up with to deal with with raw ingestion:

Each obs_foo package will have a `RawIngestFooTask` and associated executable. This Task will be a subclass of `obs.base.RawIngestTask` that knows the correct `Instrument`. For obs packages that have multiple instruments (e.g. obs_lsst), we propose a `ConfigField` to select the correct instrument (e.g. "Ts8"->"Ts8Instrument", "Latiss"->"LatissInstrument"). This should solve the problem of how to specify the instrument that goes with a set of raw files.

A followup question to this is whether these specialized tasks should have a `doCalibrations` option that runs `writeCuratedCalibrations`, or whether we want a separate `CalibIngestFooTask` for that purpose? We will be doing "raw ingest" much more often than "calibration ingest", but the latter is handled by the same `Instrument` class.

I don't think writeCuratedCalibrations belongs in ingest.  If anything, it belongs in a (TBD) script to register the instrument with the repository, but I don't think even that is quite right; there are several different cadences here, and Instrument's API's aren't really well-aligned to them yet (though they work well for testing and development):

• Register instrument with repository: done exactly once per repository+instrument combination.  Adds "instrument", "detector", and "physical_filter" dimension records.
• Human-curated calibrations change: call writeCuratedCalibrations into a new collection, test them, bless that new collection as the recommended one.
• Hardware changes: add new physical_filter entries, maybe add records of some future dimensions (Tim Jenness and I once talked about having a physical_detector, for example).
• New data is taken: run raw ingest.

What's the motivation for having a per-instrument Task subclass, rather than just per-instrument configuration?  Are we moving abstract methods out of Instrument and into the base Task, or are we just using derived classes as a place to override config variables?

Regarding your final comment, is it a question of ingestDecam.py vs ingest.py --config $OBS_DECAM/config/ingest.py? I think we ask people what they prefer.

A separate command for preparing a butler repo for an instrument is fine with me. This would presumably be allowed to run repeatedly, adding new filters if required, else doing nothing.

I had not considered changing collection every time curated calibrations are ingested. That seems fine to me since you seem to be implying that there will always be a default collection for calibrations.

Regarding your final comment, is it a question of ingestDecam.py vs ingest.py --config $OBS_DECAM/config/ingest.py? I think we ask people what they prefer.

for going with what's considered the best UI.  But also note that we can have different scripts for different cameras without having different tasks, if all the scripts are doing is hard-coding a config override.

I am going to close this ticket as "Done": DM-23976 means that defects are being written in gen3 from obs_decam_data, and DM-22655 got us a mostly-working gen2to3 convert script for decam. DM-23616 includes notes about how to run the script for ap_verify_ci_hits2015, and took care of the groundwork of processing decam data with pipetask. The remaining known issues preventing us from knowing whether the conversion is correct and that we can run gen3 single frame processing are being dealt with on DM-23985, DM-23992, and DM-23983.