At present we are targeting object which are partially vignetted and which thus lose S/N, so this work would allow us to make informed choices about when to target these objects (c. 5% of the PFI field). We might be able to work further into the spots (gaining back some of the 2%) if we trust blind cobra motions enough, but that's a higher-order objective.

My idea is to add an additional parameter to buildProblem (https://github.com/Subaru-PFS/ets_fiberalloc/blob/6f8f272370d03f56bca8fda7b1a11b54fde20cc8/ets_fiber_assigner/netflow.py#L220), which is a function that converts a distance to the nearest black spot center into a penalty. This would be analogous to the already existing cobraMoveCost| parameter. Observers can choose to pass None, in which case no penalty is applied, or a function that implements the desired penalty. I will then simply add the penalties for all visited targets to the overall "cost" of the observation.

This approach has the advantage of being extremely flexible, but of course also the drawback that all responsibility for the correct tuning of the function lies with the observers. On the other hand, I don't know who else would have all the required knowledge...

Does this sound OK?

Tentative implementation at https://github.com/Subaru-PFS/ets_fiberalloc/pull/16

Open question: so far we ignore the possibility that a fiber may be in close vicinity to a black dot of a neighbouring Cobra; we only check against its own black dot. Is that sufficient?

good catch Martin. Yes, the previously suggested parameter should certainly penalize observations close to any black dot.

I'm not sure if a fiber even can approach a neighbor's black dot so closely that we need to think about penalizing it.

Adding the feature is a bit tricky, and it may also increase run-time noticeably, so I'd be happy to get explicit confirmation that this is needed.

Looking at the fiber-allocation slack channel, it seems to me that the range where we should penalize assignments is between the actual black dot radius (somewhere around 0.75mm) and roughly 1.15mm. As far as I can see, neighoring fibers cannot come that close to a Cobra's own black dot, so this should not be necessary. Please correct me if I'm wrong.

Fair. It's probably worthwhile to make that calculation quickly. the focal plane object should expose all required information.

In regard to the possibility for given Cobra come close to the area of neighbouring dots, I quickly checked the numbers:

Measurement in September 2021 showed that distance between cobra and dot is 2.21+/- 0.25 mm ( dx(PFI) = - 0.27 +/- 0.26 mm, dy(PFI) = 2.17 +/- 0.30 mm) on average. (cf. designed value is 2.4mm in PFI-Y axis). If fibers are assigned in full patrol area, there may be a case a given Cobra reach to the neighbouring (in Y direction) dot area, I guess.

Thank you! I think I have an idea how to implement this somewhat efficiently, and hope to update the pull request in the next days.

This should be fixed now.

I made a stupid mistake in the implementation in the pfsDesign generation script, which was why it didn't work well before as reported. 

Now it looks that it works as we expected. The number of fibers assigned as a function of distance from dot center for various penalty cases is shown in the figure below. Currently, I'm using a form as a function of distance, but it can be changed according to the experience of future observations and experiment.

Here is another test with multiple priorities depending on brightness. I guess we can control the balance between dot effects and scientific priority by choosing the penalty function. I think the functionality has been implemented and tested, so we can close the ticket and file another one regarding on e.g. more scientific decision.

Thank you very much for testing, Kiyoto Yabe! Closing now.