[evla-sw-discuss] Metadata related to WIDAR: getting this to the SDM

[Michael Rupen]

Hi Martin --


> Michael Rupen wrote:
>> correlationMode -- default to CROSS_AND_AUTO .
>>   The options are CROSS_AND_AUTO, CROSS_ONLY, AUTO_ONLY.
>>   The Configuration Mapper sets up the BlBs to produce as many
>>   auto-correlations as possible, so for OSRO and most RSRO we will
>>   be in the CROSS_AND_AUTO case.  Note that this implies only that _some_
>>   auto-correlations are produced -- in general, and certainly for the first
>>   observations, we will have only half of the possible auto-correlations.
>>   It is the CBE's responsibility to store zeroes and binary flags for the
>>   unmeasured auto-correlations.  We have used CROSS_ONLY in the past
>>   for manual BlB setups and to avoid bugs in the filler.
>
> The CBE determines the value of correlationMode recorded in the BDFs
> based on its configuration. If the CM always produces some
> auto-correlations, then fixing this value in the SDM should be OK;
> otherwise, we could end up with an inconsistency.

Currently there's nothing in the subarray element of the VCI document
passed to the CM which says "do autos" or "don't do autos".  So I didn't
see any way for MCAF to figure this out, and hence went to the proposed
default.


>> axesOrderArray -- default to 1 6 BAL BAB SPW BIN SPP POL
>>   The number and order of the axes must match that of the visibility
>>   data in the BDF file.  The ordering of those axes is implicit, as given
>>   by the ordering of the AxisName enumeration in Table 1 of the BDF
>>   definition document.
>
> Actually, this should be BAL BAB SPW BIN SPP STO.

Yeah, I wondered about that.  The default here was what we'd
been using for all observations up to now, but I agree that we should
match what you have!

>> numAntenna -- default to the value for the first scan I guess
>
> This is determined by the CBE from the list of station ids in its
> configuration document, and is recorded in the BDF. Must the values of
> numAntenna be the same in the BDF and the ExecBlock table?

The ExecBlock doesn't matter at all.  numAntennas etc. also
appear in the ConfigDescription Table, which *does* matter.  There
currently MCAF is getting this from another (non-VCI) document, also
created by the Executor.  So there is a question as to whether both
the CBE and MCAF should get this from the VCI document instead.
It _shouldn't_ matter, but you know how that is...


>> numChan -- from the VCI fragment <widar:pp spectralChannels="XX">
>>   Note that the number of channels must be identical for all pol'n products
>>   at the moment (all OSRO and RSRO data).
>
> When we do the Fourier transform in the CBE, the number of channels is
> reduced by half; otherwise, not. In the BDF, the equivalent of "numChan"
> is set by the CBE configuration document, and its value should account
> for the final number of channels; the CM must account for that in
> creating the CBE configuration message. Does MCAF need to do the same?

The note I sent around didn't cover the lag case, as you point out.
The SDM does not handle that gracefully at all.  Presumably the "FFT or not" 
instruction is sent along with the CBE part of the VCI message from the 
Executor; I was waiting to see that defined, before detailing how MCAF
should deal with this.  Basically as you say we'll just multiple numChan
by two.  The frequency axis will be pretty much meaningless at that point
but we've said that lags are enough of an edge case that we don't care.

          -- Michael