Resolve details of design and responsibility for 5-point pointing calibrations

AA0.5 will require the implementation of "5-point" calibration observations, taking data that the SDP will process to determine and publish local pointing corrections and all-sky pointing models.

In ADR-59 it was decided that these observations would be formed from five individual scans (and not a single scan with "sub-scans" at the different points). 

The implementation of a "5-point" will therefore involve configuring a "normal" scan at a celestial, RA/Dec, position, executing that scan, and then re-configuring only the tracking target position of the dishes (this is a MID observing type), whilst leaving the other subsystems with the same configuration.

The  target re-configuration is achieved by an offset in Alt/Az coordinates from the RA/Dec central position. Normally the same offset (in arcsec) is applied in each of the 4 cardinal directions.

Approximately the sequence of events for a 5-point, offsetting by N arcsecs, will be:

1. Send a full configuration to all subsystems, this will set the dishes tracking the central RA/Dec position, configure the CSP and ready the SDP to process a 5-point;
2. Execute a scan;
3. Send an offset re-configuration to the  dishes of -N, 0 in Alt/Az, setting them to track this new position;
4. Execute a scan;
5. Send an offset re-configuration to the  dishes of +N, 0 in Alt/Az, setting them to track this new position;
6. Execute a scan;
7. Send an offset re-configuration to the  dishes of 0, -N in Alt/Az, setting them to track this new position;
8. Execute a scan;
9. Send an offset re-configuration to the  dishes of 0, +N in Alt/Az, setting them to track this new position;
10. Execute a scan.

Note the sequence of pointings around the central position might be different from the example above.

The purpose of this spike is to determine the best way to handle this scenario, in particular:

1. What does the OSO-scripting layer look like?
   • We think we understand how the user will specify this - as an central RA/Dec position plus an offset.
2. For the offset positions is it correct that only a dish (re-)configuration is sent?
3. Is it possible to send a partial dish re-configuration, containing only the new position request?
   • In other words no change to receiver band
4. From the very top level (user) the re-configuration will be specified as an offset (probably in arcsec). How is this handled through the system (i.e. is an offset position sent to TMC Subarray Node? To each Dish Leaf Node? to Dish LMC?
   • Note the offset should be in Alt/Az coordinates, so this might suggest it is applied at the same place as the Alt/Az for the central position is calculated (Dish LN). But could an offset to the tracking position be sent to Dish LMC?
   • If sent directly to Dish LN or LMC then separate configure commands to the subarray node are not required - this is a change in the top level interface to TMC.

Note that ADR-76 (confluence page) suggests a design where offsets are sent to the Dish Leaf Node.

And any other questions...

Since consideration of this might involve the OSO and Dish LMC components then an ADR might be required.

Resolving this spike in PI19 to come up with key responsibilities and a design will enable implementation in a later PI (20?)

Discussion with system science, SDP and solution team on 2023-08-15: https://confluence.skatelescope.org/display/SE/2023-08-15+Science+Operations+-+SW+Sync helped to clarify how this might be done:

Instead of changing the actual tracking position in the Dish Structure (DS) use would be made of an option in the DS controller to modify (temporarily) two offsets in the static pointing model, via the method trackLoadStaticOff.

Proposal is therefore:

1. OSO scripting layer sends small (re-)configuration JSON files to TMC with just the offset value to use (via the normal "configure" command);
2. TMC relays this offset to the Dish LMC (probably a new method has to be exposed in the Dish LMC API);
3. OSO scripting layer initiates a scan as normal (with new scan_id);
4. 1-3 repeat for each of the three further offset positions
5. TMC receives new reference offsets from SDP (see ADR-76) and uses them to update the values in the DS controller (via Dish LMC)

This implies that:

• An alternative schema for the Dish configure JSON allows specification of just an offset;
• OSO must be able to generate and send this new JSON
• TMC must be able to parse this new JSON
• Need to be able to communicate this offset position to the SDP
• TMC must be able to use the new JSON to configure only the Dish LMC(s).
• TMC must be able to receive the corrected reference pointing values from SDP.

Quick whiteboard drawing from zoom call of 2023-08-16 (note "arctic" should be "arcsec"!):