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-32 Data Model <p>The current <tt>pfsConfig</tt> mechanism covers two different concepts: the <em>design</em> of a targeted field, which is the input to the FPS cobra motion process, and the <em>instantiation</em> of that field where both the measured cobra positions and the starting visit number are known.</p> <p>Discussions have led to the suggestion that we should split <tt>pfsConfig</tt> into:</p> <ul class="alternate" type="square"> <li><tt>pfsFieldDesign</tt>, specifically <tt>pfsFieldDesign-$configId.fits</tt></li> <li><tt>pfsConfig</tt>, specifically <tt>pfsConfig-$configId-$visit0.fits</tt></li> </ul> <p>The only significant internal difference would be the MCS positions and the PFS <tt>visit</tt> from which the field is valid. Given that, the final <tt>pfsConfig</tt> could either refer to the <tt>pfsFieldDesign</tt>, or include it. I think we should denormalize and include it: that single <tt>$pfsConfig-$configId-$visit0</tt> would then neatly contain all that we need to know about field.</p> <p>A couple of notes: the <tt>$configId</tt> is not strictly necessary in the <tt>pfsConfig</tt> file name, since only one configuration can be active at any given time (<tt>visit</tt>+}. But binding the two seems informative.</p> DAMD-32

Split pfsConfig into pre- and post- mapping files.

Task Normal Done Done price cloomis SIM2D Wed, 30 May 2018 13:53:21 +0000 Wed, 3 Apr 2019 20:53:24 +0000 Tue, 29 Jan 2019 21:34:42 +0000 0 4 <p>Blocked. Requires discussion at the architectural level between <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a>, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hassan" class="user-hover" rel="hassan">hassan</a> and possibly LSST members such as <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=jbosch" class="user-hover" rel="jbosch">jbosch</a>.</p> <p>Expect this to move forward end of August, after LSST2018.</p> <p>No need for <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=jbosch" class="user-hover" rel="jbosch">jbosch</a>.  We just have to sort this out;  my original design was wrong and we haven't had time to fix it.</p> <p> </p> <p>I'll edit/split the relevant section of <tt>datamodel.txt</tt>, adding details for discussion.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=price" class="user-hover" rel="price">price</a> to review <tt>datamodel.txt</tt> and make necessary updates to <tt>pfi(Field)Design</tt> and <tt>pfiConfig</tt></p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a> <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=price" class="user-hover" rel="price">price</a>: can we merge to master now?</p> <p>Fine with me.</p> <p>Oh, I see that I own this now. Let me look through it once the dust settles from my trip.</p> <p>We recently agreed that there's no need for us to worry about the design part, at least right now. However, we do need the configuration (the implementation of the observation design that specifies where the cobras ended up for actual exposures) to advance work on the simulator (<a href="https://pfspipe.ipmu.jp/jira/browse/SIM2D-88" title="Compare ETC and SIM2D+DRP2D outputs" class="issue-link" data-issue-key="SIM2D-88"><del>SIM2D-88</del></a>).</p> <p>Here’s the text I’m putting in <tt>datamodel.txt</tt>. Any objections, concerns or comments?</p> <blockquote> <p>The design of a PFI setup, i.e., the targetting of fibers, is a PfiDesign:</p> <p> "pfiDesign-0x%016x.fits" % (pfiDesignId)</p> <p>The choice of a hex format is because the the pfiDesignId is a SHA-1<br/> of the intended fiber positions.</p> <p>FITS file format:</p> <p>HDU #0 PDU<br/> HDU #1 FITS binary table named "DESIGN"</p> <p>The DESIGN table lists for each object:<br/> fiberId 32-bit int<br/> catId 32-bit int<br/> tract 32-bit int<br/> patch string<br/> objId 64-bit int<br/> ra 64-bit float (degrees)<br/> dec 64-bit float (degrees)<br/> pfiNominal pair of 32-bit floats (microns on the PFI)</p> <p>N.b. fiberIds start at 1.</p> <p><del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del>=<del>=</del></p> <p>The realisation of a PfiDesign for a particular exposure is a PfsConfig:</p> <p> "pfsConfig-0x%016x-%06d.fits" % (pfiDesignId, expId)</p> <p>The choice of a hex format is because the the pfiDesignId is a SHA-1.</p> <p>FITS file format:</p> <p>HDU #0 PDU<br/> HDU #1 FITS binary table named "CONFIG"<br/> HDU #1 FITS binary table named "PHOTOMETRY"</p> <p>The CONFIG table lists for each object:<br/> fiberId 32-bit int<br/> catId 32-bit int<br/> tract 32-bit int<br/> patch string<br/> objId 64-bit int<br/> ra 64-bit float (degrees)<br/> dec 64-bit float (degrees)<br/> pfiCenter pair of 32-bit floats (microns on the PFI)<br/> pfiNominal pair of 32-bit floats (microns on the PFI)</p> <p>N.b. fiberIds start at 1.</p> <p>The PHOTOMETRY table lists:<br/> fiberId 32-bit int<br/> fiberMag 32-bit float<br/> filterName string</p> <p>A fiberId may be listed multiple times in the PHOTOMETRY table in order to<br/> provide measurements in multiple filters for a single object.</p> <p>The 'filterName' values in the PHOTOMETRY table will specify particular<br/> transmission curves used by the pipeline, and therefore the range of<br/> permitted values is limited to a set to be specified by the DRP team.<br/> There will be a mechanism for adding to this set.</p></blockquote> <p>I'd say that the PHOTOMETRY table needs to be in the Design file: that is one of the things coming from the targeting/proposal folks.</p> <p>Also that it's worth explicitly stating that a <em>pointing</em> ra/dec must be in the header: where the telescope is slewed to.</p> <p>Moved <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>'s contribution from <tt>tickets/<a href="https://pfspipe.ipmu.jp/jira/browse/DAMD-32" title="Split pfsConfig into pre- and post- mapping files." class="issue-link" data-issue-key="DAMD-32"><del>DAMD-32</del></a></tt> to <tt>u/cloomis/<a href="https://pfspipe.ipmu.jp/jira/browse/DAMD-32" title="Split pfsConfig into pre- and post- mapping files." class="issue-link" data-issue-key="DAMD-32"><del>DAMD-32</del></a></tt> in anticipation of stealing the official ticket branch for my work which is currently on <tt>u/price/<a href="https://pfspipe.ipmu.jp/jira/browse/DAMD-32" title="Split pfsConfig into pre- and post- mapping files." class="issue-link" data-issue-key="DAMD-32"><del>DAMD-32</del></a></tt>.</p> <p>Sorry to give you this as well as the simulator changes, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>, but I think they naturally go to you.</p> <p>Ack, I forgot that there needs to be coordinated changes in drp_stella.</p> <p>Made some fixes in drp_stella, and the PR is open.</p> <p>Merged along with <a href="https://pfspipe.ipmu.jp/jira/browse/PIPE2D-310" title="Modify pipeline flow to match design" class="issue-link" data-issue-key="PIPE2D-310"><del>PIPE2D-310</del></a>.</p> Relates DAMD-49 Development Rank 0|02qpuc:7m Reviewers cloomis