Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: daf_butler, Middleware, obs_base, obs_decam
-
Labels:None
-
Story Points:8
-
Epic Link:
-
Sprint:AP S20-2 (January)
-
Team:Alert Production
-
Urgent?:No
Description
It turns out the work I did on decam for DM-20763 was not complete: I only tested that one dataId could be retrieved from the ingested raw data, but there are two ccds in that file in two different HDUs and the second one is not actually getting ingested. The gen2 CameraMapper path for a decam raw looks like decam%(visit)07d.fits.fz[%(hdu)d], so the hdu number is baked in there. As far as I can tell, gen3 doesn't have any way to encode hdu number. Maybe this has to be a further specialization in the RawFormatter. File paths that go into butler.ingest have to actually exist, so we will have to do something to the raw paths that we pass into `butler.ingest`.
The gen2 butler registry has an `hdu` field that encodes which hdu to get that raw from. It doesn't look like there's an equivalent `hdu` field anywhere in the gen3 registry: could we add an extra `hdu` field to the `posix_datastore_records` table? That's my best guess as to where it should live.
Attachments
Issue Links
- blocks
-
DM-21862 Extend Gen3 butler support for obs_decam
- Done
-
DM-22655 Genericize gen2to3.py to be useable with any gen2 repo
- Done
- is blocked by
-
DM-23024 Support multi-dataset single file ingest in daf_butler
- Done
- is triggered by
-
DM-20763 Add initial support for Gen3 Butler to obs_decam
- Done
- is triggering
-
DM-23249 New decam ingest tests need skipif for testdata_decam
- Done
That certainly is part of it. I don't know if it's all of it though. 6x slower is quite a lot.