 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
J. McMullin, R. Garwood, J. Braatz
17 January 2003
A (gzipped) postscript version of this note is available (21kB).
Enhancement: AOCso04231
Enhancement: AOCso04231
Enhancement: AOCso04232
Enhancement: AOCso04233
Enhancement: AOCso04232
Enhancement: AOCso04235
Enhancement: AOCso04234
Target: 153 beam switched calibration refinements
Target: 119.1 msconcat: works for all subtables
Target: 111.15 gbtmsfiller: Support BS data
Target: 111.16 gbtmsfiller: Support multi-beam data
Target: 153 beam switched calibration refinements
Target: 172 Multi-beam Imaging
No Targets set.
Target: 119.1 MSCONCAT works for all subtables
No targets set.
This chapter provides brief guidelines on how multi-frequency observing at the GBT will be enabled. Specifically, this note addresses the situations described in the Maddalena Memo ("Requirements for Multifrequency Observing with the GBT"). In the first section, I review the observing scenarios posed and the associated information which will be available in FITS files. The association with MeasurementSet v2.0 keywords and subtables is made and the implementation of tools for virtual and permanent alterations to the observed frequency scale are listed.
The Maddelena Memo describes the required inputs for configuring the hardware and observing. The relevant parameters available in the FITS files are:
These parameters map to the following locations in the MeasurementSet.
MS SUBTABLE:
DATA_DESCRIPTION SPECTRAL_WINDOW:
PARAMETER:
DATA_DESC_ID->SPECTRAL_WINDOW_ID Int
Based on spectral tolerance, each window has a designated spectral window ID. This is mapped by the DATA_DESC_ID in the MAIN table to the DATA_DESCRIPTION table which will list the appropriate spectral window IDs for a given scan/observation. Information on each spectral window ID is found in detail in the SPECTRAL_WINDOW subtable.
MS SUBTABLE:
SOURCE PARAMETER: Format Units Measure
REST_FREQUENCY Double(NUM_LINES) Hz Frequency Several lines/transitions can be associated with a source and spectral window ID. REST_FREQUENCY will be a vector of doubles. The lines or transitions can also be specified in a string vector, TRANSITION: TRANSITION STRING(NUM_LINES)
MS SUBTABLE:
FREQ_OFFSET
PARAMETER: Format Units
OFFSET Double Hz This subtable contains frequency offset information, to be added directly to the defined frequency labeling in the SPECTRAL_WINDOW subtable as a measure offset. This allow bands with small, time variable, ad hoc frequency offsets to be labeled as the same SPECTRAL WINDOW if desired.
MS SUBTABLE:
DOPPLER
PARAMETER:
VELDEF Double m/s DOPPLER
VELDEF is a DOPPLER measure which contains the velocity definition (RADIO, OPTICAL, TRUE) and the velocity in m/s.
MS SUBTABLE:
SPECTRAL_WINDOW, SOURCE
PARAMETER:
CHAN_FREQ Double(NUM_CHAN) Hz FREQUENCY
The restFrame (LSRK, LSRD, BARY, GEO, TOPO, GALACTO, etc) is encoded in the FREQUENCY measure of the spectrum's abcissa, CHAN_FREQ.
MS SUBTABLE:
SOURCE
PARAMETER:
SYSVEL Double(NUM_LINES) m/s RADIAL VELOCITY
This has the source systemic velocity for each line/transition and the appropriate reference frame (LSRK, LSRD, BARY, GEO, TOPO, GALACTO).
MS SUBTABLE:
OBSERVATION
PARAMETER:
TELESCOPE_NAME String
The telescope name can be used to create a POSITION measure which has the earth location from which the observation was made.
MS_SUBTABLE:
SOURCE others PARAMETER:
DIRECTION Double(2) rad DIRECTION
The source direction and coordinate frame are in the DIRECTION measure.
MS SUBTABLE:
MAIN, almost any
PARAMETER:
TIME Double s EPOCH
The TIME may be used as a EPOCH measure to determine frame information. In the MAIN and POINTING tables, this is the mid-point of an observing interval.
The observing scenarios may be implemented through the support of the two canonical modes: SFSW and MFSW. The SFSW mode is already supported and has been the default. The MFSW mode needs to be supported for cases in which the observation was planned as an MFSW and also in cases where it was not anticipated such that key information isn't necessarily available natively in the data. The MFMW-1 mode is essentially the same as the SFSW mode in terms of the implementation; each window has the information and behavior of an SFSW. Similarly, the MFMW-2, MFMW-3 will behave as the the SFSW or MFSW case as appropriate. The SFMW is essentially the same as the SFSW case in terms of the spectral axis tracking requirements, however, its processing relies on the ability to combine the banks (in a properly weighted-way) into a single spectrum.
The filler constructs the spectral axis using the following information:
For each pixel along the IF axis of the backend data (RECEIVER axis for SP, SAMPLER for ACS data), the filler determines what is the matching row in the IF FITS file; that row gives the polarization and feed information and it gives all of the components for working out the sky frequency except for the LO1. The LO1 information is taken from LO1A or LO1B (based on information from the IF FITS file) and also provides the doppler information. The center channel is calculated (currently ad hoc - can now use information from the IF FITS file) that corresponds to the sky frequency.
The filler then calculates the LO1 frequency for each switching state at the first time it finds in the LO1 FITS file. It now has for each state a sky frequency axis at a specific time, antenna position, and pointing direction (this is a predicted position - the LO1 file contains the predicted LO1 frequencies) as well as a rest frequency, reference frame, and velocity to track.
Using the above and the doppler information, the sky frequencies are converted to a frequency axis in the tracked reference frame. The filler assumes that the M&C doppler tracking applies throughout the scan (hence the frequency axis is constant throughout the scan). As subsequent scans are filled, if their frequency axis is within the maximum of the specified tracking tolerance or 5 Hz of a previously filled spectral window, that spectral window is also assigned to the new data.
The dish plotter function, plotrec, handles the appropriate display of the data. Each spectrum is treated as a 1-d image with a DIRECTION and SPECTRAL coordinate. The SPECTRAL coordinate is constructed based on:
Frame information is also provided (for the frame conversions that require it) on:
The following details the handling for the unplanned and planned cases.
d.open('stjul13SP'); #using the standards_jul13 data
myscan:=d.getc(35);
myscan.data.desc.restfrequency
1.4204058e+09
myscan.data.desc.restfrequency:=1.4104058e+9
d.plotscan(myscan) #if you have velocity displayed you should see the
#shift far from 0
A tool for manipulating the REST_FREQUENCY will be required for enduring changes (saved to disk for an MS). The tool implementation would look as:
- d.restfrequency(spectral_window_id,new_restfreq_value);
The spectral window can be obtained from the d.summary(T) on the MS.
Alternatively, if multiple REST_FREQUENCY values were specified in the observation, an additional argument to the plotter functions can be made available to specify which should be used. This would then be available upon the specification of the coordinate system and used for subsequent display and access.
The data will have the RESTFRQS and NUM_LINES information filled. The sditerator will have a function which will enable toggling between members of this vector. The proposed syntax would be:
- d.open('myms_SP'); #creates the sditerator myms_SP
- myms_SP.rfindex(2); #change the spectral axis according to the rest
#frequency element 2
Some graphical representations of the intended flow through the package.
Each image tool also provides access to its underlying coordinate system. The coordsys tool has the function setrestfrequency (shorthand srf) which allows one to set the rest frequency by either over-writing the value or appending to a list. An argument of this function specifies which rest frequency is active.
Example:
- im:=image('my_image');
- csys:=im.coordsys();
- csys.summary();
Image name : g29_pre.im
Image type : PagedImage
Image quantity : Intensity
Pixel mask(s) : None
Region(s) : None
Image units : Jy/beam
Direction reference : GALACTIC
Spectral reference : TOPO
Velocity type : RADIO
Rest frequency : 1.42041e+09 Hz
Pointing center : 29.300000 -6.500000
Telescope : GBT
Observer : UNKNOWN
Date observation : UNKNOWN
Axis Coord Type Name Proj Shape Tile Coord value at pixel Coord
incr Units
--------------------------------------------------------------------------------
----------
1 1 Direction Longitude SIN 20 10 29.300 11.00 -2.176708
e+02 arcsec
2 1 Direction Latitude SIN 152 38 -6.500 77.00 2.176708
e+02 arcsec
3 2 Stokes Stokes 1 1 I
4 3 Spectral Frequency 300 100 1.420981e+09 1.00 -4.882812
e+03 Hz
Velocity -1.213028e+02 1.00 1.030572
e+00 km/s
T
- csys.setrestfrequency('1.41041e+09Hz',which=2,append=T);
T
- csys.restfrequency()
[value=[1.41041e+09 1.4204058e+09] , unit=Hz]
- im.setcoordsys(csys);
T
- im.summary()
Image name : g29_pre.im
Image type : PagedImage
Image quantity : Intensity
Pixel mask(s) : None
Region(s) : None
Image units : Jy/beam
Direction reference : GALACTIC
Spectral reference : TOPO
Velocity type : RADIO
Rest frequency : 1.41041e+09 [1.42041e+09] Hz
Pointing center : 29.300000 -6.500000
Telescope : GBT
Observer : UNKNOWN
Date observation : UNKNOWN
Axis Coord Type Name Proj Shape Tile Coord value at pixel Coord
incr Units
--------------------------------------------------------------------------------
----------
1 1 Direction Longitude SIN 20 10 29.300 11.00 -2.176708
e+02 arcsec
2 1 Direction Latitude SIN 152 38 -6.500 77.00 2.176708
e+02 arcsec
3 2 Stokes Stokes 1 1 I
4 3 Spectral Frequency 300 100 1.420981e+09 1.00 -4.882812
e+03 Hz
Velocity -2.246839e+03 1.00 1.037876
e+00 km/s
T
- im.view(); #use the ImageAnalysis Positions tool to view a spectrum in
#velocity - it is far offset from 0 due to the shift in
#restfrequency.
Enhancement: AOCso04231
Enhancement: AOCso04231
Enhancement: AOCso04232
Enhancement: AOCso04233
Enhancement: AOCso04232
Enhancement: AOCso04235
Enhancement: AOCso04234
This note provides brief guidelines on how multi-feed observing analysis at the GBT will be enabled particularly the multi-feed imaging case. This note compliments the PTCS Project Note 1.1 (Proposed Implementation of Multi-Beam Capability - Richard M. Prestage).
The GBT will have implemented the following additional information required for multi-feed analysis:
The Antenna FITS file will contain a static table containing the beam offsets for all beams from the receiver fiducial point, as minutes on the sky in the directions of increasing azimuth and elevation. This information will be filled into the BEAM_OFFSET column of the FEED table in the MeasurementSet (v2.0).
The BEAM_OFFSET is a direction measure containing the beam position offset on the sky in the antenna reference frame (Az/El for the GBT). The receiver configuration file would have the form:
name beamXelOffset beamElOffset SRFeed1 SRFeed2
1 -10.2 10.4 1 2
Where,
name = integer number designating the feed (if physical)
beamXelOffset = offset of the feed from the fiducial point (tracking beam)
in the cross-elevation direction, in arcminutes. The
corresponding azimuth offset applied will be:
AzOffset = Xel/cos(El)
beamElOffset = offset of the feed from the fiducial point (tracking beam)
in the elevation direction.
SRFeed1 = if non-zero, indicates that this feed is part of a sig-ref
pair and specifies which feed has been denoted the first feed.
SRFeed2 = for a sig-ref pair, indicates which feed has been designated
the second feed.
The beam offset information will be recorded in the Antenna FITS file while the sig-ref feed information will be recorded in the IF FITS file.
The following figure represents the data and interaction for the multi-beam observing currently available at the GBT. This is accurate only for the ACS (Spectrometer); the DCR and Spectral Processor write out a single FITS file (regardless of the number of IFs and FEEDs) and so will need to be treated differently within the calibration/data access routines.
The figure forks at the observing modes now available (the nomenclature is based on the PTCS Project Note 1.1 (underlined values) and their corresponding triptych of Observing Procedure:Switching State:Switching Signal). Below this is an example of the representation in the MeasurementSet of a single integration. Some key issues to be clarified are:
Yes - 1/14/03
Yes - 1/14/03
It can be setup in different ways - 1/14/03
Two key uses of the FEED information and BEAM_OFFSETS are required.
Data from feeds within a scan should be independently accessible. This will be enabled through the use of an additional argument specifier in getr,plotr,getc,plotc called nfeed. The nfeed will specify which feed to plot. The default will be the first feed in a list.
Imaging will be enabled for multi-beam data through the following routine:
az = az + BEAM_OFFSET(0,0)/cos(el)
el = el + BEAM_OFFSET(1,0)
This will be done for each feed.
Action: The non-switched track mode is not supported.
Performed using Track with electronic beam switching enabled. Supported with the current calib procedure.
Action: requires refinement to use the new FITS information.
Action: Support new NOD procedure
Action: Currently supported through calib on each scan and a getbs command. Full support utilizing the new FITS information is required.
Performed using any of the current procedures (e.g., RALongMap) with switching disabled.
Action: Support multi-beam imaging.
Performed using any of the current procedures (e.g., RALongMap) with switching enabled.
Action: For small maps (<feed separation), the above multi-feed gridding will be adequate. For larger maps, dual-beam deconvolution algorithms need to be developed.
Target: 153 beam switched calibration refinements
Target: 119.1 msconcat: works for all subtables
Target: 111.15 gbtmsfiller: Support BS data
Target: 111.16 gbtmsfiller: Support multi-beam data
Target: 153 beam switched calibration refinements
The following 3 GBT-specific columns will be added to the FEED table
for GBT data:
GBT_SRFEED_ID - the FEED_ID corresponding to the associated feed when
beam switching is in effect. This uniquely identifies the other
feed within a scan (and since the feed numbers should stay the
same throughout a procedure set, this will also be the other
feed during NODing - what changes is the BEAM_OFFSET).
GBT_FEED_NAME - from the NAME column of the ANTENNA file. This preserves
the original name since the filler will renumber things to start
from zero (and it might reorder things, although I've tried to
make that not happen).
GBT_TRCKBEAM - the name of the tracking beam. Note that the non-physical
beam information is not filled to the FEED table so if you were
tracking, for example, "MR12", you won't find information about
that beam in the MS.
In the main table, I propose adding this column for SPECTROMETER data
only.
GBT_SRFEED_BANK - the BANK where the GBT_SRFEED_ID can be found.
This will allow the calibration code to find the bank where
the data from the other beam can be found. If there is no
other beam, this will be whatever bank that data is in.
The reason this isn't in FEED is that I'm trying to avoid
any dependence on SPECTRAL_WINDOW_ID in the FEED table and
for multi-IF data, there will be different GBT_SRFEED_BANK
value - one for each IF, for the same FEED_ID>
Target: 172 Multi-beam Imaging
No Targets set.
Multi-bank observing may be considered a special case of multi-backend observing at the GBT; Each bank may be driven independently (different sampling rates, etc).
Multi-bank data is filled to separate MeasurementSets. Data access on the separate MSs can be done serially by changing the pointer to each spectrometer bank, e.g.,
- d.open('ohsurvey_SPECTROMETER_A');
- d.gms();
- d.open('ohsurvey_SPECTROMETER_B');
- d.gms();
- d.calib(34);
- d.plotc(34,1);
- d.filein('ohsurvey_SPECTROMETER_A');
- d.plotr(34,1,1);
The problem is that for some multi-IF/multi-feed modes the data from these separate MSs must be dealt with simultaneously (e.g. SFMW multi-IF mode, NOD beam switched mode). This requires either an MS concatenation procedure that will properly index and sort the data and fill it to a single MeasurementSet or a nimble calibration routine which can deduce the appropriate relationships between the different banks.
Target: 119.1 MSCONCAT works for all subtables
No targets set.
07 Jan 03
Decision: Existing MS definition of FEED table will work for GB case. The bloat issue should be mild as the BEAM_OFFSET changes should initially be per scan only. Long term, the addition of a single dish POINTING direction measure in the MAIN table should be assessed (analogous to synthesis UVW). Also explore possibility of storing function forms for offsets.
Pointing information in the header (and through sditerator) will be available only on the tracking beam. Detailed information on the pointing for each feed is only required for imaging applications which must handle this. Some convenience tool additions will be considered for enabling the pointing direction for a given feed to be provided.
Not a high priority at this time. Nominally, the effective pointing direction for cross-correlated feeds would be derived from the pointing directions of the individual feeds and the individual beam patterns.
We will be able to handle the first two cases: 1) non-beam switched multi-feed data and 2) beam switched with single and multi-feed for regions less than the switching or feed separation. Guidance should be provided (e.g. by the GBT SSR or NAUG).
The msconcat routines will be likely be delayed based on increased ALMA needs and the timing of the project reviews. Some discussion of the adaptation of the gbtmsfiller to provide this need - this would require some re-engineering of the filler as it was designed to support the on-line requirements and hence restricts filling to scans increasing in time. Given the impending take-over of the filler by GB M&C, analysis processing functions, which can handle the multiple MSs currently produced, will be adapted. Eventually, AIPS++ tools need to be able to handle multiple MSs seamlessly (there are several deferred targets to study this).
Based on decisions from several years ago, the handling of multi-bank data by the filler is a special case of multi-backend observing; essentially, the banks can be completely independent in their sampling. However, in practice, it appears that this is a generalization that is unlikely to be utilized/needed. As a result, we currently have a series of targets that will need to deal with cumbersome association of data across banks which to the observer were always intended as a single spectrum/observation. We propose making a GBT policy that the observations using the spectrometer will simply have the same sampling. This assumption will enable a simplification in the filler, which matches the user intent, and allows the spectra to be stored within a single MS. In addition, this unites the treatment of multi-if/feed modes between the Spectral Processor, DCR, and Spectrometer. There appears to be no real restriction in scientific throughput as a result of this restriction since only the sampling needs to be the same (frequencies, BWs, resolutions, etc can all be different). - Approved Phil Jewell 1/14/03
STATE table
-----------
o The information from SIG and REF is redundant; only one is
needed.
o Add information on the procedure size (OBS\_MODE\_SIZE?).
The sequence number information is obtained from SUB\_SCAN
o CAL should be a Bool to indicate whether the cal was fired
(True) or not (False). The cal temperature (TCAL) is in
the SYSCAL table.
MAIN/other tables
-----------------
o BEAM\_OFFSET is listed as a direction measure. Should be
Float(2,num receptor) with units like arcminutes.
o Add information (boolean) to MAIN or SYSCAL indicating whether
data had been calibrated or not. This is an issue for
single dish data where the CORRECTED\_DATA exists upon
filling and is altered only after calibration.
o Allow more cases with row-based measures. Currently, this is
avoided (Note 229), however many measures columns (particularly
in the SOURCE table) should allow this. Even in cases where
a constant measure reference is required for efficiency,
there needs to be some way to record what the original
reference was.
o Split column keyword/unit information into a separate column. There
are several cases where the column units or keywords should
be able to change per row but not in the current definition.
(e.g., units for CORRECTED\_DATA, frame information for
SYSVEL in SOURCE table).
o The units for the CORRECTED_DATA column need to be optionally
row-based.
