Changeset 1854 for trunk/doc/source/developer
- Timestamp:
- 08/04/10 18:28:06 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/doc/source/developer/scantable.rst
r1852 r1854 9 9 based on the data abstraction of the PKSreader API. 10 10 11 ASAP data handling works on objects called scantables. A scantable holds your 12 data, and also provides functions to operate upon it. 13 14 The building block of a scantable is an integration, which is a single row of 15 a scantable. Each row contains just one spectrum for each beam, IF and 16 polarisation. For example Parkes OH-multibeam data would normally contain 17 13 beams, 1 IF and 2 polarisations, Parkes methanol-multibeam data would 18 contain 7 beams, 2 IFs and 2 polarisations while the Mopra 8-GHz MOPS 19 filterbank will produce one beam, many IFs, and 2-4 polarisations. 20 21 All of the combinations of Beams/IFs an Polarisations are contained in separate 22 rows. These rows are grouped in cycles (same time stamp). 23 24 A collection of cycles for one source is termed a scan (and each scan has a 25 unique numeric identifier, the SCANNO). A scantable is then a collection of 26 one or more scans. If you have scan-averaged your data in time, i.e. you 27 have averaged all cycles within a scan, then each scan would hold just 28 one (averaged) integration. 29 11 30 Schema 12 31 ====== 13 32 14 33 The Scantable consist of a main (casacore) Table and several sub-tables which 15 are referenced via _id_. 34 are referenced via **ID**. The following descriptions use the following syntax 35 36 **COLUMN/KEYWORD NAME** - *DATA_TYPE(N)=DEFAULT_VALUE* 37 38 where *DEFAULT_VALUE* is optional and *(N)* indicates a Vector of that type 16 39 17 40 ---------- … … 20 43 21 44 The main table consists of global data (keywords) and row-based data (columns) 45 46 47 Keywords 48 -------- 49 50 * **VERSION** - *uInt* 51 52 the version of the scantable for compatibility tests 53 54 * **POLTYPE** - *String=linear* 55 56 the polarisation type, i.e. *stokes*, *linear* or *circular* 57 58 * **DIRECTIONREF** - *String=J2000* 59 60 the reference frame of the direction (coordinate) [redundant?!] 61 62 * **OBSMODE** - *String=""* 63 64 no idea... 65 66 * **UTC** - *String* 67 68 most likely the starting time of the observation (file) 69 70 * **AntennaName** - *String* 71 72 the name of the antenna 73 74 * **AntennaPosition** - *Double(3)* 75 76 the WGS position of the antenna 77 78 * **FluxUnit** - *String* 79 80 the unit of the channel values i.e. *Jy* or *K* 81 82 * **Observer** - *String* 83 84 the name of the observer 85 86 * **Obstype** - *String* 87 88 probably telescope specific name/encoding 89 90 * **Project** - *String* 91 92 e.g. proposal project number, survey name 93 94 * **Bandwidth** - *Double* 95 96 self-explanatory 97 98 * **nIF, nBeam, nPol, nChan** - *Int* 99 100 the number of IF, Beam, Polarisation and Channel values in the scantable 101 This is currently **FIXED** 102 103 * **FreqRefFrame** - *String* 104 105 redundant info - also in **FREQUENCIES** sub-table 106 107 * **FreqRefVal** - *Double* 108 109 no idea... 22 110 23 111 Columns … … 36 124 the channel-based system temperature values 37 125 38 * **FLAGROW** - *uInt *126 * **FLAGROW** - *uInt=-1* 39 127 40 128 spectrum based flags … … 60 148 the name of the source observered 61 149 62 * **SRCTYPE** - *Int *150 * **SRCTYPE** - *Int=-1* 63 151 64 152 the tyep of the source, i.e. indicating if it is an on source scan or … … 81 169 Imag(XY)=3 82 170 83 * **REFBEAMNO** - *Int *171 * **REFBEAMNO** - *Int=-1* 84 172 85 173 optional index of the reference beam in a multibeam obervation 86 174 87 * **FREQ_ID, MOLECULE_ID, TCAL_ID, FOCUS_ID, WEATHER_ID, FIT_ID** 88 175 * **FREQ_ID, MOLECULE_ID, TCAL_ID, FOCUS_ID, WEATHER_ID, FIT_ID** - *Int* 176 177 the reference indeces to the sub-tables 178 179 * **FIELDNAME** - *string* 180 181 the name of the field the source belongs to 182 183 * **OPACITY** - *Float* 184 185 maybe redundant - not used anywhere 186 187 * **SRCPROPERMOTION, SRCVELOCITY, SRCDIRECTION** 188 189 see livedata docs - not used in ASAP 190 191 * **SCANRATE** 192 193 see livedata docs - not used in ASAP 89 194 90 195 ---------- … … 95 200 --------- 96 201 97 blah blah 202 """""""" 203 Keywords 204 """""""" 205 206 * **BASEFRAME** - *String=TOPO* 207 * **FRAME** - *String=TOPO* 208 * **EQUINOX** - *String=J2000* 209 * **UNIT** - *String=""* 210 * **DOPPLER** - *String=RADIO* 211 212 """"""" 213 Columns 214 """"""" 215 216 * **REFPIX** - *Double* 217 218 * **REFVAL** - *Double* 219 220 * **INCREMENT** - *Double* 221 222 MOLECULES 223 --------- 224 225 """""""" 226 Keywords 227 """""""" 228 229 * **UNIT** - *String=Hz* 230 231 """"""" 232 Columns 233 """"""" 234 235 * **RESTFREQUENCY** - *Double()* 236 * **NAME** - *String()* 237 * **FORMATTEDNAME** - *String()* 98 238 99 239 … … 104 244 MS 105 245 == 246 247 MeasurementSets are specifically designed for synthesis data. As such one of the 248 main dfferences between the Scantable and a MS is how spectra are stored. 249 An MS usually stores those in an n_pol x n_channel complex matrix whereas the 250 Scantable stores each polarisation seperately. In case of polarimetry data the 251 (complex) cross-polarisation is serialised into real and imaginary parts, e.g. a 252 total of four rows would descibe one polarisation.
Note:
See TracChangeset
for help on using the changeset viewer.