Field rotation updates to avoid hexapod rotation limit errors

[araichoor]

This PR is in-development, but I share now, so that we can discuss choices I made.
Once perlmutter is back up, I ll run more sanity checks.

The goal of this PR is to avoid the hexpod rotation limit errors that happen in operations.
Details are presented on DocDB-8931.
In short, for a given tile:

• fiberassign computes FIELDROT = (RA, DEC, OBSDATE), the field rotation (using desimodel routines); so far, OBSDATE=2022-07-01, the "mid-survey" date which was defined years ago;
• then PlateMaker computes PM_REQ_FIELDROT, the proper field rotation, based on the exact date of observation and HA;
• the sent requested rotation for the hexapod is ROTOFFST = PM_REQ_FIELDROT - FIELDROT;
• if abs(ROTOFFST) > 600 arcsec, this triggers an hexapod rotation limit error, and we move to another tile.

The approach to solve that is twofold:
(1) change the OBSDATE (from 2022-07-01 to when_we_observe + 1 yr);
(2) apply a correction on the computed FIELDROT.
Based on DocDB-8931, those two actions should narrows the ROTOFFST distribution, keeping it within [-400 arcsec, +400 arcsec]; at least for the main survey observations.

Note that there is a subtlety that, during the observation, this rotation is updated every minute; though, hopefully, such additional rotation should be in total smaller than 30-60 arcsec for a 30min exposure, so the system should stay away from the 600 arcsec limit.

I ll discuss the implementation choices in a separate message.

[araichoor]

Tagging @schlafly @geordie666 @ashleyjross for the discussion.

First, if useful, I remind here the flow of function calling, in operations:

• fba_launch is called with some arguments, including TILERA, TILEDEC, HA, RUNDATE;
• then these arguments are propagated in the call to:
  • fiberassign.scripts.assign.parse_assign()
  • fiberassign.scripts.assign.run_assign_full()
• run_assign_full() calls run_assign_init() where the fiberassign.tiles.load_tiles() function is called, and where the field rotation is computed.

I ve chosen to tie by default the two actions to a given cutoff_rundate (dummy value for now):

fiberassign/py/fiberassign/data/cutoff-dates.yaml

Line 4 in 005eae3

obsdate: "2025-03-01T19:00:00+00:00" # obsdate set as rundate + 1yr

I ve chosen the rundate quantity to track when the tile is designed, as it avoids to bring in another variable (like nowtime), and should be close-ish to the design date for any tiles we will design (in case of perlmutter outages, it could be different by few days, but that s fine here).

The current approach is that, if a rundate is provided and later than the cutoff_rundate, then:

• OBSDATE is set to RUNDATE + 1 yr;
• if FIELDROT is not provided as an argument, a correction to the field rotation is computed and applied to the computedFIELDROT.

On top of modifications in parse_assign(), I ve added one argument --fieldrot_corr; by default, this argument is set to True if rundate >= cutoff_rundate and no --fieldrot argument is provided.

I ll have to validate/test when perlmutter is back up, but if everything works as it should be, no change would be needed to the fba_launch invocation in fba-main-onthefly.sh.

And backwards reproducibility should be preserved.
For the LSS ALTMTL runs, if I m correct, no change should be needed: the current processing is by calling fba_run for each tile, with providing arguments from the fiberassign header file, including FIELDROT and HA:
https://github.com/desihub/LSS/blob/4bb4692866ae9305ad2f9f940f1388a594e54baf/py/LSS/SV3/fatools.py#L250-L272.
https://github.com/desihub/LSS/blob/4bb4692866ae9305ad2f9f940f1388a594e54baf/py/LSS/SV3/fatools.py#L444-L467
So the chosen default settings should:

• pick the same OBSDATE as for operations;
• not apply any correction on FIELDROT (as the header FIELDROT value already had that correction computed+applied).

Happy to have feedback / suggestions / etc!

[araichoor]

for info:
with the help of @sbailey, I ve re-based from the main branch, pulling in the changes from #464.
now the tests pass, great!

in the very unlikely case that someone has checked out this hexrot branch and started to work on it between yesterday and now, just be careful of those changes.