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-108 Data Model <p>When analysing SuNSS data it's very convenient for the pfsArm and pfsConfig files to line up, each with the same number of fibres. This won't be true for the full PFS system with four spectrographs, but if we add a <tt>spectrograph</tt> field to the pfsConfig it'll be easy to work with the data. So let's do it before SM2 arrives.</p> DAMD-108

Please add spectrograph to pfsDesign/pfsConfig file

Story Normal Done Done price rhl Wed, 3 Mar 2021 03:34:05 +0000 Thu, 11 Mar 2021 17:49:33 +0000 Thu, 11 Mar 2021 17:49:32 +0000 0 3 <p>What should the value be in each of the following cases?<br/> 1. Only spectrograph 3 is expected to take data.<br/> 2. Spectrographs 1 and 3 are expected to take data.<br/> 3. All spectrographs are expected to take data.</p> <p>Cancel my previous question. I thought this was a request for a header telling which spectrographs were expected to be used for a particular observation. Now I understand this to be a request to easily provide the subset of fibers for a particular spectrograph. I propose to add <tt>selectBySpectrograph</tt>, along the same lines of <tt>selectByTargetType</tt>, which will return the indices of all the fibers on that spectrograph.</p> <p>I've pushed <a href="https://github.com/Subaru-PFS/datamodel/pull/65" class="external-link" rel="nofollow">an implementation</a> that adds <tt>spectrograph</tt> (and <tt>fiberHole</tt>) properties to <tt>PfsConfig</tt> and <tt>PfsArm</tt>. <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a>, does this do what you need?</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a> rightly points out that the magic number (651) and the functions to translate <tt>fiberId</tt> to <tt>spectrograph</tt> and <tt>fiberHole</tt> belong in pfs&#95;utils, but I'm concerned about adding a dependency to the datamodel package. I'm happy to do either, but someone needs to decide which option we go with.</p> <p>What are the disadvantages of having <tt>datamodel</tt> dependent on <tt>pfs_utils</tt> ? I also felt that the functions should reside under <tt>pfs_utils</tt>.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a> points out that we could put the functions in pfs&#95;utils, and put the new <tt>property</tt> methods in subclasses in drp&#95;stella. This should make everyone happy.</p> <p>I was thinking the same as an alternative option. Fine by me also!</p> <p>Done. Deleted the branch in datamodel, and there are now ticket branches in pfs&#95;utils and drp&#95;stella. I also fixed some off-by-one bugs (all these identifiers are Fortrash!) and added tests.</p> <p>How does this relate to <a href="https://pfspipe.ipmu.jp/jira/browse/PIPE2D-770" title="Support sub-selection of pfsConfig" class="issue-link" data-issue-key="PIPE2D-770"><del>PIPE2D-770</del></a>?</p> <p>It doesn't. I'm working on that independently in the background.</p> <p>Yes, you're right. Sorry.</p> <p>Looks OK. Blame JEG for the 1-based names, I'm not sure why he did that but it's far <em>far</em> too late to change.</p> <p>Merged to master.</p> Development Rank 0|zzs47y:zz Reviewers rhl Sprint 2DDRP-2021 A3