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/INSTRM-1042 Instrument control development <p>At present, sky-to-pfi of CoordTransp.py is incomplete: it only covers transformation from field angle of input light of the WFC lens (X_in, Y_in). So process of (Ra, Dec) -&gt; (Az, El) -&gt; (X_in, Y_in) needs to be added. </p> <p>I'll use astropy module and prescription by Hohenkerk (1984) for atmospheric refraction.</p> INSTRM-1042

modify sky-to-pfi coordinate transformation to start with Ra-Dec

Task Normal Done Done yuki.moritani yuki.moritani Tue, 28 Jul 2020 10:23:26 +0000 Wed, 23 Sep 2020 09:25:59 +0000 Wed, 23 Sep 2020 09:25:59 +0000 pfs_utils 0 2 <p>I'm currently testing this in a very naive way (see testcoord.py), by specifying some center Ra, Dec and requesting the PFI coordinates for exactly the same Ra, Dec. Unless I'm overlooking some correction, this should result in returned coordinates of (0., 0.), correct?</p> <p>The unmodified code fails with:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Traceback (most recent call last): File "testcoord.py", line 15, in &lt;module&gt; testcoord() File "testcoord.py", line 10, in testcoord res = ctrans(np.array([[ra], [dec]]), 0., "sky_pfi", rotang, np.array([ra_c, dec_c])) File "/home/martin/codes/pfs_utils/python/pfs/utils/coordinates/CoordTransp.py", line 62, in CoordinateTransform xyin, inr, za1 = convert_in_position(xyin, za, inr, c, cent, time) File "/home/martin/codes/pfs_utils/python/pfs/utils/coordinates/CoordTransp.py", line 192, in convert_in_position za = za[0] IndexError: invalid index to scalar variable. </pre> </div></div> <p>It seems that line 192 is actually not necessary, so I commented it out.</p> <p>After this change the code runs and returns the coordinates  (0.10197685, -0.05085649), which is fairly close to zero. Is there some coordinate offset I'm missing, or is this compatible with zero within the expected accuracy of the transform?</p> <p>Another question: is it OK to leave the zenith angle parameter unset in this coordinate conversion mode? I think yes, because the code ovewrites it anyway. If so, I'd like to suggest giving it a default value of {{None }}and mention it in the docstring.</p> <p>The shape of <tt>xyin</tt> apparently needs to be{{ (2, N)}}, rather than {{(N,2). }}Not sure whether the code or the documentation should be adjusted.</p> <p>Performance seems to be roughly 30.000 coordinate transforms per second on my laptop, which might become a slight bottleneck for large source catalogs.</p> <p>The <tt>inr</tt> argument doesn't appear to have any influence on the returned values. I would have expected that varying{{ inr}} from 0 to 360 would produce PFI coordinates that describe a circle around (0,0). Am I making an incorrect assumption?</p> <ul> <li>As for za and offsets at (0, 0), I'll look into it. (Actually (0, 0) in the WFC model don't usually go PFI (0,0), but your number is larger than expected at zenith...)</li> <li>Shape of <tt>xyin</tt> should be  <tt>(2,N)</tt>, so I'll fix the document. I'm really sorry for confusion</li> <li>As for performance, to be honest, I don't have any idea about the requirement...</li> <li>For sky-to-pfi transformation, <tt>inr</tt> actually doesn't have any meaning, since (1) <tt>inr</tt> is calculated via astropy. As you expect, PFI coordinates rotates w.r.t <tt>inr</tt>, so you'll see stars rotate on PFI coordinates if you change the time... This made me realised that I didn't consider PA ... PA should be taken into account... correct? </li> </ul> <p><cite>(Actually (0, 0) in the WFC model don't usually go PFI (0,0), but your number is larger than expected at zenith...)</cite></p> <p>I don't think I'm pointing at the zenith, so the numbers may be fine!</p> <p><cite>This made me realised that I didn't consider PA ... PA should be taken into account... correct</cite>?</p> <p>Ahh ... thank you for pointing this out! I was looking for something PA-like, and `inr` seemed to be a good match, so I thought they were the same. Sorry for the confusion!</p> <p>Yes, I think we will need PA support.</p> <p>Concerning performance, I think we needn't worry about this at the moment. In any case I'll try to keep redundant calls to the absolute minimum.</p> <p>Sorry to come back to this, but I just realized that I will most likely need the `pfi_sky` direction as well. Without access to this functionality, I'd have to query a region larger than a square degree when looking for guide star candidates, which will result in very large query results and may be rejected by the DB servers.</p> <p>A rough approximation is currently sufficient for my purposes, so I can try to implement a first-order accurate solution as a workaround. But I'd still be happy of there was an official way to compute these transforms as well.</p> <p>Is the `pfi_sky` transformation direction currently planned, and if so, what are the (rough) time scales?</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=Martin.Reinecke" class="user-hover" rel="Martin.Reinecke">Martin Reinecke</a> would you mind discussing `pfi_sky` transformation in another ticket? If you agree, I'll file another.</p> <p>Oh absolutely! Sorry for mixing up various different issues here.</p> Development Rank 0|zzs2b4: Reviewers Martin.Reinecke