radec2xy not considering airmass squashing term

[sbailey]

IIUC, the RA,dec -> x,y conversion happens in fiberassign::Hardware::radec2xy, which does not seem to have any knowledge of the potential airmass of the observation (although it can't know the hour-angle, given the latitude of the observatory and the dec of the tile it could know the minimum airmass if observed at HA=0).

This is similar to desimodel.focalplane.geometry.xy2radec which is also missing this term, with a dangling ticket desihub/desimodel#121 requesting adding that.

desimeter, however, does include these terms via the chain radec2tan -> tan2fp.

This missing term is partially mitigated by

• the 200 um buffer that fiberassign includes on its outer reach (R1+R2-200um), thus reducing the number of cases that could go from reachable to unreachable
• neighboring fibers have a similar offset and thus a small differential offset, thus reducing the number of cases that could go from non-colliding to colliding

But still, fiberassign should include this term. A new desimeter dependency (perhaps via desimodel -> desimeter dependency) might be the simplest route, with the complication that the fiberassign radec2xy calculation is happening on the C++ side so it may not be trivial to call back out to python. e.g. the transform might need to be done on the python side using desimeter before passing the xy into the C++ code along with the RA,dec of the targets...

@tskisner @schlegel @julienguy

[tskisner]

Just to summarize in the current code, radec <--> xy conversion:

fiberassign/src/hardware.cpp

Line 439 in dced43b

fiberassign::geom::dpair fba::Hardware::xy2radec(

fiberassign/src/hardware.cpp

Line 343 in dced43b

fiberassign::geom::dpair fba::Hardware::radec2xy(

Is indeed in the C++ code, but when converting between radial angle and arc length it uses the platescale from desimodel:

fiberassign/py/fiberassign/hardware.py

Line 82 in dced43b

# We are going to do a quadratic interpolation to the platescale on a fine grid,

Which is used for the equivalent of the desimodel get_radius_mm() function.

So fiberassign has an independent implementation of radec2xy (written in C++) which has been verified against the current equivalent function in desimodel. This function is used at several places in the compiled code. It sounds like we want to call an external function for that calculation. I'll need to ponder the least disruptive way to do this. There will definitely be a performance hit- it looks like the desimeter functions are working with a single coordinate at a time. In fiberassign, all targets are projected at once inside an OpenMP threaded loop. However, I guess that is just life.

[dstndstn]

Done in #348