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/PIPE2D-1135 DRP 2-D Pipeline <p>The pipeline helpfully assumes that if there are no lamps turned on, then the exposure's on the sky and OI, NaI, and OH lines should be present:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> reduceExposure.readLineList INFO: No lamps on; assuming sky. </pre> </div></div> <p>Unfortunately, the quartz lamps aren't checked when making this guess. Please make sure that we don't look for sky lines when extracting spectra from quartzes (which is a useful check of e.g. fibre normalisations)</p> PIPE2D-1135

Ring lamp needs to be recognised as a lamp

Story Normal Done Done hassan rhl Sun, 18 Dec 2022 11:25:13 +0000 Tue, 7 Feb 2023 22:36:41 +0000 Fri, 23 Dec 2022 14:28:08 +0000 0 4 <p>The requested behaviour has been implemented for a very long time. <a href="https://github.com/Subaru-PFS/drp_stella/blob/master/python/pfs/drp/stella/readLineList.py" class="external-link" rel="nofollow"><tt>ReadLineListTask.getLampInfo</tt></a> calls <a href="https://github.com/Subaru-PFS/obs_pfs/blob/master/python/lsst/obs/pfs/utils.py#L6-L35" class="external-link" rel="nofollow"><tt>getLamps</tt></a>, which returns <tt>"Quartz"</tt>, and therefore the <tt>"No lamps on; assuming sky."</tt> log message and associated behaviour should not fire.</p> <p>You didn't provide information on how to reproduce your problem, but I suspect you may be looking at an exposure that requires a header fix. Perhaps the header fix has been implemented (in pfs_utils) but your corrections database (in obs_pfs) hasn't been rebuilt?</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hassan" class="user-hover" rel="hassan">hassan</a> points out that there are some exposures which are "dome flats" using the top-end ring lamps, which apparently is a separate mode from the "Quartz" lamps. It looks like we can recognise these through the <tt>W_TFFnVC</tt> (commanded) and <tt>W_TFFnVV</tt> (measured) header keywords (for <tt>n = 1..4</tt>). I'll add support for that now.</p> <p>Sorry, Paul, but <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a> mentioned to me that he was thinking of adding a summary card for such exposures. Maybe we should discuss with Craig before implementing anything for now?</p> <p>Ah, OK. So the problem is that we're not setting the quartz header card (<tt>W_AITQTH</tt>). Closing as invalid (except I can't; closing as won't fix); cf. <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-1766" title="Flesh out on-PFI quartz lamp card logic" class="issue-link" data-issue-key="INSTRM-1766">INSTRM-1766</a></p> <p>Those W_TFF cards are the "internal" cards which were added for the 2022-11 run, and we did not understand their actual behavior. We now do and can add the summary `W_AITQTH`.</p> <p>I understand that <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a> will set <tt>W_AITQTH</tt> when the ring lamp is on, and that's good enough for future data, but we need to set <tt>W_AITQTH</tt> for the existing dome flats taken with the ring lamps.</p> <p>200 domeFlat visits were identified from the opDB and header fix code added accordingly.</p> <p>As suggested by Paul, an additional convenience method <tt>rangeIncl()</tt> added to generate inclusive visit ranges. Code updated to use that method.</p> <p>Merged to master.</p> Development Rank 0|02qph7:0h Reviewers price Sprint 2DDRP-2023 A