While the physical coordinate system labels in msv4 are straightforward, I found the hardware channel index traceability to be slightly less intuitive.
The msv2 -> msv4 conversion might reverse the array along the frequency axis to ensure an increasing order for other benefits. Since this behavior doesn't seem to be explicitly defined in the schema (as far as I understand), is it a reference implementation choice?
The slight confusing part or maybe a bug (?) is that some sub_xds objects (e.g., system_calibration_xds) could still get attached with the raw channel index (in msv2 -- essentially the table array indices) as the frequency label. This discrepancy, for example, might lead to slight confusion regarding tsys data presentation.
I guess that the hardware / original msv2 correlator channel ordering and channelization is permanently lost? I haven't noticed obvious msv2-or-hardware-channel-to-frequency mapping.
Retaining the original channel index information might be useful for specific use cases, such as dealing with online/hardware calibration tables, diagnosing hardware artifacts... Though perhaps the assumption is that these issues should already be corrected by the time the data arrives in MSv4. Most typical calibration and imaging workflows don't need this.
Note: For context, the initial case I encountered was an LSB spw, which has descending chan_freq when in msv2. I am bringing this up just for clarification.
While the physical coordinate system labels in msv4 are straightforward, I found the hardware channel index traceability to be slightly less intuitive.
The
msv2->msv4conversion might reverse the array along the frequency axis to ensure an increasing order for other benefits. Since this behavior doesn't seem to be explicitly defined in the schema (as far as I understand), is it a reference implementation choice?The slight confusing part or maybe a bug (?) is that some
sub_xdsobjects (e.g.,system_calibration_xds) could still get attached with the raw channel index (inmsv2-- essentially the table array indices) as the frequency label. This discrepancy, for example, might lead to slight confusion regardingtsysdata presentation.I guess that the hardware / original
msv2correlator channel ordering and channelization is permanently lost? I haven't noticed obviousmsv2-or-hardware-channel-to-frequency mapping.Retaining the original channel index information might be useful for specific use cases, such as dealing with online/hardware calibration tables, diagnosing hardware artifacts... Though perhaps the assumption is that these issues should already be corrected by the time the data arrives in MSv4. Most typical calibration and imaging workflows don't need this.
Note: For context, the initial case I encountered was an LSB spw, which has descending
chan_freqwhen inmsv2. I am bringing this up just for clarification.