Probably interesting: fiberIds are off by 1 (2 in edge case) between HgAr data and Neon/Krypton data taken in February, even though they have been taken with the same fiber configuration. Observe

butler_HgArFeb = Butler("/tigress/ncaplar/ReducedData/HgArFeb_2019/rerun/Apr30_2019/arc")
arc_HgArFeb = butler_HgArFeb.get("pfsArm", visit=11749, arm="r", spectrograph=1)
arc_HgArFeb.fiberId

gives

array([619, 586, 524, 517, 463, 417, 400, 339, 307, 288, 254, 222, 191,
       110,  62,  31], dtype=uint64)

while

 butler_NeonFeb = Butler("/tigress/ncaplar/ReducedData/NeonFeb_2019/rerun/Apr30_2019/arc")
arc_NeonFeb = butler_NeonFeb.get("pfsArm", visit=12356, arm="r", spectrograph=1)
arc_NeonFeb.fiberId

gives

array([621, 587, 525, 518, 464, 418, 401, 340, 308, 289, 255, 223, 192,
       111,  63,  32], dtype=uint64)

I'm going to guess that this has been fixed by PIPE2D-415, and/or rendered unnecessary by PIPE2D-424. I propose to close it unless ncaplar objects.

I will check this today and report back (today).

I wanted to test this on the data taken in May, but I hit a problem described in PIPE2D-427.

If I do not ingest the updated detectorMap and use the one provided in obs_pfs, the reduction passes and all 10 fibers are recognized. (I now finally understand comment in PIPE2D-411 about ``which detectorMap to choose'''). There are some problems (subtraction seems to be a bit off, i.e., fibers seems to be systematically moved by 1 or 2 pixels; one fiber does not have full length), but I suggest closing this ticket and dealing with that after PIPE2D-358.

Closed by agreement.