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/INSTRM-1748 Instrument control development <p>With the exception of SuNSS-based <tt>pfsDesign</tt> files (designId=<tt>0xdeadbeef</tt>), it seems that all <tt>pfsDesign</tt> files generated so far do not contain any <tt>fiberStatus</tt> information other than <tt>GOOD</tt>. </p> <p>However, as <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=yuki.moritani" class="user-hover" rel="yuki.moritani">yuki.moritani</a> tells me, of the 2394 available science fibers, 7 are broken, two of those fed to SM1.</p> <p>Please propagate those broken fibers into future <tt>pfsDesign</tt> files.</p> INSTRM-1748

FiberStatus information not propagated to PfsDesign files

Task Normal Done Done monodera hassan EngRun Fri, 7 Oct 2022 01:27:18 +0000 Tue, 29 Nov 2022 17:29:06 +0000 Tue, 29 Nov 2022 17:29:06 +0000 0 5 <p>I believe that the canonical source of Truth is the GFM, but we should be sure that we all agree.</p> <p>I don't see any status information in the attributes of <tt>pfs.utils.fiberids.</tt><tt>FiberIds()</tt> and in the GFM file. I think that we can add a column for the fiber status in the GFM file and use them as the default values in <tt>pfs.utils.pfsDesignUtils.</tt><tt>makePfsDesign()</tt> if the code can read the GFM file (and set to <tt>GOOD</tt> as currently implemented if the code failed to read the GFM file, which is not a good sign, thoguh).</p> <p>Well.. I'm confused with Robert's comment, he is mentioning the current situation, or he is proposing to use GFM.</p> <p>I feel that the built-up instrument information such as "broken fibers" should be handled in the same way as the others. Disabled fiducial fiber ID is stored <em>pfs_instdata</em>, and xml file (under <em>pfs_instdata</em> too) convers the broken fibers on PFI side. So I think these information should be passed when pfsDesign file is created. In addition, .xml file should cover all the broken fibers (<a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-1729" title="Cobra .xml file is missing two broken fiber of SM1" class="issue-link" data-issue-key="INSTRM-1729"><del>INSTRM-1729</del></a>)</p> <p>I also think that having the <tt>PfiDesign</tt> class, which is currently in <tt>ics_cobraCharmer</tt> and can access the cobra XML files, should be moved to <tt>pfs_utils</tt> to help with propagating fiber status information to <tt>pfsDesign</tt> files (<a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-1243" title="Move pfiDesign accessor from cobraCharmer to pfs_utils" class="issue-link" data-issue-key="INSTRM-1243">INSTRM-1243</a>).</p> <p>I'm sorry that I confused things.  I thought we'd decided to use the GFM as the source of truth, but the data in pfs_instdata would be another fine place – I more wanted to emphasise that we need to decide than (apparently incorrectly) propose the GFM.</p> <p>This will be fixed as a part of <a href="https://pfspipe.ipmu.jp/jira/browse/OBSPROC-30" title="Review the pfsDesign generation script in 2022Sep run and plan for 2022Nov run" class="issue-link" data-issue-key="OBSPROC-30"><del>OBSPROC-30</del></a>.</p> <p>This has been implemented in the latest script, so I close this ticket (but see <a href="https://pfspipe.ipmu.jp/jira/browse/DAMD-143" title="add brokenCobra to fiberStatus" class="issue-link" data-issue-key="DAMD-143"><del>DAMD-143</del></a>).</p> Blocks OBSPROC-30 Relates INSTRM-1243 INSTRM-1729 Development Rank 0|zzst9l:zzo Sprint preEngRun08Nov Story Points 3.0