Add ability for tile priority overrides

[sbailey]

Add options to afternoon planning to allow overriding tile priorities, either high or low. This could be used by the survey coordinator to prioritize fields to fill in gaps in the coverage, or to repeat calibration fields each year.

This could be as simple as afternoon planning not updating priorities for tiles with priority 0-2 or 8-10, while shuffling priorities in the 3-7 range.

[dkirkby]

Flexible tile priorities are now implemented via a set of rules in a YAML file. These can either be left untouched (e.g., when running surveysims) or else adjusted any afternoon by the survey coordinator.

[sbailey]

[apologies for commenting in one issue (#18) on a topic that I should have commented here...]

For BOSS we found it helpful to have a set of priorities that the survey coordinator could adjust that the automated algorithm would not override, on a tile-by-tile basis. e.g. to force a problematic tile to priority=0 and know it would be left there, or move a special tile to top priority until it was observed, even if the automated algorithm would have ranked it differently.

In the current scheme, the survey coordinator can update the global rules in the YAML file, but can that easily be done for individual tiles? They can also override it for an individual tile for an individual night via editing the plan.fits file, but that would get reset the following night, correct?

i.e. is there some easy way to set "sticky" priorities (low or high) on a per-tile basis?

[dkirkby]

I think the cleanest implementation is to extend the YAML syntax to support, e.g.

# Specify TILEID: PRIORITY pairs that override all other rules.
overrides:
  123: 0.0
  456: 99.9

I prefer this over a new mechanism since it simplifies record keeping (taking a snapshot of the rules each afternoon is sufficient to fully document how each night's priorities were set) and program logic (small perturbation to existing code and unit tests).

I guess tiles with an override directive should be removed from the group they would otherwise belong to, for the purposes of determining whether that group is "done"?

Note that the rules syntax already allows a group of tiles to forced to some priority. For example, adding the following to the top of the rules does what you would expect:

kill-sgc-pass0:
  cap: S
  passes: 0
  rules:
    kill-sgc-pass0(0): { START: 0 }

[schlafly]

The tiles file includes a priority boost factor that is only changed by humans. That's enough to address anything we might want to do with it. We have not built much plumbing around it to make it easy to set priorities. If we end up setting a lot of special priorities, I'll put together such code. Closing this in the meantime as the base functionality exists.