fmadec points out that the slit number is potentially different from the spectrograph number. This may or may not complicate things.

Just for recording...
We had conversations on slack and the option 2 seems preferred (fh+sp*651 in terms of GFM), but Fabrice would like to think a little more about which options is the best. Having the same fiberid between the modules looks also simple.

I was asked to confirm the fiber mapping on the spectrograph side.
According to the design document by Brazil (document on PBworks), the numbering schema of fiber (fh) hole is identical.

GFM doesn't entry three fibers (fh=280, 309, 359) for SM3 and SM4 since there is no counterpart on PFI side. (If the slit is connected to the all fiber lamp, for instance, these three fibers are illuminated)

Note that FCA4, which is now being assembled on SM2 was built lacking three fibers (fh=280, 309, 359). But mapping is correct.

So, I think the fiber index is defined uniquely when you use spectrograph module (not slit serial number). Note that fiber status (blocked/broken/unilluminated) will change in some cases (but I think this is beyond this ticket..).

So, I think the fiber index is defined uniquely when you use spectrograph module (not slit serial number). Note that fiber status (blocked/broken/unilluminated) will change in some cases (but I think this is beyond this ticket..).

That's right. We set those in the pfsConfig file:

      fiberStatus    32-bit int (enumerated type: GOOD,BROKENFIBER,BLOCKED,BLACKSPOT,UNILLUMINATED)

fmadec: do you have any issues with the proposal (option 2, fh+sp*651) ? I propose if there is no issue by end of business Weds 06 Jan 2021, we implement that proposal.

I think you should use multi -index, so option 3 , that will be the most flexible solution.

for my perspective (testing) spectrograph, I like to have identification from spectrograph point view. fiber 2 on SM1 is "identical" to fiber 2 on SMx, I mean it should be at the extreme position , etc ...
I guess that will be useful also using the entire instrument to have a fast way to know which fiber is on which SM.

We need to agree on way to use DCB, allfiber, SunSS ... I though we said we need a dedicated telecon for that, it may be better to have this telecon before we set this, no ?

Hassan needs to arrange a dedicated telecon the week of 18 Jan 2021 to agree on proposal. Participants: Fabrice, Arnaud, Craig, Paul, Robert, Jim, Yuki.

fmadec has no objections with option 2 given that a trivial function can be introduced to decode the fiberId to extract the SM number. So we shall go with option 2.

Code changes are done. I haven't yet built new simulated data (for the integration test and weekly) because there are other tickets touching the same dataset, so we'd have to recreate the data again after they merge.

Should have payed a bit more attention to the grandfibermap.txt changes earlier, sorry.

Ideally, grandfibermap.txt is just a data file and not accessed directly. Until now it has been machine-generated. The trivial code in fiberids.py is supposed to wrap all access – this is the way the ICS (fps/cobraCharmer) accesses the GFM. One could have added a fiberId method or property, though it does not really matter since the GFM will be getting other updates.

The cobras.pdf file covers most of the geometry and nomenclature. The unexplained columns in GFM are:
cm: cobra-in-module. 1-57. 1 is the bottom-left cobra in a module when looked at with the wide (29-cobra) board down. Increasing as you move across the module.
mf: module-in-field. 1-14. The number of the module within the field, with 1 at the center of the PFI.
cf: cobra-in-field (1-798). 57*(mf-1)+cm

Note that the "mod" field is very very confusing and should be renamed. The A and B are not the id of the board, but of the fiber bundle coming off the module.

The "id" column contains the id of the USCONNEC connector hole at the Cable B-C interface according to a convention in a different reference document. I believe that the values are currently both incorrect and incomplete. A different ticket covers updating that map.

cloomis, I've added code to fiberids.py to read that extra column. Is this sufficient to allow merging?

>>> from pfs.utils.fiberids import FiberIds
>>> ff = FiberIds()
>>> ff.fiberId
array([   2,    3,    4, ..., 2332, 2333, 2334], dtype=uint16)

Good for me.

Merged to master.