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-138 DRP 2-D Pipeline <p>Please change the FiberId identification in FiberTrace::assignITrace and FiberTrace::findITrace<br/> so it assigns the ID of the closest Fiber found in redFiberPixels.fits.gz/redFiberTraces.fits.</p> PIPE2D-138

Fix FiberId identification

Story Major Done Done aritter aritter Fri, 16 Dec 2016 03:22:44 +0000 Tue, 13 Jun 2017 01:55:23 +0000 Tue, 13 Jun 2017 01:55:23 +0000 0 4 <p>We discussed this at the 2017-01-09 meeting. The existing tickets/<a href="https://pfspipe.ipmu.jp/jira/browse/PIPE2D-138" title="Fix FiberId identification" class="issue-link" data-issue-key="PIPE2D-138"><del>PIPE2D-138</del></a> branch contains a single giant commit with a lot of unrelated work. We agreed that @aritter will (in priority order):</p> <ul class="alternate" type="square"> <li>Pull out just the work related to FiberId identification and handle it on this ticket;</li> <li>File other tickets to describe the purely mechanical work (adding line lists, etc) which are currently included in the giant commit, and send them out for review separately;</li> <li>File another ticket to describe the overall strategy for wavelength calibration at LAM, and provide a description there of the approach which is going to be taken. We will review this at a future meeting.</li> </ul> <p>I changed `findITrace` to return the number of the closest predicted FiberTrace. This function will<br/> now always return a positive number, so I also changed the return type from int to size_t and the return type of `assignITrace` from bool to void.</p> <p>Per discussion of 2017-01-18,</p> <ul class="alternate" type="square"> <li>Point 1 above has been done, and is now on this ticket.</li> <li>Points 2 &amp; 3 have not been addressed.</li> </ul> <p>Points 2 &amp; 3 to be attacked on <a href="https://pfspipe.ipmu.jp/jira/browse/PIPE2D-148" title="describe overall strategy for the wavelength calibration" class="issue-link" data-issue-key="PIPE2D-148"><del>PIPE2D-148</del></a>.</p> <p>The single giant commit which was on this ticket branch is now on branch <tt>PFSMeeting</tt>: <a href="https://github.com/Subaru-PFS/drp_stella/tree/PFSMeeting" class="external-link" rel="nofollow">https://github.com/Subaru-PFS/drp_stella/tree/PFSMeeting</a> in separate commits (but Andreas assures me we are not losing anything).</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=swinbank" class="user-hover" rel="swinbank">swinbank</a>, if you haven't started reviewing the ticket yet, I would have 1 more commit to add which I found stashed away, replacing one number with a control parameter</p> <p>Fine. I'll set the ticket back to "in progress"; please let me know (by setting the ticket to "in review") when your additional commit is added.</p> <p>In addition to the comments on GitHub:</p> <ul class="alternate" type="square"> <li>I don't see tests. Specifically, I'd like to see tests which demonstrate that each individual function does what you expect <b>and</b> an overall integration test. You should be able to test (for example) <tt>findITrace</tt> with a variety of different inputs and demonstrate that it always returns the correct trace.</li> <li><a href="https://github.com/Subaru-PFS/drp_stella/pull/15/commits/9072604e4bee80fe8b6ebf488ce9557144ff011e" class="external-link" rel="nofollow">9072604e4bee80fe8b6ebf488ce9557144ff011e</a> is broken: it garbles the argument list of <tt>assignITrace</tt>. You then fix it in a later commit, but that's not good enough: the code should compile after each atomic change.</li> <li><a href="https://github.com/Subaru-PFS/drp_stella/pull/15/commits/9072604e4bee80fe8b6ebf488ce9557144ff011e" class="external-link" rel="nofollow">9072604e4bee80fe8b6ebf488ce9557144ff011e</a> has a misleading commit message: it refers to <tt>yCenter</tt>, but the argument is actually <tt>yCenters</tt>.</li> <li>Why are <a href="https://github.com/Subaru-PFS/drp_stella/pull/15/commits/c08dcb427617691d2a47cb84a54c83e3937b16e5" class="external-link" rel="nofollow">c08dcb427617691d2a47cb84a54c83e3937b16e5</a> and <a href="https://github.com/Subaru-PFS/drp_stella/pull/15/commits/baf1012421a0ca1f9922487b359cb7e6668b9a9d" class="external-link" rel="nofollow">baf1012421a0ca1f9922487b359cb7e6668b9a9d</a> separate commits? If you are changing the return type to reflect changes in the logic of the function, why aren't you changing the return type <b>at the same time</b> as you change the logic?</li> <li>The formatting of the commit message in <a href="https://github.com/Subaru-PFS/drp_stella/pull/15/commits/2f20a2ff6fa1f1a9868b3a8420e7d0760c3de260" class="external-link" rel="nofollow">2f20a2ff6fa1f1a9868b3a8420e7d0760c3de260</a> is incorrect (there's a weird extra new line).</li> <li>In <a href="https://github.com/Subaru-PFS/drp_stella/pull/15/commits/2f20a2ff6fa1f1a9868b3a8420e7d0760c3de260" class="external-link" rel="nofollow">2f20a2ff6fa1f1a9868b3a8420e7d0760c3de260</a> you add the <tt>maxDistance</tt> parameter. However, I can't find anywhere that that parameter is actually used! I'm not sure whether that's because there's something more subtle here than I understand, or whether you forgot. Can you clarify, please? (And as per the first point above: this functionality should be tested, so I can see that it works by just checking that the test runs.)</li> </ul> <p>Mostly quite minor comments, here and on GitHub. However, the lack of tests is a big problem, and I'd like to understand properly how <tt>maxDistance</tt> is being used.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=swinbank" class="user-hover" rel="swinbank">swinbank</a>, I just found out that the fiber IDs in <tt>RedFiberPixels.fits.gz</tt> contain gaps what requires a code change in order to get the correct fiber IDs. I would shortly move this ticket back to 'In Progress' and fix that unless you have any objections...</p> <p>According to <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a> the slit has more positions than there are science fibers, and the<br/> pipelines will only see the science fibers.<br/> The missing fiber IDs are gaps (between the two CCDs, say), fiducial fibers, alignment fibers, etc.<br/> It was decided to number all fibers according to the <em>slit</em> position, and not, say, the science fiber index.</p> <p>That's from me, and I figure I should state the convention: fibers are numbered according to their position along the slit, and not according to their index as visible science fibers. Besides the science fibers which the pipeline sees, there are gaps between fiber bundles and between the two CCDs, and there are other fibers &#8211; fiducial alignments fibers, etc.</p> <p>So all of PFS numbers fibers from 1 to 651, even though there are only ~600 science fibers per spectrograph.</p> <p>I think you mean <span class="error">&#91;-324, 324&#93;</span></p> <p>I thought that fibres start at 1. What did <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a> mean?</p> <p>I've set this back to "in review" — as suggested by @aritter above — until the above issues are resolved.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a> meant what he said, but 1) left out the 1-indexing and 2) got the numbers wrong. Yes, the fibers <em>should</em> be numbered from 1 to 651, and the science fibers span 2 to 650</p> <p>The file which <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=aritter" class="user-hover" rel="aritter">aritter</a> has is not correct, as it is still indexed w.r.t. the center being 0.</p> <p>I didn't check that the code is correct.</p> <p>Please look at the review comments and deal with as appropriate. Sometimes this means filling a ticket.</p> <p>Merged into master</p> Blocks PIPE2D-139 Relates PIPE2D-148 Development Rank 0|ii00v2:zi Reviewers rhl Sprint 2014-16 Story Points 1.0