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-71 Data Model <p>Define the values of the <tt>TargetType</tt> enum in <tt>datamodel.txt</tt> along with a new enum, <tt>FiberStatus</tt>.</p> <p>Also write this definitions in all the relevant product headers (pfsObject, pfsMerged etc) so they are self-describing.</p> <p>The <tt>TargetType</tt> enum should contain the following values:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> SCIENCE SKY FLUXSTD UNASSIGNED ENGINEERING </pre> </div></div> <p>The new <tt>ENGINEERING</tt> value is to accommodate data where the engineering fibers are illuminated. Note that the fiber characteristics (broken, blocked etc) have been moved. They are now in a new enumeration, <tt>FiberStatus</tt> (or better name), with values:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> GOOD BROKENFIBER BLOCKED BLACKSPOT UNILLUMINATED </pre> </div></div> <p>The value <tt>BROKENFIBER</tt> replaces <tt>BROKEN</tt> (which is confusing as 'BROKEN' could indicate a broken cobra or a fiber). A perfectly functioning fiber is labelled with <tt>FiberStatus==GOOD</tt>.</p> <p> </p> DAMD-71

TargetType should be defined in datamodel.txt and headers

Story Normal Done Done price hassan Fri, 20 Dec 2019 19:31:18 +0000 Mon, 4 Jan 2021 20:23:04 +0000 Mon, 23 Mar 2020 15:53:06 +0000 0 3 <p>I don't think the <tt>TargetType</tt> and <tt>FiberStatus</tt> are orthogonal, as your design implies. If a fiber has a status of <tt>BLOCKED</tt>, it can't be targeted to anything. Similarly for all other fiber statuses than <tt>GOOD</tt>. I suggest that instead of being a separate enumeration, the statuses you have identified should all be included in <tt>TargetType</tt>. We could rename <tt>TargetType</tt> to <tt>FiberTarget</tt> or similar to reflect the all-encompassing nature.</p> <p>Please keep the separate. For example, we could design a plate and then discover that a fibre is broken. They capture different sorts of information.</p> <p>What is the downside?</p> <p>The only downside is extra work for something unnecessary, but I'm happy to do it if you think it's important.</p> <p>Here's an example of the values and definitions in the FITS header:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> HIERARCH TargetType.SCIENCE = 1 / science target HIERARCH TargetType.SKY = 2 / blank sky; used <span class="code-keyword">for</span> sky subtraction HIERARCH TargetType.FLUXSTD = 3 / flux standard; used <span class="code-keyword">for</span> fluxcal HIERARCH TargetType.UNASSIGNED = 4 / no particular target HIERARCH TargetType.ENGINEERING = 5 / engineering fiber HIERARCH FiberStatus.GOOD = 1 / working normally HIERARCH FiberStatus.BROKENFIBER = 2 / broken; ignore any flux HIERARCH FiberStatus.BLOCKED = 3 / temporarily blocked; ignore any flux HIERARCH FiberStatus.BLACKSPOT = 4 / hidden behind spot; ignore any flux HIERARCH FiberStatus.UNILLUMINATED = 5 / not illuminated; ignore any flux </pre> </div></div> <p>I've split <tt>TargetType</tt> into <tt>TargetType</tt> and <tt>FiberStatus</tt>, improved the python docs and put docs in the FITS headers.</p> <p>Oh, this will need a new drp_stella_data. I'll start that now, and hopefully submit it later tonight.</p> <p>There are conflicts between this work and <a href="https://pfspipe.ipmu.jp/jira/browse/DAMD-67" title="Update PfsObject to track input visits in the OBSERVATIONS table" class="issue-link" data-issue-key="DAMD-67"><del>DAMD-67</del></a>, which will need to be resolved.</p> <p>It's important to point out that this changes <tt>PfsDesign</tt> and <tt>PfsConfig</tt>.</p> <p>Merged to master.</p> Relates PIPE2D-492 Development Rank 0|02qprn:8 Reviewers hassan Sprint 2DDRP-2021 A Story Points 2.0