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-907 DRP 2-D Pipeline <p>If black spots are not perfect at hiding fibers and/or allow even a little light, then fiber profiles measured independently will be contaminated. <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a> advocates measuring simultaneously in order to remove the contamination.</p> PIPE2D-907

Solve profiles for multiple fibers simultaneously

Story Normal Done Done price price Tue, 28 Sep 2021 18:41:40 +0000 Thu, 27 Apr 2023 18:30:46 +0000 Thu, 27 Apr 2023 18:30:46 +0000 0 3 <p>We're going to assume for starters that the black spots are grey (constant attenuation as a function of wavelength). We can't assume that the attenuation is identical for all fibers.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a> has suggested that solving for the profiles might be done by matrix inversion. But it seems to me that the model is non-linear in the parameters, as we're fitting:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> flux(image, x, y) = A_{image, fiber} . B_{fiber, x, y} </pre> </div></div> <p>where <tt>A</tt> is the normalisation for a particular fiber on a particular image, and <tt>B</tt> is the fiber profile.</p> <p>If we were to fit <tt>log(flux)</tt> the equation would be linear, but then it's not linear in flux and Bad Things would surely happen.</p> <p>One thing to think about is measuring a guess for <tt>A</tt> directly from the data (e.g., starting with a narrow boxcar extraction) and solving for <tt>B</tt>. Then we could iterate a few times in an attempt to atone for errors in our starting assumption.</p> <p>I've come fairly close to getting this working well, but I've hit a roadblock when fitting profiles in the integration test: the matrix solution is taking a crazy long time with the default solver, and other solvers either fail or segfault. But the matrices are fine when I run them through the Eigen sparse matrix benchmark program. I'm hoping that a more recent version of Eigen will deal with whatever is causing this, so will put this back on the stack until after <a href="https://pfspipe.ipmu.jp/jira/browse/PIPE2D-598" title="Upgrade base LSST stack to latest version" class="issue-link" data-issue-key="PIPE2D-598"><del>PIPE2D-598</del></a>, and deal with more pressing issues.</p> <p>Hmm. Are you sure that there's not a memory problems somewhere?</p> <p>Thanks for the idea. I found a memory problem in my code, but fixing that didn't help the segfaults and such in the matrix solver.</p> <p>You shouldn't be able to get segfaults from a bad matrix, especially if it solves stand-alone.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=price" class="user-hover" rel="price">price</a> Where do we stand on merging this ?</p> <p>Merged a couple of weeks ago.</p> Development Rank 0|02qph7:07a Sprint 2DDRP-2021 A 10 2DDRP-2021 A11 2DDRP-2022 A 2DDRP-2023 A Story Points 5.0