...
- The associated metafits file for each observation should be considered the source of truth for everything, except things that vary per coarse channel, which will be in the primary HDU of each coarse channel FITS file.
- Only the most basic information such as the obsid, projectid, time, correlator mode are repeated in the FITS Primary HDU (purely for convenience).
- The number of antenna can change on observation boundaries, so do not assume 128. The new MWAX correlator is designed to support up to 256 tiles, but will likely start at 128 and grow as next generation receivers are added to the array. E.g. the next increment might be 144T.
- Within the FITS image HDUs for visibilities, NAXIS1 represents the fine channels * polarisations * 2 (real/imaginary). NAXIS2 represents the baselines (antennas x (antennas+1))/2
- Antennae are ordered by the "antenna" value as per the ‘BINTABLE’ in the associated metafits file called ‘TILEDATA’. See MWAX Antenna Ordering for more details.
- Baselines are antenna vs antenna, not input vs input (e.g. ant0 vs ant2, not ant0x vs ant2y)
- Baselines are in lower regular triangular order. 0-0..0-n, then 1-1..1-n, then 2-2..2-n, etc.
- Coarse channel numbers (CORRCHAN) are in sky frequency ascending order
- Polarisations are in xx,xy,yx,yy order
- Real and imaginary data values are 32 bit floats
- There are significantly more correlator modes to support. Rely on FINECHAN and INT_TIME for the correct mode information from the metafits. The current working list of supported modes is shown the below figure "MWAX Correlator 256T modes" (supported modes in green; unsupported modes in red).
The number of coarse channels per observation could change (once we deploy replacement receivers, or if we allow astronomers to choose LESS than 24 course channels with the existing receivers, or if an MWAX server is offline), so do not assume 24.
Instantaneous bandwidth could change (once we deploy replacement receivers), so do not assume 30.72 MHz (24 x 1.28 MHz).
- Weights are provided in the gpubox files (after each visibility HDU containing one timestep/integration). The weights and how they are determined is discussed elsewhere (where Brian Crosse [X] (Unlicensed)?)
- Each visibility has a multiplicative weight applied, based on a data occupancy metric that takes account of any input data blocks that are missing due to lost UDP packets or RFI excision (a potential future enhancement). The centre (DC) ultrafine channel is excluded when averaging and the centre output channel values are re-scaled accordingly. Note that only 250 Hz of bandwidth is lost in this process, rather than a complete output channel.
- As part of the M&C system, the application of weights can be turned on or off per observation based on the science case/needs. With weights not applied, the data will be averaged in the correlator without taking into account the weights. Either way the weights are supplied in each alternate ImgHDU for your information.
- The MWAX correlator will provide options on a per observation to apply geometric and cable delays. When these are on, they do not need to be done by downstream tools such as Cotter or the RTS.
- Existing visibilities from the legacy/Ord correlator still need to be supported by downstream tools (e.g. Cotter / RTS).
- The MWAX FITS files contain a keyword "CORR_VER" which represents the correlator version number. If this keyword is missing, assuming this is a FITS file from the Ord/Legacy correlator. "2" is the value for the MWAX correlator.
...
Below is an example using 4 antenna (ant0, ant1, ant2, ant3) example, with 2 fine channels (0,1) and 4 polarisations (xx,xy,yx,yy) in one time step / integration (we only have time step per HDU). The ImgHDU data would like the following:
| antA | antB | ch0.xx | ch0.xy | ch0.yx | ch0.yy | ch1.xx | ch1.xy | ch1.yx | ch1.yy |
|---|---|---|---|---|---|---|---|---|---|
| 0 | 0 | r, i | r, i | r, i | r, i | r, i | r, i | r, i | r, i |
| 0 | 1 | r, i | r, i | r, i | r, i | r, i | r, i | r, i | r, i |
| 0 | 2 | r, i | r, i | r, i | r, i | r, i | r, i | r, i | r, i |
| 0 | 3 | r, i | r, i | r, i | r, i | r, i | r, i | r, i | r, i |
| 1 | 1 | r, i | r, i | r, i | r, i | r, i | r, i | r, i | r, i |
| 1 | 2 | r, i | r, i | r, i | r, i | r, i | r, i | r, i | r, i |
| 1 | 3 | r, i | r, i | r, i | r, i | r, i | r, i | r, i | r, i |
| 2 | 2 | r, i | r, i | r, i | r, i | r, i | r, i | r, i | r, i |
| 2 | 3 | r, i | r, i | r, i | r, i | r, i | r, i | r, i | r, i |
| 3 | 3 | r, i | r, i | r, i | r, i | r, i | r, i | r, i | r, i |
NOTE: RTS and cotter seem to want [time][channel][station][station][polarization][polarization][complexity], which might look something like this:
| chan | antA | antB | xx | xy | yx | yy |
|---|---|---|---|---|---|---|
| 0 | 0 | 0 | r, i | r, i | r, i | r, i |
| 0 | 0 | 1 | r, i | r, i | r, i | r, i |
| 0 | 0 | 2 | r, i | r, i | r, i | r, i |
| 0 | 0 | 3 | r, i | r, i | r, i | r, i |
| 0 | 1 | 1 | r, i | r, i | r, i | r, i |
| 0 | 1 | 2 | r, i | r, i | r, i | r, i |
| 0 | 1 | 3 | r, i | r, i | r, i | r, i |
| 0 | 2 | 2 | r, i | r, i | r, i | r, i |
| 0 | 2 | 3 | r, i | r, i | r, i | r, i |
| 0 | 3 | 3 | r, i | r, i | r, i | r, i |
| 1 | 0 | 0 | r, i | r, i | r, i | r, i |
| 1 | 0 | 1 | r, i | r, i | r, i | r, i |
| 1 | 0 | 2 | r, i | r, i | r, i | r, i |
| 1 | 0 | 3 | r, i | r, i | r, i | r, i |
| 1 | 1 | 1 | r, i | r, i | r, i | r, i |
| 1 | 1 | 2 | r, i | r, i | r, i | r, i |
| 1 | 1 | 3 | r, i | r, i | r, i | r, i |
| 1 | 2 | 2 | r, i | r, i | r, i | r, i |
| 1 | 2 | 3 | r, i | r, i | r, i | r, i |
| 1 | 3 | 3 | r, i | r, i | r, i | r, i |
FITS Extension Weights ImgHDU
...
This HDU represents the weights for one coarse channel for one time integration / time step.
| Keyword | (MWA) Valid Values | Notes |
|---|---|---|
XTENSION | IMAGE | Image Extension created by MWA DataCapture |
BITPIX | -32 | number of bits per data pixel (negative is floating point) |
NAXIS | 2 | number of array dimensions |
NAXIS1 | pols(xx,xy,yx,yy) == 4 | Polarisations |
NAXIS2 | For 128T = (128*129)/2 = 8256For 256T = (256*257)/2 = 32896 | Baselines |
PCOUNT | 0 | number of group parameters |
GCOUNT | 0 | number of groups |
COMMENT | FITS (Flexible Image Transport System) format is defined in 'Astronomy | |
COMMENT | and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H | |
TIME | e.g. 1531077040 | Unix start time of this HDU |
MILLITIM | 0-999 | Milliseconds since TIME |
MARKER | e.g. 0,1,2... n (where n is the final time step) | Data offset marker of HDU (all channels should match). The marker increments by 1 per time step |
Weights Data
Below is an example using 4 antenna (ant0, ant1, ant2, ant3) example and 4 polarisations (xx,xy,yx,yy) in one time step / integration (we only have time step per HDU). The ImgHDU data for the weights would like the following:
| weight.xx | weight.xy | weight.yx | weight.yy | |
|---|---|---|---|---|
| ant0,ant0 | w | w | w | w |
| ant0,ant1 | w | w | w | w |
| ant0,ant2 | w | w | w | w |
| ant0,ant3 | w | w | w | w |
| ant1,ant1 | w | w | w | w |
| ant1,ant2 | w | w | w | w |
| ant1,ant3 | w | w | w | w |
| ant2,ant2 | w | w | w | w |
| ant2,ant3 | w | w | w | w |
| ant3,ant3 | w | w | w | w |