[PIPE2D-415] Sometimes pfsArm has less elements than number of fibers in the image Created: 01/May/19  Updated: 22/May/19  Resolved: 22/May/19

Status: Done
Project: DRP 2-D Pipeline
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: ncaplar Assignee: price
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File pfsArmKr.png     File pipe2d-415.py    
Issue Links:
Duplicate
is duplicated by PIPE2D-418 ConstructFiberTrace.py only identifie... Won't Fix
Relates
relates to PIPE2D-424 Investigate very wide traces Done
relates to PIPE2D-414 reduceExposure.doSubtractContinuum=Tr... Done
relates to PIPE2D-418 ConstructFiberTrace.py only identifie... Won't Fix
Story Points: 4
Sprint: 2DDRP-2019 E
Reviewers: hassan

 Description   

Possibly closely connected with PIPE2D-414.

naoki.yasuda reports in PIPE2D-339 that ``But for visit=14000 only a half of fibers will be identified (left hand side)``. This is probably the same problem as I report from Krypton data e.g., visit 13052, in PIPE2D-411. There should be 16 fibers but

butler_KrFeb = Butler("/tigress/ncaplar/ReducedData/KrFeb_2019/rerun/Apr30_2019/arc")
arc = butler_KrFeb.get("pfsArm", visit=13052, arm="r", spectrograph=1)
arc.wavelength[14]

fails with 

IndexError: index 14 is out of bounds for axis 0 with size 14

i.e., not all fibers have been identified.

The full script is pfs_Apr30_Kr_Feb.sh in the folder /home/ncaplar/ReductionScripts/Apr30/.

All outputs are in /tigress/ncaplar/ReducedData/KrFeb_2019/.

 Comments   
Comment by ncaplar [ 01/May/19 ]

I have verified that the fibers that are missing in the Krypton example above are on the edge, which is consistent with what naoki.yasuda is reporting.

Comment by naoki.yasuda [ 02/May/19 ]

I'm not sure my problem is the same as this. My problem happens on constructFiberTrace.py and it identifies only five fibers out of 10.

Comment by price [ 17/May/19 ]

It turns out that the reason traces aren’t being found is that some of the fibers are wider on the detector than the trace finder permits. The trace finder does a Gaussian fit of a candidate trace, and compares the derived width and center with some hard-wired values. In this case, the widths are larger than is permitted, so the candidate trace isn't accepted.

The high limit on the Gaussian sigma is the apertureFwhm config parameter, which is 2.5, but sigma ~ 2.7 for the edge trace on visit=13183 arm=r. Opening up the limit allows finding all 16 traces. I’m making the limits configurable, and setting some more permissive defaults.

This also solves PIPE2D-418.

Such wide traces in this data may indicate a misconfiguration of the instrument. The width of the trace varies monotonically from 2.7 on the left to 1.2 on the right, which I suspect is due to optics.

Comment by price [ 17/May/19 ]

hassan, could you please look this over?

Comment by hassan [ 22/May/19 ]

Changes look fine to me. Please go ahead and merge to master.

Comment by price [ 22/May/19 ]

Merged to master.

Generated at Sat Feb 10 15:52:55 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.