Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Story Points:2
-
Epic Link:
-
Team:Data Release Production
-
Urgent?:No
Description
When trying to process HSC g-band data for exposure 106126 detector 33, the ISR task fails with the error:
Failed to initialise spline for type akima, length 1 {0}
|
This exposure was part of a larger run, running the $CP_PIPE_DIR/pipelines/cpSky.yaml pipeline to produce sky frames; all HSC-g detector 33 ISR tasks failed for this run.
On closer inspection, detector 33 is unusual, with amps 0 and 1 saturated, and amps 2 and 3 seemingly producing usable scientific results. An example raw image for the above data ID is attached to this ticket, for reference.
An example log showing the above error is also attached to this ticket.
Attachments
Activity
Jenkins run: [-https://ci.lsst.codes/blue/organizations/jenkins/stack-os-matrix/detail/stack-os-matrix/35832/pipeline-]
Thanks for looking at this so quickly Chris; all on the PR looks good to me. I've ran a local check to confirm that the above data ID now completes successfully. I attach the postISRCCD image for reference. Assuming Jenkins doesn't complain, then I think this is good to merge - cheers!
Sorry to throw a spanner in the works at the 11-th hour, but I've just tried a different data ID, and running it on this ticket branch does not appear to resolve the error message.
Specifically, I'm trying to run HSC exposure 101380 detector 33. The error message is:
Failed to initialise spline for type akima, length 4 {0}
|
I think the example data IDs I was looking at yesterday were only finding 1 data point, whereas this data ID is finding 4. The original ticket branch fix looks for a threshold of at least 3 data points, hence the reason why it seemingly worked yesterday, but doesn't work today. Thanks for the chat on Slack, Chris - I agree, upping the N-data-point threshold to 5 should probably resolve this - cheers!
Jenkins should be working again, so:
Despite the Jenkins oddities recorded above (centos failed, but macos passed), I've been using this ticket branch to process a large number of quanta (of the order 1E5 ISR task quanta), and so far all seems to be well.
I suspect the above Jenkins weirdness is unrelated to this ticket, and is instead linked to the failure to merge drp_pipe issue being discussed on Slack. Hopefully, this should be resolved for w_2022_07.
This appears to be a failure only on Amp 0.
In any case, when there are insufficient points, the fitter now returns a scalar float value. The measureVectorOverscan then identifies this case, applies that scalar value as the overscan fit and returns a mask that fully masks the amplifier (this is redundant in the case of HSC detector 33, as both the overscan mask and the defects will mask that amplifier).
I've also run a test with a non-spline fitter (CHEB) which does the correct thing, even though that fitType does run successfully (returning an array of floats, which does not trigger this work around).