[FIBERALLOC-43] consider priorities for calibration stars Created: 07/Apr/22  Updated: 26/May/23  Resolved: 26/May/23

Status: Done
Project: Target to fiber allocation and configuration
Component/s: ets_fiberalloc
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: ishigaki Assignee: Martin Reinecke
Resolution: Done Votes: 0
Labels: EngRun
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File FIBERALLOC-43_test1.png    

 Description   

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. 

 



 Comments   
Comment by mxhf [ 07/Apr/22 ]

Hi Martin,

 

lets hand calibration objects as science objects such that we can assign different non-observations costs to them as well. 

 

So directly in par with classes like

sci_P1, sci_P2, sci_P3

lets do

cal_P1, cal_P2, cla_P3

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.

 

Please, let me know if you have no bandwidth for this right now.

 

Max

 

Comment by Martin Reinecke [ 07/Apr/22 ]

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.

One problem that comes to mind is that for calibration targets we want to optimize the cost function per exposure 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.

Comment by Martin Reinecke [ 07/Apr/22 ]

Maybe I'm overthinking this, but I don't really find a way around the limitation I mentioned above.

So is it acceptable to simply optimize for the highst accumulated priority over all calibration targets and visits?

Comment by mxhf [ 07/Apr/22 ]

What is "highest accumulated priority"?

I thought we really give, a "nonobservationcost" and a "supply" for each class of calibrator?

 

 

Comment by Martin Reinecke [ 08/Apr/22 ]

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).

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.

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.

Comment by Martin Reinecke [ 25/Apr/22 ]

I have pushed a propoal to https://github.com/Subaru-PFS/ets_fiberalloc/tree/tickets/FIBERALLOC-43, 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.
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.

 

Comment by Kiyoto Yabe [ 31/Mar/23 ]

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.

Comment by Kiyoto Yabe [ 26/May/23 ]

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.

Comment by Martin Reinecke [ 26/May/23 ]

Thank you! Closing this now.

Comment by Kiyoto Yabe [ 26/May/23 ]

And I merged.

Generated at Sat Feb 10 16:53:17 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.