danielczech
commented
4 years ago The changes in commits 470ae05, cabcf82 and e935833 provide the above features; these will be tested during engineering time (hopefully today, 2020-05-28).
The target name is derived only from components explicitly part of the current subarray under consideration. Thus <array_name> always refers to the current subarray specifically.
Some thought may need to be given to circumstances in which antennas within the same subarray are pointed at different targets (if such circumstances are possible). Would this be the case in fly's eye mode observations, for example?
david-macmahon
Maintaining a history of key metadata values is useful for knowing which antennas have observed which sources and when. Two of the more critical metadata fields to memorialize this way are antennas and target. Unfortunately, there are several different ways to get at subtly different antennas and target metadata values. We need a way to canonicalize this.
An initial demonstration of how this historical data could be maintained has been setup to scrape the katcp and katportal log files on the head node to populate redis keys:
These redis keys refer to hashes whose fields are timestamps and whose values are strings. The timestamps represent UTC time and are formatted as:
Where
YYYYis the four digit year,mmis the month,ddis the day,Tis literal 'T' to separate date and time,HHis the hour,MMis the minute,SS.SSSis the seconds to millisecond precision, andZis a literal 'Z' to indicate UTC.For strftime() implementations that support the
%Nconversion specification, the format string for this format this is%Y%m%dT%H%M%S.%3NZ. For strftime() implementations that lack%Nsupport, the format string is%Y%m%dT%H%M%S.000Z. The latter form sets the milliseconds field to "000" for simplicity.The values for the
antennasfields are a JSON string that represents an ordered list of antenna names, such as:Note that JSON require double quotes.
The values for the
targetfields are just the string taken directly from the sensor value.One other point is that the keys for these history hashes need to be canonicalized. The current use of
<array_name>(e.g.array_1) is derived from the name that our KATCP server gets from CAM. For the target name, however, the value has been taken from different sensors, some without the array name in their names. How to best canonicalize these is an open question. Additional details about available MeerKAT sensor values are needed to illuminate a path forward.