Status: Won't Fix
Fix Version/s: None
It did in fact used to work correctly in that ingestCuratedCalibs.py could read the output of findDefects.py. I pulled up the w_2020_40 code, and there was a function in cp/pipe/defects.py called _writeData that got called at the end of the FindDefectTask. This wrote things out with the correct file structure so that ingestCuratedCalibs.py could read it. I looked at an output file from that time frame and there is a statement at the end of findDefects.py that says:
findDefects INFO: Writing defects to /project/shared/BOT/rerun/cslage/PTC_LSSTCAM_12638/calibrations/LSSTCam/defects/r01_s00/2020-10-13T01:07:04.651000 in format: BOTH
This is the directory structure that ingestCuratedCalibs.py is looking for. When I pull up the current code, that _writeData function is gone, so the output gets written into the defects directory and ingestCuratedCalibs.py fails when it tries to read it. Perhaps I'm going about things the wrong way. I'm happy to do things a different way if you can point me in the right direction.
- relates to
DM-29581 runISR.py can't find defect files
Looking at your repositories, I see that:
sqlite3 /project/shared/auxTel/rerun/cslage/PTC_Defect_2021-01-21/CALIB/calibRegistry.sqlite3 \
"select * from defects;"
id filter raftName detectorName detector calibDate validStart validEnd
1 None RXX RXX_S00 0 2021-01-26T09:15:21.014929 2021-01-26 2037-12-31
Comparing to the above command, it looks like you're testing on expId=2021012100538, which looks to be prior to the validStart applied to the defects. Manually editing the sqlite UPDATE defect SET validStart='2021-01-01' WHERE id=1 is one solution. For the future, passing a --date 2021-01-01 argument to the ingestAssistant.py command should do this automatically set this. Testing this in a temp directory yields a curated file with the correct date for ingestCuratedCalibs.py.
This is one of the failing points in the gen2 code: calibration date ranges are automatically but inconsistently set at various stages of the generation. This is resolved in gen3, as the certification step explicitly requires the date ranges to be set.
The manual sqlite edit fixed the problem. I've had that problem before - I should have thought of that. I haven't tried the --date option yet.
I re-ran it with a new rerun directory with the --date 2021-01-01 option for ingestAssistant.py. This edited the defect filename with the 2021-01-01 date, but the sqlite registry still showed 2021-01-26 for the valid date, and the ISR failed as before.
I pulled down the latest code and now the --date option is working and the ingestion and ISR ran correctly. However now the makePhotonTransferCurve failed. I think when I got the new code I also got the latest code there, and Andrés had warned me that there were changes because of Gen3, so I need to work on that. I don't think I need any more at this point, but I might ask if I get stuck.
I'm setting this to Won't Fix as we're well on the way to using Gen3 everywhere, and it seems like this isn't an issue any more.
I pulled down tickets/
DM-28346on cp_pipe and ip_isr to test out the fix. I ran it on both ComCam and AuxTel data., and both failed in the same way, as detailed below for the auxTel. I ran the following steps, and with these the defects files were appropriately created and ingested:
The appropriate defect files were then in the CALIB directory, with the file names like this:
However, when I tried to run ISR, it was unable to find the defect files. This command, with doDefect=False successfully ran:
But this command, with doDefect=True, gave a 'No registry for lookup' error. I think there is a problem with the filename and it is not finding it:
Here is the full error log:
Here's the ISR command for the ComCam, if that is easier to deal with: