46241-r1-bad-extractions.png
[PIPE2D-776] Unexplained BAD_DATA in extracted spectra Created: 12/Mar/21 Updated: 17/Mar/21 Resolved: 17/Mar/21 |
|
| Status: | Done |
| Project: | DRP 2-D Pipeline |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Story | Priority: | Normal |
| Reporter: | rhl | Assignee: | price |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
46241-r1-bad-extractions.png
|
| Sprint: | 2DDRP-2021 A3 |
| Reviewers: | hassan |
| Description |
|
Using /projects/HSC/PFS/Subaru/CALIB-SuNSS-bad to extract the spectra for 46241 r1 results in missing spectra from some rows of the detector, I think, certainly the same index in the pfsArm.flux data. E.g. 46241 r1 the mask for [1751, 1787, 1816, 1832, 1841, 1869, 1874, 1915, 2016] are all set to 256 (NO_DATA). See The data looks fine for that row, and there's nothing obviously wrong with the fiberTrace – and I don't know how that could give problems for a particular pixel for every extracted spectrum. Using /projects/HSC/PFS/Subaru/CALIB-SuNSS I don't see the problem. The CALIB-SuNSS-bad calibs are not good, they were made with only two 10s fibre trace exposures, but I think we need to know what went wrong. I'd also like to see a bit set for why extractions fail in addition to NO_DATA (which can mean other things too). |
| Comments |
| Comment by rhl [ 13/Mar/21 ] |
|
Paul and I think that this must be a problem in the matrix inversion that handles overlapping traces. |
| Comment by price [ 17/Mar/21 ] |
|
Added code to catch zeroes in the diagonal of the matrix, and mask them as BAD_FIBERTRACE. |
| Comment by hassan [ 17/Mar/21 ] |
|
Changes approved with no additional comments. |
| Comment by price [ 17/Mar/21 ] |
|
Merged to master. |
