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-751 DRP 2-D Pipeline <p>The need to loop over <tt>y</tt> in python calling <tt>DetectorMap.getWavelength(fid, y)</tt> is a significant slow-down in SuNSS analysis. Please provide a version that accepts a numpy array as the second argument.</p> PIPE2D-751

Please add a vectorised version of DetectorMap.getWavelength(fid, y)

Story Normal Won't Fix Won't Fix price rhl SuNSS Wed, 3 Mar 2021 02:18:49 +0000 Mon, 5 Apr 2021 21:19:10 +0000 Mon, 5 Apr 2021 21:19:10 +0000 0 3 <p>The lack of this function is for example significantly slows the analysis of OH <tt>arcLines</tt> files from SuNSS.</p> <p>This function exists, but is named <a href="https://github.com/Subaru-PFS/drp_stella/blob/master/include/pfs/drp/stella/DetectorMap.h#L108-L121" class="external-link" rel="nofollow"><tt>findWavelength</tt></a>, probably for historical reasons. So I'll take this as a request to clean up the interface in regard to <tt>get&#42;</tt> vs <tt>find&#42;</tt>. I propose:<br/> 1. Move <tt>findWavelength</tt> to <tt>getWavelength</tt>.<br/> 2. Move <tt>findPoint</tt> to <tt>getPoint</tt>.<br/> 3. Move <tt>findFiberId</tt> to <tt>getFiberId</tt>.</p> <p>I'm a little concerned that <tt>get*</tt> implies a fast return without much in the way of calculation, which is not the case for any of these, but it's certainly the name we look for first, so perhaps convenience trumps that?</p> <p>Oh, good. I think the name's OK; the user doesn't know that we don't have these things pre-computed to logically it's just a `get`</p> <p>I don't see the corresponding vectorised function to return the fibre position (in x) at a set of wavelengths for a given fibre. This could be done by adding a vector overload to <tt>findPoint</tt> (returning a 2xn array), or a new function (<tt>getTracePosition</tt>?)</p> <p>There is <a href="https://github.com/Subaru-PFS/drp_stella/blob/master/python/pfs/drp/stella/DetectorMap.cc#L44-L47" class="external-link" rel="nofollow">a vectorised version of <tt>findPoint</tt></a> already. If it's not working for you, check that your types are correct (<tt>fiberId</tt> arrays should be <tt>int32</tt>, wavelength arrays should be <tt>float64</tt>) and the arrays are contiguous.</p> <p>Oh, that's great. I did look at the .h file, but didn't realise that you can vectorise over both <tt>fiberId, lambda</tt> which is exactly what I needed.</p> <p>OK, so what's the verdict on what work needs to be done?</p> <p>It sounds as if we should have a chat about a consistent API, but that all the needed functionality is present</p> <p>Can this ticket be closed, and a separate ticket on the API update filed?</p> <p>Problem is due to confusion over API. This is the subject of a separate ticket.</p> Relates PIPE2D-805 Development Rank 0|02qpt6:508yl0chzzy00000yy Sprint 2DDRP-2021 A3 2DDRP-2021 A 4