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-1072 Instrument control development <p>It was discussed a while ago whether `pfi-sky` transformation is needed or not. This transformation is thought to be needed to look for guide stars by projecting PFI-AG regions on the sky.   At that time, we thought it will work querying slightly wider region than AGs and picking the stars which will be on the AG.</p> <p>Recently, however, Martin found that `pfi-sky` transformation is still needed after some development work. The below is a comment from <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=Martin.Reinecke" class="user-hover" rel="Martin.Reinecke">Martin Reinecke</a> in <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-1042" title="modify sky-to-pfi coordinate transformation to start with Ra-Dec" class="issue-link" data-issue-key="INSTRM-1042"><del>INSTRM-1042</del></a></p> <blockquote><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></blockquote> INSTRM-1072

Implement pfs-sky transformation?

Task Normal Done Done yuki.moritani yuki.moritani Wed, 9 Sep 2020 10:08:37 +0000 Fri, 16 Apr 2021 14:10:37 +0000 Fri, 16 Apr 2021 14:10:37 +0000 pfs_utils 0 3 <p>As I said, there are most likely viable workarounds for the guide-star selection scenario, so the `pfi_sky` for this single purpose may not be necessary.<br/> However, there are other situations where it is needed, e.g. when producing finder charts where the focal plane geometry is plotted over a sky image downloaded from SDSS or another service. I'm not sure whether this kind of feature is essential, but if it is wanted, I do not see a way around the `pfi_sky` transformation.</p> <p>If I remember correctly, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=jeg" class="user-hover" rel="jeg">jeg</a> also mentioned during a PFS telecon that he considers this transformation direction necessary, but unfortunately I don't recall how he intended to use it.</p> <p>We exchanged some conversations. Suppose that transformation doesn't need to be so accurate (order of 10–100um on PFI difference is OK), this direction is to be added for axisymmetric distortion.</p> <p>Sorry for the late reply!</p> <p>Yes, an accuracy of 10-100um is perfectly fine for my purposes. If it is possible, it would be great to know an upper bound for the error, but if this is hard to estimate, I'll just use 1mm to be on the safe side.</p> <p> </p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=Martin.Reinecke" class="user-hover" rel="Martin.Reinecke">Martin Reinecke</a> I update the code with pfi-sky transformation and pushed it to dedicated branch. I looked into how much the error is by executing pfi to sky transformation, and then  sky to pfi transformation. The difference in pfi position between before and after transformation is &lt;~300um. Error in elevation is dominant, since I didn't implement correction of atmospheric dispersion for pfi-sky.</p> <p>Thank you!</p> <p>For my purposes (i.e. defining a relatively tight boundary around the AG cameras to avoid large query results) this error margin is absolutely fine.</p> <p> </p> <p>Oh, absolutely! Sorry if I messed things up.</p> <p>Actually I'm not sure whose respobsibility it is to finally close the issue, and I just wanted to show clearly that I'm happy with the resolution, so I became a bit over-enthusiastic <img class="emoticon" src="https://pfspipe.ipmu.jp/jira/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>You are absolutely right that this can not be closed before the merge has actually happened.</p> <p>Hi <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=Martin.Reinecke" class="user-hover" rel="Martin.Reinecke">Martin Reinecke</a> no need to apologize - your intentions were pure, read below:</p> <p>Yes it's true that it is for the appropriate management body to close the issue (in this case, <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=yuki.moritani" class="user-hover" rel="yuki.moritani">yuki.moritani</a>) and as you say, only after the merge has taken place. </p> <p>But I believe your intention is to simply mark the ticket as being approved by you as the reviewer, which you are correct in assuming that is what a reviewer should be doing. </p> <p>To do this, simply select 'Workflow'-&gt;'Review Complete'. </p> <p>Do you mind doing that please?</p> <p>Set to 'Review Complete' on behalf of <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=Martin.Reinecke" class="user-hover" rel="Martin.Reinecke">Martin Reinecke</a>.</p> <p>Merged to master in Dec 2020 (<a href="https://github.com/Subaru-PFS/pfs_utils/commit/48b5502a527f686d014c790a061367bbb46cc682" class="external-link" rel="nofollow">https://github.com/Subaru-PFS/pfs_utils/commit/48b5502a527f686d014c790a061367bbb46cc682</a>)</p> Development Rank 0|zzs2o8: