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-91 Data Model <p>There is a strong possibility that the proposed Subaru Night Sky Spectrograph will be built. Provide support for this mode of operation in the PFS datamodel. </p> <p>Expected changes will be in the <tt>pfsDesign</tt> and <tt>pfsConfig</tt> content.</p> DAMD-91

Update datamodel (pfsDesign/config) to support SuNSS mode

Story Normal Done Done hassan hassan SuNSS Fri, 23 Oct 2020 01:05:47 +0000 Fri, 28 Jan 2022 17:16:21 +0000 Fri, 12 Feb 2021 18:17:16 +0000 0 4 <p>Good point.  I think we'll need new <tt>targetType</tt> entries, maybe <tt>DIFFUSE_SKY</tt> and <tt>SUNSS</tt> for the diffused and imaging legs of the instrument respectively. While we're making changes here, we shouldn't list the values of the enumeration in both the description of the DESIGN table and the definition of the <tt>targetType</tt> enum as they can get out of sync.</p> <p>With the current proposal to drive SuNSS to the appropriate hardstop at the beginning of each exposure (or possibly pointing) the rotator angle will not be known until we start observing. I think that this can be handled by having a standard <tt>pfsDesign</tt> for SuNSS which is converted to <tt>pfsConfig</tt> once the angle is known. Ideally this only matters for SuNSS's imaging leg, but that depends on the uniformity of the diffused illumination. This relies on knowing the position angle sufficiently accurately which is not, I think, a problem. If we need a better measurement I suspect that we can get it from a short <tt>n</tt> channel integration summed in the wavelength direction.</p> <p>There is one major difference from regular PFS operations, namely that we cannot specify the <tt>fiberId</tt> in the <tt>pfsDesign</tt> file because we don't control the rotator angle. I think this is OK; we'd set it to -1 (a number which will have to go into the datamodel; real IDs start at 1 so 0 would be an option, but -1 seems safer to me as it's obviously invalid) and the real <tt>fiberId</tt> would be written by the code that writes the <tt>pfsConfig</tt>. Who owns the code that does this transformation? I assume that it's usually done as part of cobra configuration.</p> <p>As discussed on the #commissioning slack channel today: Update the <tt>targetType</tt> entries, to <tt>SUNSS_DIFFUSE_SKY</tt> and <tt>SUNSS_IMAGING</tt></p> <p>I did the minimal work, and generated a SuNSS pfsConfig file as a test but have not yet confirmed that it works.  However, I think that this was enough to close this ticket</p> <p>N.b.  I went with <tt>SUNSS_DIFFUSE</tt> as all diffuse SuNSS fibres are sky fibres.</p> Relates PIPE2D-724 Development Rank 0|02qpq3:08 Reviewers hassan Sprint 2DDRP-2021 A