[evla-sw-discuss] Keeping track of spectral windows at the EVLA: SDM vs. BDF

[Francois Viallefond]

On Wednesday 17 February 2010 01:15, Michael Rupen wrote:
> Hi folks --
>
>    please find attached a portion of the SDM intro document dealing
> with the association between spectral windows in the SDM, and those
> in the BDF.  A previous iteration was approved by Francois so I think this
> is kosher.  

- I have never seen before this SDM intro document! Hence, if it is publicly 
available, you must remove my name from it!
- What is a  kosher? I can not find the french translation!

> Note that there are subsections at the beginning & end you 
> probably don't care about at the moment.  Much of the rest of this
> message is detailed and EVLA-centric; I've cc'd several CASA and ALMA
> folks in case they have comments, since this affects the filler at least.
>
>    Basically we have to ensure that the order in which the spectral windows
> are stored in the BDF matches the order in which those spectral windows are
> referenced in the dataDescriptionId array in the SDM's ConfigDescription
> Table.   The order in the BDF is required to be such that swbb and sw occur
> in ascending order; the combination of swbb and sw is unique for the EVLA
> (for ALMA they have to worry about the sideband but that's a detail).  So
> if we agree on swbb and sw and send that information to both the CBE and
> MCAF we should be OK.  We are sending all other information like by sending
> the VCI's subarray element to MCAF as well as the Confiruation Mapper, so I
> propose using that same route here.
>
> swbb is the "baseband ID" in the SDM sense.
>
>    1. I propose that we make this one-to-one with the VCI's baseBand name
>      (e.g., A1/C1).
>      - This is currently an optional attribute; the suggested change would
>        make this required.  If this does violence to the VCI (e.g., all
>        names are currently optional), we should create a new attribute,
> maybe swbbName  enumeration or string
>
>    2. The BDF and the SDM use the BasebandName enumeration:
>
>         BB_1  BB_2  BB_3  BB_4 BB_5  BB_6  BB_7  BB_8  NOBB
>
>      I propose adding more useful EVLA names to this enumeration:
>
>         A1/C1_3BIT  A2/C2_3BIT   A/C_8BIT
>         B1/D1_3BIT  B2/D2_3BIT   B/D_8BIT

One basic technical point here:
it is not possible to write in the c/C++ enum enumerators which have the '/'
character. You have to replace this by something else!

One question: 
Heum... do you concatenate here two infos? Is the second part, a number of 
BITs, already an item somewhere else in the DM?


>      Part of the point here is to avoid confusion with WIDAR's baseband
> IDs, which are *not* the same (though they are closely related).
>
>      2b. If it takes any time to add to that enumeration, 

In principle this is a trivial task!

>      I propose 
>        something similar to Barry's scheme:
>
>          BB_1 ==> A1/C1_3BIT
>          BB_2 ==> A2/C2_3BIT
>          BB_4 ==> A/C_8BIT
>
>          BB_5 ==> B1/D1_3BIT
>          BB_6 ==> B2/D2_3BIT
>          BB_8 ==> B/D_8BIT
>
>    3. The required ascending order is then:
>
>         BB_1  BB_2  BB_3  BB_4 BB_5  BB_6  BB_7  BB_8  NOBB
>         A1/C1_3BIT  A2/C2_3BIT  A/C_8BIT  B1/D1_3BIT  B2/D2_3BIT  B/D_8BIT
>
>
> sw is the spectral window index (an integer) in the BDF, which is NOT the
> same as the spectral window ID (tag) in the SDM.
>
>    1. We could use the VCI's subband element's name attribute
>      (an optional ASCII string at the moment), making that mandatory; or we
>      could create a new attribute like
>        swName   string
>      or perhaps better
>        swIndex  integer
>
>    2. The value of name/swName/swIndex would have to be an integer starting
>      at 1.   Ascending order is then obvious.
>
> The CM would pass these new attributes on to the CBE, which would sort
> all the extant swbbName/swIndex pairs into the proper order and store them
> in the sdmDataHeader element.
>
> The Executor would pass these new attributes along with the rest of the
> VCI subarray fragment to MCAF, which would extract the swbbName/swIndex
> pairs and figure out from those the proper order for the dataDescriptionId
> array.
>
> Of course this begs the question of who comes up with swbbName and swIndex
> to begin with.  This seems properly left to the OPT: there is enough
> information there, and these values can be determined independently for
> every scan.  It would be preferable to have a deterministic algorithm for
> doing so.  For swbbName this is trivial.  For swIndex within a given
> swbbName I propose:
>
>    1- sort by the lower edge of the lowest frequency channel in each
> subband (to match the ALMA ACA correlator)
>    2- for remaining matches, give the lower swIndex to the SpW with
>      the narrower channels
>    3- for remaining matches, give the lower swIndex to the SpW with the
>      fewer total channels
>    4- at this stage we have only exact matches left.  If the OPT or
> whatever is explicitly setting the StB filter to be used, the lower filter
> gets the lower swIndex.
>
> All of this of course is negotiable.

I assume that this is only an internal rule. It could be that some other 
processors (correlators) may have different internal rules.

> A couple points:
>
> * In the BDFs, all SpW in "lower" swbbName's come before all SpW in
> "higher" swbbName's, regardless of the actual frequency tunings.  A/C comes
> before B/D, full stop; similarly data from A1/C1_3BIT comes before
> A/C_8BIT.
>
> * In the BDFs, within a given swbbName, the above scheme would put
>    non-overlapping SpW in frequency order (low to high).
>
> * None of this says ANYTHING about the ordering of the actual Spectral
>    Windows seen by the observer in post-processing, or even in the SDM.
>    That is a separate discussion, which I hope to initiate tomorrow or
>    Thursday.
>
>
>
> Comments?
>
>             Michael

Francois