You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think a scan "subtable" (i.e scan_xds) is needed where an association of SCAN_NUMBER to more info that includes the intent, the time interval that the scan was observed and/or any other hardware settings that are specific to this scan (may be combined with intent).
Otherwise we already discussed antenna, pointing and field xds.
The text was updated successfully, but these errors were encountered:
A MSv4 can have more than one intent but all visibilities must have the same intents. A single visibility can have more than one intent for example ALMA commonly has:
This intent information is currently stored in ms_xds.partition_info['intents']. We can add additional information in the SCAN_NUMBER attributes. @kgolap what do you suggest we add?
I guess SCAN_NUMBER is moot for a single msV4 but its existence is really when working with multiple msV4...then just a number does not make sense unless it is tied to a processor and intent.
My bad i missed that the partition_info contains the intents. Well then things have to be associated with the SCAN_NUMBER may be as a key. I guess that ms_xds.processor_info will have to a similar reference
I think a scan "subtable" (i.e scan_xds) is needed where an association of SCAN_NUMBER to more info that includes the intent, the time interval that the scan was observed and/or any other hardware settings that are specific to this scan (may be combined with intent).
Otherwise we already discussed antenna, pointing and field xds.
The text was updated successfully, but these errors were encountered: