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/FIBERALLOC-34 Target to fiber allocation and configuration <p>Currently opDB has no table for the output from `ets_shuffle`, so come up with a mechanism in opDB to store the information of the selected guide/acquisition stars in each camera.</p> <p>Currently, the output of the shuffle processing is like this but we may have more information:<br/> Identified target IDs for each camera: AG camera #0 <span class="error">&#91;2493596405047282176 2493597813796555648&#93;</span> AG camera #1 <span class="error">&#91;2492943913615230592 2492943913615227776 2492991020816540672&#93;</span> AG camera #2 <span class="error">&#91;2492877221363219712&#93;</span> AG camera #3 <span class="error">&#91;2493142272384857344 2493142448479083136 2493142169305639680 2493142585918005120&#93;</span> AG camera #4 <span class="error">&#91;2494051431062162944 2494051057400740608 2494047999384032512 2494050988681269248 2494051362342685056 2494050984385562752&#93;</span> AG camera #5 [2493685637288060288 2493685469784142336 2493685469784142592<br/> 2493690177068271488 2493690172773592832]<br/>  </p> FIBERALLOC-34

Design a mechanism to store the output from shuffle in opDB

Task Normal Done Done Kiyoto Yabe Kiyoto Yabe opDB Thu, 1 Oct 2020 08:34:49 +0000 Mon, 4 Oct 2021 02:40:28 +0000 Mon, 4 Oct 2021 02:40:28 +0000 ets_shuffle 0 2 <p>I'm still thinking about two possibilities regarding where we store the output from `shuffle`, and it's a bit difficult to explain in this comment, but...</p> <p> </p> <p><b>option 1</b>. we make `pfs_design_agc` for (guide and acquisition) objects in AG camera like `pfs_design_fiber` for science objects in fibers.</p> <p>----------------------</p> <p><b>pfs_design_agc</b></p> <p>----------------------</p> <p>pfs_design_id (FK; not null)  ---&gt; referring to `pfs_design`</p> <p>agc_camera_id (not null)</p> <p>guide_star_id (not null)  ---&gt; Gaia ID?</p> <p>agc_target_x_mm</p> <p>agc_target_y_mm</p> <p>...</p> <p>----------------------</p> <p>In this design, I'm assuming both `ets_shuffle` and `ets_fiberalloc` run integrally and save all information to `pfs_design`, `pfs_design_agc` &amp; `pfs_design_fiber` in the end of the process.</p> <p> </p> <p> <b>option 2</b>. we make `shuffle` and `shuffle_agc`</p> <p>----------------------</p> <p><b>tile</b></p> <p>----------------------</p> <p>tile_id (serial not null; auto-incremented)</p> <p>program_id (FK)</p> <p>ra_center_initial</p> <p>dec_center_initial</p> <p>pa_initial</p> <p>...</p> <p>----------------------</p> <p> </p> <p>----------------------</p> <p><b>shuffle</b></p> <p>----------------------</p> <p>shuffle_id (serial not null; auto-incremented)</p> <p>tile_id (FK)  ---&gt; referring to `tile`</p> <p>ra_center_designed_shuffle</p> <p>dec_center_designed_shuffle</p> <p>pa_designed_shuffle</p> <p>...</p> <p>----------------------</p> <p> </p> <p>----------------------</p> <p><b>shuffle_agc</b></p> <p>----------------------</p> <p>shuffle_id (FK; not null)  ---&gt; referring to `shuffle`</p> <p>agc_camera_id (not null)</p> <p>guide_star_id (not null)  ---&gt; Gaia ID?</p> <p>agc_target_x_mm</p> <p>agc_target_y_mm</p> <p>...</p> <p> ----------------------</p> <p> </p> <p>----------------------</p> <p><b>pfs_design</b></p> <p>----------------------</p> <p>pfs_design_id (not null)</p> <p>shuffle_id (FK; not null)  ---&gt; referring `shuffle`</p> <p>ra_center_designed</p> <p>dec_center_designed</p> <p>...</p> <p>----------------------</p> <p> </p> <p>In this design, we need to run `ets_shuffle` first and decide the pointing center and save info to the database, and then we run `ets_fiberalloc` based on the decided pointing center. I do not think about how to deal with multiple visits using netflow mechanism yet.</p> <p> </p> <p> </p> <p>I think the current agreement is that "shuffle" will not actually do any shuffling; it will simply output suitable acquisition/guide star candidates for the provided telescope pointing and orientation. If this is correct, then your option 1 feels more natural to me.</p> <p>One open question from my side: are "agc_target_<span class="error">&#91;xy&#93;</span>_mm" given in PFI coordinates or in a coordinate system specific to every AG camera? If the latter, I'd need a way to transform from PFI to these coordinates (I don't think this is integrated in pfs_utils yet).</p> <p> </p> <p>Thank you for your comments. I'll push option 1 forward taking into consideration other discussion points. For the open question, I think we should coordinate with the AG camera table (e.g., `agc_data`). I guess currently they are coordinates on AG image in pix, so agc_target_<span class="error">&#91;xy&#93;</span>_pix would be probably what we need.</p> <p>I found this was still floating, but now it's a time to fix.</p> <p>Here is a new proposal based on the current datamodel GUIDESTARS HDU in pfsDesign file.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hiro" class="user-hover" rel="hiro">Yoshida, Hiroshige</a>?</p> <p>----------------------</p> <p><b>pfs_design_agc</b></p> <p>----------------------</p> <p>pfs_design_id (FK; not null)  ---&gt; referring to `pfs_design`</p> <p>guide_star_id (not null)  ---&gt; joinable with GaiaDB</p> <p>epoch</p> <p>guide_star_ra</p> <p>guide_star_dec</p> <p>guide_star_pm_ra</p> <p>guide_star_pm_dec</p> <p>guide_star_parallax</p> <p>guide_star_magnitude</p> <p>passband</p> <p>guide_star_color</p> <p>agc_camera_id</p> <p>agc_target_x_pix</p> <p>agc_target_y_pix</p> <p>comments</p> <p>----------------------</p> <p>I'll implement the design above for now and close this ticket. We file a new ticket if we need a further fix.</p> Development Rank 0|zzs2ts: