Enable AA0.5 solution for providing delays for the CBF based on a shared source of truth for 'Telescope Model' parameters

Why?

We believe that developing a simple solution for sharing telescope data and using it to evaluate "telescope model" parameters is needed for the successful operation of AA0.5 commissioning tests without having to resort to unacceptable levels of manual synchronisation between sub-systems.

Geometric delay calculation is needed by the CBF for the generation of visibilities and in order to process/analyse the visibility data products eventually written by the SDP, SDP will need to share the same instrument configuration parameters when evaluating uvw coordinates that it writes to the visibility data products (eg Measurement Sets).

Who?

Provides a solution to developers generating and consuming geometric delays and uvw coordinates.

What? (Outcomes)

The immediate use case for this capability is for TMC to correctly publish geometric delays for CBF subscription.

In order to achieve this goal, we want to enable the telescope model as a service for all the systems to use. More general value is obtained by enabling a clear structure and service for when information is shared between TMC, CBF, SDP. 

In this PI it is essential that the Telescope Model includes:

• The minimal set of information needed by the system to know the available telescope resources (i.e. how does the system know that 4 dishes are available for use? )
• Dish configuration information including receptors' position.
• ... to be completed ... 

The TMC implementation of delay calculation will be based on such information and it will contribute to the refinement and implementation of the CSP-TM interface  ( see References below  ). 

What do we need to learn?

• Do we have a solution that will enable AA0.5 use cases and related computations
• Can we manage the lifecycle of these data products based on this very simple solution
• How we measure performance metrics with a view to understanding future scaling considerations. 

Important NFRs / Success Measures

Usability of the telescope model service and libraries. As the product evolves we anticipate that a very basic layer is now implemented to expose information contained in the model in a raw format and without needing much intelligence in interpreting the data. (i.e.  python dictionaries VS typed objects) . Usability in this context is not only represented by how easy it is for a client to extract relevant information but most importantly how easy it is to add new information to the model. 

Availability of information extracted from the Telescope Model service needs to be considered in the event of loss of connection. How information is stored locally by the client. 

Consistency of telescope model information between different clients. It is important to be able to address a specific version of the information contained in the telescope model when querying the system. It's also important to know what version is being used in a running system. 

Scalability and Performance of the geometric delays computation is a longer-term key concern.  It will be important to measure performance metrics in relation to this first implementation to understand RAM and CPU consumption for delay calculation and also provide an estimate of the wall clock time. If achievable within the time constraints the implementation needs to take into account how the calculation and transmission of corrections will scale with the number of baselines in the TANGO system. How this is split into devices and device servers.

References

• https://gitlab.com/ska-telescope/katpoint  (https://github.com/ska-sa/katpoint)
• (geometric delays) https://developer.skao.int/projects/katpoint/en/latest/katpoint.html?highlight=delay#katpoint.Target.geometric_delay
• (uvw) https://developer.skao.int/projects/katpoint/en/latest/katpoint.html?highlight=uvw#katpoint.Target.uvw
• Telescope Model description in the Solution Intent: https://confluence.skatelescope.org/display/SWSI/Telescope+and+Resource+Model+architecture+AA0.5 
• LOW coordinates https://ska-aw.bentley.com/SKAProd/Search/QuickLink.aspx?n=SKA-TEL-SKO-0000422&t=3&d=Main%5ceB_PROD&sc=Global&r=04&i=view 
• MID coordinates https://ska-aw.bentley.com/SKAProd/Search/QuickLink.aspx?n=SKA-TEL-INSA-0000537&t=3&d=Main%5ceB_PROD&sc=Global&r=09&i=view 

 

FROM LOW-CSP to TM

3.8.8.5.2 Station Beam Delay Tracking 

Station Beam delay polynomials are required for all Processing Modes. The TM shall provide these parameters in advance of the scan start time and at regular intervals during the scan. TM shall also specify date and time (UTC) when the specified set of values becomes valid. Each CSP_Low sub-array subscribes for updates independently. Parameters for all Station Beams within a sub-array are expected to be rolled up into a sub-array update.

The initial values should be received 20 seconds (TBC.008) in advance of the scan start time. 

The Station Beam Delay Polynomials shall be updated every 10 seconds in real-time during a scan. 

Table 3-32 Station Beam Delay Polynomials required for all Processing Modes

Note: Section 3.8.8.5.2 is followed by 4 sections which list the parameters specific for each of  the supported processing modes: correlation, PSS, PST and VLBI.    Configuration for zoom modes should be defined. 

3.8.8.5.3 Updates for the processing mode correlation

The Station Beam Delay Polynomials as described in Section 3.8.8.5.2 must be provided for each sub-array where the Processing Mode Correlation is active.

Table 3-32 lists correlation-specific parameters that require updates during a scan.  TM shall provide these parameters in advance of the scan start time and at regular intervals during the scan. TM shall also specify date and time (UTC) when the specified set of values becomes valid. Each CSP_Low sub-array subscribes for updates separately. Parameters for all Station Beams within a sub-array are expected to be rolled up into a sub-array update.

...

FROM MID-CSP to TM ICD

3.6 Subarray and Scan Configuration

...

Some of the parameters require updates during the scan; those parameters can be classified in two categories:

1. The parameters that require regular updates during the scan (e.g. parameters for delay tracking).   These parameters are critical for the validity of the output products and CSP_Mid must be able to detect and report when the provided parameters become outdated.  The cadence for updates should be specified in advance (via command ‘configure scan’) or the validity period should be specified as a part of the message. 

...

3.6.1 Scan Configuration for the Processing Mode Correlation

...

 

3.8.8.5 TM_Mid TelState TANGO Device Attributes and Events

The Sections below list the attributes that shall be provided by TM, or by other Elements via TM, to CSP_Mid. This version of the ICD does not provide implementation details (type, format, properties). 

The following applies for all the attributes delivered via the TM_Mid TelState:

1. CSP_Mid requires read-only access. 
2. The delivery method is publish-subscribe, TM provides the subscription point information (TANGO Device FQDN and attribute names) either in advance or as a part of scan configuration. 
3. The event is Absolute Change Event (i.e. the event is generated when the value changes).

 

The following applies for all the parameters which require periodic updates during scan execution:

1. As a part of scan configuration, the CSP_Mid subarray subscribes to receive the parameters.  
2. The TM shall specify the time when the new set of parameters becomes valid (i.e. when the CSP_Mid shall begin to apply the new model), the epoch for application of models is usually specified on second. 
3. The parameters shall be made available 5 to 10 seconds in advance of the specified activation time (TBC.003).
4. The validity period and cadence for updates may be indicated in advance or as a part of the parameter set (exact implementation will be agreed during construction). 
5. Parameters shall be provided for a sub-array where obsState = SCANNING; but are also accepted when obsState = CONFIGURING and READY.

 

As a part of the scan configuration, the TM provides to the CSP_Mid the subscription point (the TANGO Device FQDN and attribute names) for the parameters to be delivered using publish-subscribe method; the CSP_Mid subscribes to receive the parameters.  For the parameters sourcing from the SDP (e.g. polarization calibration coefficients, a.k.a. Jones Matrices), most likely the CSP_Mid will be instructed to subscribe with the SDP TelState directly.

 

3.8.8.5.2 Delay Tracking and Calibration parameters for Correlation

Table 3-29 Delay tracking and calibration parameters