I will try to add this capability, but to start I'll need a quantification of what "uniform" means, such that we can formulate it as additional constraints to the netflow optimizer.

As far as I recall, there was also the additional constraint that calibration targets are uniformly distributed along the slits of the spectrographs. For this, we also need a clear specification what this means.

Dear Martin, dear all, yes we should be able to model this in the netflow framework.

I would propose that the the decouple the implementation side (how do we do this in netflow) from the actual practical side (which parts of the focal plane should be covered how and what are the specific fiber to spectrograph&slit mappings).

The simple thing to do is to subdivide the calibrators (=sky) according to whether they fall into a particular subregion of the focal plane. This really would just subdivide the calibrator target call into subclasses, directly equivalent to the different priority classes for galaxies. This is really easy way to solve the problem to good approximation, but it is not precise because calibrators may be reachable by multiple cobras, which belong to different spectrographs even.

BUT I think we can actually solve it precisely:

For this we would define a generic set of groups of cobras. The list of groups should be dynamic and we should be reading it from an ascii file. My gut feeling is that we will probably have more than 10 and less than 50 such groups. Also we should define a minimum required number of calibrators per group (=N, this might be the same number for all groups but really we can just as easily have one number per group in the same ascii file.

netflow should now enforce that there is at least a than minimum number of calibrators allocated per group by adding the term

(N - input_flow) x LARGE_COST to the cost function for each group. Input_flow is the sum over all calibrator flows into a group node. Now for this to work we need to distinguish between galaxy-flow and calibrator flow which is a bit of a rewrite of netflow but well possible.  

Finally for each cobra group node we need to limit the input flow to N by adding another constraint equation:

input_flow <= N

This will be generic and allow us to distribute cobras across fibers/spectrographs/slits in whatever-way we like.

All the information for the spatial uniformity of the calibs is already present, so the input would be the definition of the regions which define the groups. The mapping of cobras to positions along the slits is present in the FiberId object in fps_utils, so that's also known to Netflow (at least in theory). I believe that pfs_utils brings in few or no extra dependencies, but that should be checked.

Perfect, this should make the start easy then. I added a sketch of the proposed solution here

skyfiber-dist.pdf

^{and can walk through it tomorrow if useful.}

I have been thinking about this some more, and I think we can perhaps formulate this without adding more flow variables:

when building the problem, we are adding the "Tv_Cv" flows to the system, and for every one of these flows we know if it comes from a sky calib target and we can also determine to which "location group" the corresponding Cobra belongs. So, let's assume we are adding a flow going from a sky calib target to, say, a Cobra in location group 5: can't we just add this flow to a new constraint for location group 5 and require that the sum of this constraint is >= some user-defined limit?

(If we don't want a hard limit but rather penalize not reaching the required number, we can add an "overflow source" with a high cost, right?)

Does this make sense? A first sketch is on branch "tickets/FIBERALLOC-42".

Sorry, my proposal wasn't complete. We will need one additional constraint per location group per exposure. I haven't taken this into account yet, but this should not make the implementation harder.

I have now added overflow arcs, and I believe that the code now does (in principle) what it s supposed to do.

We still need to discuss how to pass the required additional information to the assigner. As far as I see, we need

• the mapping from Cobra index to region index (integer array)
• the minimum number of sky targets per region
• the penalty cost for every necessary sky fiber that we didn't manage to allocate

Adding something analogous for spectrograph slit regions should be straightforward once we have nailed down the solution for the focal plane regions.

I think that the mapping from Cobra index to region index (integer array) can come from the Grand Fibre Map which is available from pfs_utils. Is that a dependency for you?

The assigner already depends on `pfs.utils`, so this won't cause any additional dependencies. The contents of the Grand Fibre Map look extremely useful for someone defining the regions, but I think someone still needs to decide how many regions to use and which Cobras actually fall into them.

That is to say, someone still has to build this integer array and pass it to the assigner ... or is your suggestion to use a single, hard-wired one?

Do you think that my general approach makes sense, or do you see any complication I missed? I'm still a bit worried because Max thought we have to (almost) double the number of flow variables, and I seem to manage with just adding {{nvisit*nregion }}extra constraints ...

I pushed a few fixes and added a very basic "demo_netflow_regions.py" script.

OK, this seems to work just beautifully.  Please see the attached slides. I also added my modifications to the demo script. 

From my point of view we should discuss merging this to master in the next meeting and also modify commissioning.py to include this.

20220124_region_based_fiberallocation.pdf

Thank you for the extensive testing!

As we discussed, there is now analogous functionality for distributing sky targets evenly along the spectrograph slits as well.

Tested, again works beautifully, slides and test code attached.

Added analysis code to 

./misc/test_codes/demo_netflow_regions_with_analysis.py 

 20220127_region_based_fiberallocation.pdf

Unless there are objections, I propose to merge and close this at the end of the week.

I agree entirely!   

Merged!

I deleted `requirements.txt` from master for the time being, since it pulls in more packages than strictly needed for the assigner.

This has the status "review complete", but at the same the resolution is "unresolved", which is a bit confuing.
I think the issue can be closed, but I don't have a button in my Jira interface to do it.

I just realised that your account was created Jira internally, not via LDAP... so I need to look into it.

I'm sorry, I just realised how it can be done: I just set the workflow to "Done", but don't select any reviewers. That seems to do the trick!