[evla-sw-discuss] Metadata related to WIDAR: getting this to the SDM
Michael Rupen
mrupen at nrao.edu
Wed Feb 17 11:29:27 EST 2010
Hi folks --
please find attached a detailed discussion of how to fill the SDM with
metadata related to the WIDAR correlator. I've cc'd Michel to check
a few questions embedded in that document, but assume this is too detailed
for the rest of the ALMA folks. Once we've converged I'll send the
revised version to the CASA people so they know how we're using the
various SDM fields.
Cheers,
Michael
-------------- next part --------------
Metadata related to WIDAR
-------------------------
mrupen 17feb10
Currently MCAF reads a few key SDM properties from the file
external-sdm.properties . Most of these are related to WIDAR, and
primarily affect the Spectral Window Table. This note details how those
properties should be filled by MCAF in real time based on content from
the Executor and the VCI subarray fragment, extending Barry's spectral
window suggestions with a few tweaks noted below.
I've broken this up by SDM Table, and have included some implicit defaults
as well as all items in the external-sdm.properties file. The order
of the table elements follows that in the SDM short table listing.
Note the questions for MICHEL and BARRY/KEN embedded thoughout.
I give a sample OSRO VCI subarray fragment from the current
OPT+model2script at the end of this message.
--------------------------------------------------------------------------------
Aside: Test Observations
------------------------
This note assumes that the Executor is controlling the Configuration
Mapper through a VCI document. For test purposes we may occasionally
revert to "old style" observations with the boards set up by hand. More
commonly, we may use some of the more esoteric capabilities of the CM and
the VCI before these are fully understood by MCAF. It would be helpful
to allow the Executor (or the user) to send along something like the
external-sdm.properties file to tell MCAF how to fill in various values
when the VCI subarray fragment is unavailable, insufficient, or uses
capabilities not yet interpreted by MCAF. This may be especially
important for correlator acceptance tests in which we painfully check
capabilities well before they are fully implemented for naive observers.
Examples might include the correlator chips' auto-correlation and burst
modes, and pulsar gating and phase binning.
--------------------------------------------------------------------------------
-----------------------
ConfigDescription Table
-----------------------
numDataDescription
dataDescriptionId[] -- the order of the Ids must match that in the
corresponding BDF file. See the 16feb10 e-mail discussing the
relationship between spectral windows in the BDF and the SDM.
switchCycleId[] -- default to all SwitchCycle_0 (no switching)
numFeed -- default to 1 (>1 is intended for arrays of feeds)
feedId[numAnt*numFeed] -- default to all 0s (feedId is only one
element in a complex key)
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.
numAtmPhaseCorrection -- default to 1
atmPhaseCorrection[] -- default to AP_UNCORRECTED (no on-line
atmospheric phase correction)
processorType -- default to CORRELATOR
spectralType -- default to FULL_RESOLUTION
--------------------------------------------------------------------------------
--------------------
CorrelatorMode Table
--------------------
This table is currently highly ALMA-centric and requires extensive revision,
but not right now. I see no point in making the table values terribly
accurate.
MICHEL: I assume only numAxes and axesOrderArray are used by the filler --
numBaseband and basebandNames are overrules by the SpectralWindow Table.
correlatorModeId -- default to CorrelatorMode_0 (only one row)
numBaseband -- default to 2 for OSRO (8-bit samplers)
basebandNames[] -- default to 1 2 BB_4 BB_8
(use 1 2 A/C_8BIT B/D_8BIT if those enumerations are
available)
filterMode[] -- default to 1 2 UNDEFINED UNDEFINED
(not applicable for WIDAR)
basebandConfig[] -- default to 1 2 1 1
These are meaningless for WIDAR.
accumMode -- default to NORMAL
binMode -- default to 0
This is the number of data bins (and yes, numBin would be more sensible).
We'll eventually use this for pulsar phase bins; ALMA uses this for switch
cycles (e.g., frequency switching observations).
numAxes -- default to 6
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.
correlatorName -- default to NRAO_WIDAR
--------------------------------------------------------------------------------
---------------------
DataDescription Table
---------------------
There is one row in this table for each (Polarization, Spectral Window)
pair. Note that full pol'n (RR RL LR LL) data require an extra polarization
row for the auto-correlations (RR RL LL), so there will be twice as many
corresponding DataDescription rows as you might naively expect.
--------------------------------------------------------------------------------
-------------
Doppler Table
-------------
Not used until Doppler tracking (not setting) is implemented.
--------------------------------------------------------------------------------
---------------
Ephemeris Table
---------------
Not used for OSRO. Requires definition for Bryan's RSRO experiment.
--------------------------------------------------------------------------------
---------------
ExecBlock Table
---------------
Another ALMA-specific table, with many embedded assumptions about telescope
operation. Again it would be nice to fill in useful bits but very little
of this is relevant. I've *d those that seem useful.
execBlockNum -- default to 1
Ideally this should be the position of this Exec Block in the project
(sequential starting at 1), but I do not know how we could get that
information to MCAF.
execBlockUID -- default to meaningless value:
<EntityRef documentVersion="1" entityTypeName="ExecBlock"
partId="X00000000" entityId="uid://evla/sdm/X1"/>
projectId -- default to meaningless value:
<EntityRef documentVersion="1" entityTypeName="ObsProject"
partId="X00000000" entityId="uid://evla/sdm/X2"/>
*configName -- should come from Executor -- BARRY/KEN should say how
Currently this should default to D
*telescopeName -- default to EVLA
*observerName -- default to name of the script (e.g., XWICloop)
I would prefer this to be the name of the observer (!) but there
is no other obvious place to reference the observing script.
BARRY/KEN should say whence this comes.
*observingLog -- default to UNKNOWN
Eventually it would be nice to give this the name of the actual
observing log (maybe an html address?).
sessionReference -- default to UNKNOWN
sbSummary -- default to meaningless value:
<EntityRef documentVersion="1" entityTypeName="SBSummary"
partId="X00000000" entityId="uid://evla/sdm/X1"/>
schedulerMode -- default to UNKNOWN
baseRangeMin
baseRangeMax
baseRmsMinor
baseRmsMajor
basePa -- all defaulted to 0.0 -- we don't use any of these
siteAltitude -- default to 2115.0 (meters)
siteLongitude -- default to -107.6180555555556
siteLatitude -- default to 34.07861111111111
This is for the array center. Note that the reference frame for all
this is not specified. The station locations are much more rigorously
defined.
*aborted -- default to false
BARRY/KEN: Is there some way to note whether the ExecBlock ended early
(aborted)? If so it would be nice to fill this in correctly.
numAntenna -- default to the value for the first scan I guess
antennaId[]
sBSummaryId -- default to SBSummary_0
--------------------------------------------------------------------------------
----------
Feed Table
----------
numReceptor -- 1 or 2, depending on VCI for the appropriate
Spectral Window (i.e., 2 if products include both RR & LL)
polarizationTypes[] -- R, L, or R L, depending on VCI for the appropriate
Spectral Window
beamOffset[Nrec][2] -- default to all 0s
focusReference[Nrec][3] -- default to all 0s
polResponse[Nrec][Nrec] -- default to all 0s
receptorAngle[Nrec] -- default to all 0s
receiverId[Nrec] -- this refers to the Receiver Table, which includes
band and LO tuning information. See below.
For now, default to one value per observing band.
--------------------------------------------------------------------------------
----------------
FreqOffset Table
----------------
Not used for OSRO. To be used eventually for "clunky" (as compared to
continuous) Doppler tracking, e.g., Doppler tracking at the beginnings of
scans.
--------------------------------------------------------------------------------
------------------
Polarization Table
------------------
Requires one row for each set of Stokes parameters, as given
explicitly in the VCI fragment.
For example:
<widar:pp spectralChannels="64" id="1" correlation="A*A"/>
<widar:pp spectralChannels="64" id="4" correlation="B*B"/>
refers back to
<widar:baseBand singlePhaseCenter="yes" name="A0/C0" inQuant="8"
bw="1024000000" bbB="2" bbA="0">
so A*A is 0*0, and B*B is 2*2. 0 and 2 refer back to
<widar:bbParams sourceType="FORM" sourceId="0" sideband="upper"
polarization="R" bbid="0"/>
<widar:bbParams sourceType="FORM" sourceId="0" sideband="upper"
polarization="L" bbid="2"/>
so 0*0 is R*R and 2*2 is L*L.
In reading the VCI fragment, think Hamlet -- by indirections find
directions out.
numCorr -- the number of widar:pp elements (1, 2, or 4)
For the example above, numCorr=2.
corrType[Ncorr] -- the correlator products, as determined via the
indirections discussed in the example above. For that example
corrType would be 1 2 RR LL
For full pol'n products the order *must* be RR RL LR LL.
corrProduct[Ncorr][2] -- basically duplicates corrType. For the example
above corrproduct is 2 2 2 R R L L
For OSRO the two possibilities are
<numCorr>2</numCorr>
<corrType>1 2 RR LL</corrType>
<corrProduct>2 2 2 R R L L</corrProduct>
and
<numCorr>4</numCorr>
<corrType>1 4 RR RL LR LL</corrType>
<corrProduct>2 4 2 R R R L L R L L</corrProduct>
If numCorr=4 we have to create another row for the auto-correlations, with
<numCorr>3</numCorr>
<corrType>1 3 RR RL LL</corrType>
<corrProduct>2 3 2 R R R L L L</corrProduct>
--------------------------------------------------------------------------------
---------------
Processor Table
---------------
modeId -- default to CorrelatorMode_0
processorType -- default to CORRELATOR
processorSubType -- default to ALMA_CORRELATOR_MODE
** This enumeration value should be changed to CORRELATOR_MODE to match
the SDM Table correctly, but for now ALMA_CORRELATOR_MODE works with the
filler
--------------------------------------------------------------------------------
--------------
Receiver Table
--------------
This Table is currently not filled, and no-one seems to care.
Eventually this should hold the observing band (e.g., 4-8_GHz), the
receiver serial number, and the details of the LO tuning.
--------------------------------------------------------------------------------
---------------
SBSummary Table
---------------
Similar to the ExecBlock Table, this needs some work to be useful for the
EVLA. But we ignore that for now and just fill in meaningless defaults.
sBSummaryId -- default to SBSummary_0, i.e., one row
sBSummaryUID -- default to meaningless value:
<EntityRef documentVersion="1" entityTypeName="SBSummary"
partId="X00000000" entityId="uid://evla/sdm/X1"/>
projectUID -- default to meaningless value:
<EntityRef documentVersion="1" entityTypeName="ObsProject"
partId="X00000000" entityId="uid://evla/sdm/X1"/>
obsUnitSetId -- default to meaningless value:
<EntityRef documentVersion="1" entityTypeName="ObsUnitSetId"
partId="X00000000" entityId="uid://evla/sdm/X1"/>
frequency -- default to 0.0
frequencyBand -- default to UNXPECIFIED
sbType -- default to OBSERVATORY
sbDuration -- default to 0
centerDirection -- default to 1 2 0.0 0.0
numObservingmode -- default to 0
observingMode[] -- default to 1 0
numberRepeats -- default to 0
numScienceGoal -- default to 0
scienceGoal[] -- default to 1 0
numWeatherConstraint -- default to 0
weatherConstraint[] -- default to 1 0
--------------------------------------------------------------------------------
--------------------
SpectralWindow Table
--------------------
We use a few values over and over again for this table. Here's their origin:
SSLO: signed sum of the LOs, from the observation document
sideband: from the observation document (USB= +1; LSB= -1)
centralFreq: the central frequency of the subband, from the
widar:subband element of the VCI fragment
bw: the total subband bandwidth, from the widar:subband element
of the VCI fragment
basebandName -- see 16feb10 e-mail regarding swbbName
netSideband -- default to USB
We claim we always present USB to the Baseline Boards.
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).
refFreq -- the frequency at the zero-frequency edge of the subband:
refFreq= SSLO + sideband*(centralFreq-bw/2)
sidebandProcessingMode -- default to FREQUENCY_OFFSET_REJECTION
(this seems more accurate than Barry's FREQUENCY_OFFSET_SEPARATION)
totBandwidth -- bw
windowFunction -- default to UNIFORM (which means "no windowing")
chanFreqStart -- same as refFreq
chanFreqStep -- bw/numChan -- ALWAYS POSITIVE
chanWidth -- bw/numChan
effectiveBW -- bw/numChan
resolution -- bw/channel
oversampling -- default to false (Nyquist sampling)
quantization -- default to false (no quantization correction applied)
correlationBit -- default to BITS_4x4
Ideally we should take this value from the VCI fragment
<widar:subBand rqNumBits="XX">
(currently XX=4). At some point the enumeration should be extended
to allow BITS_7x7 .
name -- leave this out for now -- deserves some thought, if we want
to use it at all.
numAssocValues -- default to 1
assocSpectralWindowId[] -- the corresponding SpW with numChan=1 (see below)
assocNature[] -- default to CHANNEL_AVERAGE
For switched power purposes we define another SpW row for each "standard"
(visibility) row, with values as above except:
numChan set to 1
chanFreqStep etc. set to bw
assocSpectralWindowId[] points to the corresponding "standard" row
assocNature[] -- default to FULL_RESOLUTION
--------------------------------------------------------------------------------
------------
SysCal Table
------------
This is another kettle of fish, to be opened in a separate discussion.
================================================================================
Sample VCI subArray fragment:
<widar:subArray timeStamp="2010-02-16T11:45:50.470-07:00" subarrayId="1"
scanId="42" name="Osro01.1" msgId="1546206396" mappingOrder="5"
activationId="Osro01_sb9_1_scan0001" action="create">
<widar:listOfStations action="add">
<widar:station sid="1" name="Station 1"/>
<widar:station sid="2" name="Station 2"/>
<widar:station sid="3" name="Station 3"/>
<widar:station sid="4" name="Station 4"/>
<widar:station sid="5" name="Station 5"/>
<widar:station sid="6" name="Station 6"/>
<widar:station sid="7" name="Station 7"/>
<widar:station sid="8" name="Station 8"/>
<widar:station sid="9" name="Station 9"/>
<widar:station sid="11" name="Station 11"/>
<widar:station sid="13" name="Station 13"/>
<widar:station sid="14" name="Station 14"/>
<widar:station sid="15" name="Station 15"/>
<widar:station sid="16" name="Station 16"/>
<widar:station sid="18" name="Station 18"/>
<widar:station sid="19" name="Station 19"/>
<widar:station sid="20" name="Station 20"/>
<widar:station sid="21" name="Station 21"/>
<widar:station sid="23" name="Station 23"/>
<widar:station sid="24" name="Station 24"/>
<widar:station sid="25" name="Station 25"/>
<widar:station sid="26" name="Station 26"/>
<widar:station sid="27" name="Station 27"/>
<widar:station sid="28" name="Station 28"/>
</widar:listOfStations>
<widar:stationInputOutput sid="all">
<widar:bbParams sourceType="FORM" sourceId="0" sideband="upper"
polarization="R" bbid="0"/>
<widar:bbParams sourceType="FORM" sourceId="0" sideband="upper"
polarization="R" bbid="1"/>
<widar:bbParams sourceType="FORM" sourceId="0" sideband="upper"
polarization="L" bbid="2"/>
<widar:bbParams sourceType="FORM" sourceId="0" sideband="upper"
polarization="L" bbid="3"/>
<widar:bbParams sourceType="FORM" sourceId="0" sideband="upper"
polarization="R" bbid="4"/>
<widar:bbParams sourceType="FORM" sourceId="0" sideband="upper"
polarization="R" bbid="5"/>
<widar:bbParams sourceType="FORM" sourceId="0" sideband="upper"
polarization="L" bbid="6"/>
<widar:bbParams sourceType="FORM" sourceId="0" sideband="upper"
polarization="L" bbid="7"/>
<widar:baseBand singlePhaseCenter="yes" name="A0/C0" inQuant="8"
bw="1024000000" bbB="2" bbA="0">
<widar:subBand useMixer="no" signalToNoise="0" sbid="0"
rqNumBits="4" pulsarGatingPhase="0" name=""
mixerPhaseErrorCorr="yes" centralFreq="448000000" bw="128000000">
<widar:polProducts>
<widar:pp spectralChannels="64" id="1" correlation="A*A"/>
<widar:pp spectralChannels="64" id="2" correlation="A*B"/>
<widar:pp spectralChannels="64" id="3" correlation="B*A"/>
<widar:pp spectralChannels="64" id="4" correlation="B*B"/>
<widar:blbProdIntegration recirculation="1" minIntegTime="200.0"
ltaIntegFactor="2500" ccIntegFactor="2" cbeIntegFactor="1"/>
<widar:blbPair quadrant="1" numBlbPairs="1" firstBlbPair="0"/>
<widar:stationPacking algorithm="maxPack"/>
<widar:productPacking algorithm="maxPack"/>
</widar:polProducts>
</widar:subBand>
</widar:baseBand>
<widar:baseBand singlePhaseCenter="yes" name="B0/D0" inQuant="8"
bw="1024000000" bbB="6" bbA="4">
<widar:subBand useMixer="no" signalToNoise="0" sbid="0"
rqNumBits="4" pulsarGatingPhase="0" name=""
mixerPhaseErrorCorr="yes" centralFreq="448000000" bw="128000000">
<widar:polProducts>
<widar:pp spectralChannels="64" id="1" correlation="A*A"/>
<widar:pp spectralChannels="64" id="2" correlation="A*B"/>
<widar:pp spectralChannels="64" id="3" correlation="B*A"/>
<widar:pp spectralChannels="64" id="4" correlation="B*B"/>
<widar:blbProdIntegration recirculation="1" minIntegTime="200.0"
ltaIntegFactor="2500" ccIntegFactor="2" cbeIntegFactor="1"/>
<widar:blbPair quadrant="1" numBlbPairs="1" firstBlbPair="1"/>
<widar:stationPacking algorithm="maxPack"/>
<widar:productPacking algorithm="maxPack"/>
</widar:polProducts>
</widar:subBand>
</widar:baseBand>
</widar:stationInputOutput>
</widar:subArray>
================================================================================
More information about the evla-sw-discuss
mailing list