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-865 DRP 2-D Pipeline <p>Each PFSA file has a <tt>W_LGTSRC</tt> card, which describes where the spectrograph module light comes from. The choices are currently "sunss", "dcb", "pfi". It would be useful to have that available in the butler registry.</p> <p>Note that we have no design for the observing mode where the two gang connectors come from different light sources. I think I'd vote for composite strings like "dcb/sunss" or "dcb,pfi" over a separate keyword <tt>W_LGTSR2</tt>.</p> PIPE2D-865

Add registry column for the light source(s).

Task Normal Open Unresolved Unassigned cloomis Mon, 28 Jun 2021 19:45:16 +0000 Fri, 13 Jan 2023 12:57:18 +0000 0 4 <p>Adding a registry column will require re-ingesting everything. Perhaps we should leave this until the Gen3 middleware cutover?</p> <p>Sorry, I wasn't paying attention after this went into the headers not the opdb. Why do we need this in the registry (which is just an optimisation)? That is, what code needs to <em>select</em> data based on this entry?</p> <p>"what <span class="error">&#91;source&#93;</span> was that taken with?" and "what is the last set of SuNSS data?", etc. seem to be pretty common questions. That's all. <tt>fitsheader ...../2021*/sps/*</tt> is no fun anywhere, especially on GPFS, and opdb queries require some construction and take some interpretation (that could also be fixed).</p> <p>Given that you don't have any general SQL access to the registry (except by opening it from the command line with <tt>sqlite3</tt>) I don't think that DB queries to the butler registry are the correct solution here.  I'm not especially against it — it's no big deal to reingest all the data, but this seems much more like an opdb query than a butler one.  Gen3 does provide more general SQL, but it's still designed for processing than interrogating the data.</p> <p>So, sure; we can do this but I'd like to think about whether this is the right solution.  Generically Rubin is missing what we're calling "campaign management" to manage processing and analysis, and I suspect that that fits better into that bucket.  It could be the same back-end database, of course.</p> <p>This is one of the questions I raised during yesterday's PU Group telecon. I'm certainly OK with it going through the opDB as it's good to have one central place from which to interrogate data. </p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>: shall we file a new ticket on the opDB and close this one?</p> <p>These are orthogonal questions.   Yes, this should be in the opdb, and we are going to put it in the header.   The question in this ticket is whether we extract the header value (possibly patched) into the registry as a convenient cache.</p> <p> </p> Development Rank 0|02qpjd:00r20060i20018002