Storing an instrument model

In order to fit the astrometry on full exposures (all CCD) we need to use an instrument model which will be itself the result of a simultaneous fit on multiple images.
The question is : what is the best way to store this model, assuming that it will be encoded in a set of files (probably fits) associated to a given instrument. The file to be used may depend on the filter and on the observing date ?
I am thinking of the mechanism used to store and retrieve Megacam defects, but I am wondering if there is a better way to do it ?

I don’t know how the Megacam defect system works, but I know I’ve always been vaguely dissatisfied with the HSC one, just from a software engineering perspective (it puts the data in obs_subaru, which confuses software versions with instrument versions). I think we eventually want to store this sort of information in a Butlerized repository that’s associated with main data repository in a way that’s similar to the way we store calibration frames. I think @KSK and @npease may have thought about this some; there were some early discussions at the JTM but I don’t know if they’ve gone anywhere since.

The repo-of-repos model that @npease is working on is intended to handle this use case. We need to change cameras from being a special thing loaded in the CameraMapper constructor to something that is loaded from a dataset and that can use the validity interval mechanisms in the Butler. The problem we have right now (being discussed a little in DM-5738) is that we have no good general mechanism for grabbing parts of objects (e.g. Exposures) from different places (although there are attempts to permit this in the Butler code, they’ve never been used). The other big worry I have once that is solved is performance, but we might be able to defer that for future optimization. (Oh, and whether the repositories describing a camera live in the obs_* package or somewhere else is up to you; it would depend on whether these are quite stable or highly variable/experimental.)

FWIW (and slightly off-topic), that sounds like how obs_decam handles defect currently. Defect is a Butler calibration dataset type in DecamMapper and resides outside obs_decam like other calibration data. There have been requests to move it into obs_decam though. What is preferred?

This sounds like the information that is currently in the cameraGeom model of the object. It used to be a .paf file, but I think @KSK changed (== fixed that).

The rest of the answers, how to version this object, are on topic of course.

This is exactly the think the CameraGeom is supposed to take care of. If there are things that make that difficult (or non-performant), I’d hope we could fix that rather than inventing a new thing.