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-343 DRP 2-D Pipeline <p>Define a class for the 2D PSF. </p> <p>This could be an extension of the LSST <tt>Psf</tt> class, but that is to be determined. </p> PIPE2D-343

Define {{Psf}} class

Story Normal Done Done price hassan Thu, 7 Feb 2019 21:17:23 +0000 Fri, 20 Dec 2019 00:16:36 +0000 Fri, 13 Dec 2019 20:43:46 +0000 6.0 0 5 <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hassan" class="user-hover" rel="hassan">hassan</a>: I've defined a <tt>SpectralPsf</tt> base class, with an <tt>ImagePsf</tt> specialisation that should allow us to wrap a <tt>PsfexPsf</tt> from LSST. Is this sufficient definition?</p> <p>I expected this to inherit from the LSST class (but would check with <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=jbosch" class="user-hover" rel="jbosch">jbosch</a> first).  I am very suspicious of an API that fundamentally works in terms of <tt>(fibreId,</tt> lambda) as we <b>measure</b> things in terms of <tt>(x,</tt> y);  I can see adding an API that takes a <tt>DetectorMap</tt> as a convenience.</p> <p>Why do we have our own separate class hierarchy?</p> <p>I don't think I know enough to comment usefully on most of this, but if you do need to define a new PSF API instead of using LSST's, I'd strongly recommend <b>not</b> defining an API that includes spatial variation <em>in C+++</em> if you can avoid it (in other words if you can always evaluate the PSF at a point in Python, yielding an image or some kind of local PSF class to pass to C&#43;&#43;, <em>do</em>).  That will make it a lot easier to write what is probably not performance-critical code in Python instead of C&#43;&#43;.  It's also something LSST may have to do someday, as disruptive as it might be, in order to use Piff (it's not the only solution to that problem, but it's definitely on the table).</p> <p>The fundamental requirement is that the <tt>SpectralPsf</tt> works in terms of <tt>(fiberId, lambda</tt>) (that's all we really care about when we come to subtract sky lines), so the interface is defined in terms of that. Note that there is a specialisation that composes an LSST <tt>Psf</tt>, which sweeps all the <tt>(x, y)</tt> details under the rug so the user doesn't need to worry about them.</p> <p>I could re-write in python, but I think this approach (composition instead of inheritance) is the Right Way as it hides the <tt>(x, y)</tt> details from the user.</p> <p>I want this PSF to work in detector coordinates, please.  That's where it defined and measured.  I understand that we will often use it in <tt>(fibreId, lambda)</tt> but that mapping is derived; we need to make it convenient, but I don't want it to be primary. For example, if we change the order of the wavelength fit it doesn't change the PSF.</p> <p>I've updated the code to work in detector coordinates, and put the implementation in python as was suggested.</p> <p>It's not yet clear whether we need this implementation to be in C++ or not. We need <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=ncaplar" class="user-hover" rel="ncaplar">ncaplar</a> to explain how his PSF code works so we know how difficult it will be do implement in C++.</p> <p>I am not sure that I fully understand the question.</p> <p>The code that generates the oversampled images is quite complex and I doubt that it can be moved outside Python without considerable effort, especially at this stage.</p> <p>What I do at the moment is to supply a big array, which contains samples of PSF on many positions of the detector. From this, one can interpolate PSF at any position of the detector. Initial function is in <a href="https://pfspipe.ipmu.jp/jira/browse/PIPE2D-347" title="Provide a method that provides a PSF for a given fiber and wavelength" class="issue-link" data-issue-key="PIPE2D-347"><del>PIPE2D-347</del></a>.</p> <p>I doubt this an answer to the question you are looking for, but I am not sure I can provide better one without further clarifications.</p> <p> </p> <p>No, that's really useful, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=ncaplar" class="user-hover" rel="ncaplar">ncaplar</a>. It looks like you've done all the difficult work outside the function you're providing, which just finds the two closest arrays and does a linear interpolation. That's something we can easily do in C++, I think.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a>, shall I push this down to C++? And I may as well integrate Neven's code while I'm at it.</p> <p>I have pushed the PSFs down to C++ and implemented the <tt>NevenPsf</tt>, based on the PSF realisations and interpolation algorithm provided by <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=ncaplar" class="user-hover" rel="ncaplar">ncaplar</a>. It sounds like Neven wants to update the realisations slightly, which we may as well do as part of this ticket, but I think this is ready for a new review. <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a> and <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hassan" class="user-hover" rel="hassan">hassan</a>, please have a look!</p> <p>Just to clarify, I will update the arrays that I provide in <a href="https://pfspipe.ipmu.jp/jira/browse/PIPE2D-450" title="Create array_of_arrays that contains 2d PSF model inputs" class="issue-link" data-issue-key="PIPE2D-450"><del>PIPE2D-450</del></a>. I propose to create 211x211 images where position of chief ray is in the center pixel (instead of current 210x210 version).</p> <p>I believe this is ready to merge. It's already being used for the work in <a href="https://pfspipe.ipmu.jp/jira/browse/PIPE2D-326" title="Implement arc subtraction algorithm in 2D" class="issue-link" data-issue-key="PIPE2D-326"><del>PIPE2D-326</del></a>, so we should get this into master. I propose to merge tomorrow if there are no objections.</p> <p>Merged to master.</p> Blocks PIPE2D-348 PIPE2D-326 Relates PIPE2D-342 DAMD-9 Development Epic Link PIPE2D-351 Rank 0|02qpt6:508yl0chzzy0000p922 Reviewers hassan Sprint 2DDRP-2019 C 2DDRP-2019 D 2DDRP-2019 E 2DDRP-2019 F 2DDRP-2019 G 2DDRP-2019 H 2DDRP-2019 I 2DDRP-2019 J 2DDRP-2019 K Story Points 2.0