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-43 Target to fiber allocation and configuration <p>Prioritizing among calibration stars according to magnitudes, reliability of the photometric selection, uncertainty flags is helpful to collect high-quality calibration data. We would like to request netflow to have a capability of considering priorities among calibration stars in fiber assignment. </p> <p> </p> FIBERALLOC-43

consider priorities for calibration stars

Task Normal Done Done Martin Reinecke ishigaki EngRun Thu, 7 Apr 2022 09:39:43 +0000 Fri, 26 May 2023 13:51:58 +0000 Fri, 26 May 2023 13:17:35 +0000 ets_fiberalloc 0 5 <p>Hi Martin,</p> <p> </p> <p>lets hand calibration objects as science objects such that we can assign different non-observations costs to them as well. </p> <p> </p> <p>So directly in par with classes like</p> <p>sci_P1, sci_P2, sci_P3</p> <p>lets do</p> <p>cal_P1, cal_P2, cla_P3</p> <p>the difference of course still being, that the calibration object lives on a per exposure basis. It might well be reobserved in the next exposure.</p> <p> </p> <p>Please, let me know if you have no bandwidth for this right now.</p> <p> </p> <p>Max</p> <p> </p> <p>I will have a look later today. Since scientific and calibration targets are processed very differently in the assigner, this may not be as trivial as it seems.</p> <p>One problem that comes to mind is that for calibration targets we want to optimize the cost function <b>per exposure</b> and not over all exposures. It's no good to have a lot of very good calibration targets in exposure #1, at the cost of having pretty poor calibration targets in exposure #2, even if that produces the best quality on average.</p> <p>Maybe I'm overthinking this, but I don't really find a way around the limitation I mentioned above.</p> <p>So is it acceptable to simply optimize for the highst accumulated priority over all calibration targets and visits?</p> <p>What is "highest accumulated priority"?</p> <p>I thought we really give, a "nonobservationcost" and a "supply" for each class of calibrator?</p> <p> </p> <p> </p> <p>True, but the "nonobservationcost" only kicks in if we are not able to meet the supply (i.e. if we have to send some of the calibration targets to the overflow in order to use up the supply).</p> <p>If we can use up the supply by assigning calibration targets to fibers, no cost is incurred from the calibration targets that we don't observe.</p> <p>I might be able to break up an existing calibration target class into subclasses with different priority, then require that at least a given number of targets from all these subclasses must be observed for every exposure, and give some "observation bonus" depending on the priority of the subclass. But that still does not prevent the optimizer from oberving only "bad" calibration targets in the first exposure and only "good" ones in the second.</p> <p>I have pushed a propoal to <a href="https://github.com/Subaru-PFS/ets_fiberalloc/tree/tickets/FIBERALLOC-43" class="external-link" rel="nofollow">https://github.com/Subaru-PFS/ets_fiberalloc/tree/tickets/FIBERALLOC-43</a>, which adds an optional property called "penalty" to calibration targets. The fiber assigner will account for these penalties in the overall cost function and consequently prefer calibration targets with lower penalties.<br/> How large the penalties should be chosen unfortunately depends on other aspects of the cost function; I cannot really give a "one size fits all" recommendation here.</p> <p> </p> <p>A quick test of the penalty for calibration targets. It is a bit difficult to control the magnitude distribution by choosing the penalty function, but we can at least prioritize the bright calibrators by using the penalty.</p> <p><span class="image-wrap" style=""><a id="15600_thumb" href="https://pfspipe.ipmu.jp/jira/secure/attachment/15600/15600_FIBERALLOC-43_test1.png" title="FIBERALLOC-43_test1.png" file-preview-type="image" file-preview-id="15600" file-preview-title="FIBERALLOC-43_test1.png"><img src="https://pfspipe.ipmu.jp/jira/secure/thumbnail/15600/_thumb_15600.png" style="border: 0px solid black" /></a></span></p> <p>I think I confirmed that the implementation of the fiberalloc side worked during the last engineering run, so I think we can close this ticket now.</p> <p>Thank you! Closing this now.</p> <p>And I merged.</p> Development Rank 0|zzstj3: