Trimming target file using desimodel.footprint.find_points_in_tiles() for fiber assignment about desimodel

[sbailey]

For context, desimodel.footprint.find_points_in_tiles() uses desimodel.focalplane.get_tile_radius_deg() for the default radius. This returns the radius of the middle of the outermost positioner, but as you found here that means that there are some targets that are reachable by some positioners that aren't included. This choice was motivated by people doing coverage statistics and not wanting to include too many points that couldn't actually be observed.

I'd be fine with updating desimodel.focalplane.get_tile_radius_deg() to be the furthest radius that any positioner could reach and just accept that that will bring in a superset of targets that actually could be reached. I don't think we should try to update desimodel.footprint.find_points_in_tiles() to do the exact per-positioner coverage calculation which would be much much slower (ok if someone wants to contribute that as a separate function; I have ideas about how that could be done...)

Any strong opinions either way from anyone about whether the tile "radius" should be referring to the maximum possible radius, or the typical radius?

This shows the radius of furthest reach of the positioners along the outer edge of the tile, along with the radius equivalent to what is currently considered to be the tile radius.

[kdawson1000]

I vote that it is updated to be the maximum possible radius to ensure that all targets will lie within reach of a positioner. I agree that this does not need to do the exact per-positioner coverage.

[Srheft]

Would be nice to show the tile perimiter in tile plots of the fiber assignment (a fine dashed-line circle superposed on the plots just so that we know if an "edge fiber" is left unassigned, it's not for any reason other than insufficient target density or fiber collision).

And, @sbailey: Agreed. clearly desimodel.focalplane.get_tile_radius_deg() controls the find_points_in_tiles() output so this is more of a "tile radius definition" issue than the find_points_in_tiles() issue. This ticket just shows how we reached to the conclusion about [possibly] changing the tile radius definition.

[tskisner]

Another note: In fiber assignment, the tile radius (which is used in the tree lookup to find available targets for each tile) is currently hard-coded to 1.65 degrees. This and all of the hardware properties will be reviewed after the merge when updating the positioner geometry, etc. That would be a good time to get this value from some other place like desimodel.

[tskisner]

For reference: https://github.com/desihub/fiberassign/blob/tsk_refactor/src/hardware.cpp#L94

[Srheft]

@tskisner

In fiber assignment, the tile radius (which is used in the tree lookup to find available targets for each tile) is currently hard-coded to 1.65 degrees.

The source of difference between hard-coded tile radius in hardware and what I see below is not clear to me:

import desimodel.focalplane
desimodel.focalplane.get_tile_radius_deg()
1.6057735024174122

[sbailey]

default tile radius updated in PR #102; closing this ticket.