# Fix decam gen3 ingest

XMLWordPrintable

#### Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Story Points:
8
• Sprint:
AP S20-2 (January)
• Team:
• 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

1. gen3ingest.dot
100 kB
2. gen3ingest.dot.pdf
67 kB

#### Activity

Hide
John Parejko added a comment -

That certainly is part of it. I don't know if it's all of it though. 6x slower is quite a lot.

Show
John Parejko added a comment - That certainly is part of it. I don't know if it's all of it though. 6x slower is quite a lot.
Hide
Tim Jenness added a comment -

3 times isn't it?

Show
Tim Jenness added a comment - 3 times isn't it?
Hide
John Parejko added a comment -

gen3 is 180s for just raws. gen2 is 60s for raw+calib+defect, and by-eye timing the raws are about half of that.

Show
John Parejko added a comment - gen3 is 180s for just raws. gen2 is 60s for raw+calib+defect, and by-eye timing the raws are about half of that.
Hide
Tim Jenness added a comment - - edited

In theory we could modify ObservationInfo constructor so that you could select which properties you want calculated (or allow all the translations to be on demand). That would at least allow ingest to only ask for the handful of items it needs. I don't think gen2 ingest was switched over to use ObservationInfo yet (obs_lsst does).

Show
Tim Jenness added a comment - - edited In theory we could modify ObservationInfo constructor so that you could select which properties you want calculated (or allow all the translations to be on demand). That would at least allow ingest to only ask for the handful of items it needs. I don't think gen2 ingest was switched over to use ObservationInfo yet (obs_lsst does).
Hide
John Parejko added a comment -

Thanks for the review comments. I believe I've addressed them all.

Show
John Parejko added a comment - Thanks for the review comments. I believe I've addressed them all. New Jenkins run: https://ci.lsst.codes/blue/organizations/jenkins/stack-os-matrix/detail/stack-os-matrix/31113/pipeline

#### People

Assignee:
John Parejko
Reporter:
John Parejko
Reviewers:
Tim Jenness
Watchers:
Colin Slater, Jim Bosch, John Parejko, John Swinbank, Tim Jenness