https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/DAMD-96 Data Model <p>Our current <tt>PfsDesign</tt> (and <tt>PfsConfig</tt>) assumes a single identifier is sufficient to index all fibers in the entire instrument (all spectrographs), which identifier is called <tt>fiberId</tt>. However, it appears that this is not a scheme that is currently supported/approved in the <a href="https://sumire.pbworks.com/w/file/fetch/129816660/PFS-GEN-LNA780701-01_FOCCoS%20Fiber%20Mapping%20revisao%202018-09-17[1833].pdf" class="external-link" rel="nofollow">slit design</a>.</p> <p>I argue that all fibers should appear in the <tt>PfsDesign</tt>, so that the 2D pipeline knows what to extract and record; this means that JEG's "science fiber" index (<tt>sfib</tt> in the <a href="https://github.com/Subaru-PFS/pfs_utils/blob/master/data/fiberids/grandfibermap.20171114.txt" class="external-link" rel="nofollow">"Grand Fiber Map" table</a>) is not sufficient for this.</p> <p>I believe our options are:<br/> 1. Add a spectrograph index to <tt>PfsDesign</tt>, so the primary keys are the spectrograph and the <tt>fiberId</tt>; here, <tt>fiberId</tt> is what JEG calls <tt>hole</tt> and the slit design calls "Slit position". I think the pipeline can work with this, but may need a bit of tweaking.<br/> 2. Extend <tt>fiberId</tt> so that it incorporates the spectrograph: <tt>fiberId= 651*spectrograph + slitPosition</tt>. Then <tt>fiberId=1..651</tt> are on <tt>spectrograph=1</tt>, <tt>fiberId=652..1302</tt> are on <tt>spectrograph=2</tt>, and so on. This is my preferred option, as I think the pipeline already supports it.<br/> 3. Use both schemes, so the <tt>PfsDesign</tt> includes <tt>spectrograph</tt>, <tt>hole</tt> and <tt>fiberId</tt>. This might be the most user-friendly, but I worry about the unnecessary duplication of information.</p> DAMD-96

Index fibers from multiple spectrographs in PfsDesign

Story Normal Done Done price price SuNSS Tue, 24 Nov 2020 16:03:36 +0000 Mon, 1 Feb 2021 21:01:10 +0000 Fri, 29 Jan 2021 18:40:11 +0000 0 6 <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=fmadec" class="user-hover" rel="fmadec">fmadec</a> points out that the slit number is potentially different from the spectrograph number. This may or may not complicate things.</p> <p>Just for recording...<br/> We had conversations on slack and the option 2 seems preferred (<tt>fh+sp*651</tt> 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.</p> <p>I was asked to confirm the fiber mapping on the spectrograph side.<br/> According to the design document by Brazil (<a href="https://sumire.pbworks.com/w/file/141387879/PFS-GEN-LNA780701-04_FOCCoS%20Fiber%20Mapping.pdf" class="external-link" rel="nofollow">document on PBworks</a>), the numbering schema of fiber (<tt>fh</tt>) hole is identical.</p> <p>GFM doesn't entry three fibers (<tt>fh=280, 309, 359</tt>) 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)</p> <p>Note that FCA4, which is now being assembled on SM2 was built lacking three fibers (<tt>fh=280, 309, 359</tt>). But mapping is correct.</p> <p>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..).</p> <blockquote><p>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..).</p></blockquote> <p>That's right. We set those in the pfsConfig file:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> fiberStatus 32-bit <span class="code-object">int</span> (enumerated type: GOOD,BROKENFIBER,BLOCKED,BLACKSPOT,UNILLUMINATED) </pre> </div></div> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=fmadec" class="user-hover" rel="fmadec">fmadec</a>: do you have any issues with the proposal (option 2, <tt>fh+sp*651</tt>) ? I propose if there is no issue by end of business Weds 06 Jan 2021, we implement that proposal.</p> <p>I think you should use multi -index, so option 3 , that will be the most flexible solution.</p> <p>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 ...<br/> I guess that will be useful also using the entire instrument to have a fast way to know which fiber is on which SM.</p> <p>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 ?</p> <p> </p> <p>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.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=fmadec" class="user-hover" rel="fmadec">fmadec</a> 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.</p> <p>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.</p> <p>Should have payed a bit more attention to the grandfibermap.txt changes earlier, sorry.</p> <p>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 &#8211; 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.</p> <p>The cobras.pdf file covers most of the geometry and nomenclature. The unexplained columns in GFM are:<br/> 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.<br/> mf: module-in-field. 1-14. The number of the module within the field, with 1 at the center of the PFI.<br/> cf: cobra-in-field (1-798). 57*(mf-1)+cm</p> <p>Note that the "mod" field is very very confusing and should be renamed. The A and B are <em>not</em> the id of the board, but of the fiber bundle coming off the module. </p> <p>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 <em>values</em> are currently both incorrect and incomplete. A different ticket covers updating that map.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>, I've added code to <tt>fiberids.py</tt> to read that extra column. Is this sufficient to allow merging?</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> &gt;&gt;&gt; from pfs.utils.fiberids <span class="code-keyword">import</span> FiberIds &gt;&gt;&gt; ff = FiberIds() &gt;&gt;&gt; ff.fiberId array([ 2, 3, 4, ..., 2332, 2333, 2334], dtype=uint16) </pre> </div></div> <p>Good for me.</p> <p>Merged to master.</p> Relates INSTRM-1138 Development Rank 0|zzs2rz:zu Reviewers hassan Sprint 2DDRP-2021 A