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

[Barry Clark]

As usual with things SDM, this will take a little study.  But one quick
remark - I've no problem with things being mandatory for the EVLA and
optional for the rest of the world.  That is, we can use the schema as
is for those things that fit.  (The format checking service of XML is
not very valuable, IMHO.)

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.  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
> 
>     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, 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.
> 
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> This body part will be downloaded on demand.