|
casacore
|
Modules | |
| MeasurementSets_module_internal_classes | |
| Internal MeasurementSets_module classes and functions. | |
Handle storage and access of telescope data
See below for an overview of the classes in this module.
The MeasurementSet is where all data are ultimately to be found in Casacore. Since, this is a collection of measurements (either actual or simulated), the term MeasurementSet seems appropriate. Often we use the abbreviation (and typedef) MS for MeasurementSet.
The MeasurementSets module handles storage of telescope data and access to it. The MeasurementSet is the class that gives access to the data.
A MeasurementSet (MS) is a Table with subtables stored as keywords. For each of these tables there is a separate class: the main table is MeasurementSet, the subtables are MSAntenna, MSArray, MSFeed, MSField, MSObsLog, MSObservation, MSSource, MSSpectralWindow, MSSysCal, MSWeather.
Each table has a number of predefined columns and keywords, a subset of which is required to be present. The column and keyword layout of each table is described in Note 229 and in a separate class which contains two enum definitions. The enum classes, e.g., MSMainEnums and MSAntennaEnums, just contain a PredefinedColumn (PDC) enum and a PredefinedKeyword (PDK) enum. These enum definitions are used as template arguments for the generic class MSTable<PDC,PDK> from which MeasurementSet and all the subtable classes are derived. Thus, e.g., the class MSAntenna is derived from MSTable<MSAntennaEnums::PredefinedColumns, MSAntennaEnums::PredefinedKeywords>.
The MSTable class provides a large number of common column and keyword helper functions. They are useful when creating a Table following the MeasurementSet
conventions from scratch and assist in following the agreed upon column and keyword naming conventions.
MSTable in turn is derived from Table, thus all the MS table classes are Tables. Many operations on a MeasurementSet are Table operations. See the Tables module for a list of those operations.
The reason for this class hierarchy is to provide each of the table classes with a separate namespace for its column and keyword enums, so that e.g., they can all have a column named TIME, while sharing as much code as possible. The MSTable class forwards any substantial work to the MSTableImpl class which does the actual work, it is a purely implementation class with static functions not of interest to the user.
To simplify the access of columns, and catch type errors in the column declarations for column access objects (TableColumns) at compile time, there is a helper class for each (sub)table (e.g., MSFieldColumns). The helper class for the MeasurementSet, MSColumns gives access to the main table columns and the helper objects for all subtables.
At present these classes are separate from the Table classes, mainly to ensure that the member functions are only called on valid, completely constructed MeasurementSet Tables. They also represent a large amount of 'state' in the form of TableColumn objects of which only a couple may actually be used.
Columns in the MeasurementSet and its subtables can have several keywords attached to describe the contents of the column. The UNIT keyword contains an ASCII string describing the unit of the values in the column. The unit member function (in MSTable) will return this unit string, it can be used to construct a Unit object for a particular column.
The MEASURE_TYPE keyword gives the Casacore Measure that applies to the column (if any). See the Measures module for a list of available Measures and their use.
The MEASURE_REFERENCE keyword gives (part of) the reference frame needed to interpret the values in a column. An example is J2000 for the POSITION column. A number of static functions in MeasurementSet are available to create a 'template' Measure for a column, which has the MEASURE_TYPE filled in. Currently the following functions exist: directionMeasure, positionMeasure, epochMeasure and frequencyMeasure. They return a Measure which can then be filled with a value from a particular row from the column to obtain, e.g., a proper MDirection Measure for the phase center.
Each of the MS classes has a member function referenceCopy which takes the name of a new Table and a list (Block) of column names to create a Table which references all columns in the original table, except for those listed. The listed columns are new columns which can be written to without affecting the original Table. The main use of this is for the synthesis package where corrected and model visibilities are stored as new DATA columns in an MS which references the raw MS for the other columns. Except for these special cases, the use of this function will be rare.
To accommodate both synthesis and single dish data efficiently, it was decided that a MeasurementSet can have a Complex DATA column, a float FLOAT_DATA column or both. If it has only a FLOAT_DATA column, the corresponding DATA column can be created with the makeComplexData() member function. In special cases, both columns could be present but filled for different rows, with an extra index defined indicating in which column to look (e.g., multi-feed single dish with cross correlations). The details of this last scheme are yet to be worked out. The table consistency checks (isValid()) do not require the presence of either column.
For ID columns, the rule is that a value of -1 indicates that there is no corresponding subtable in which to look up details. An example is the PULSAR_ID column, which should be set to -1 if the optional PULSAR subtable does not exist.
The rules for non integer unset values in MS tables have not settled down yet. For Floating point and Complex values the recommended practice is to set the values to the FITS and IEEE value NaN, with a bit pattern of all 1's. In much of the present filler code unused values are filled with 0 instead.
Upon destruction, the table and all subtables are checked to see that the MeasurementSet remains valid, i.e., all required columns are present. An exception is thrown if not all required columns are present Nevertheless, the table will be flushed to disk if it is writable - preserving its state.
While the class name, MeasurementSet, is descriptive, it is often too long for many common uses. The typedef MS is provided as a convenient shorthand for MeasurementSet. The example below uses this typedef.
This example illustrates creation and filling of the MeasurementSet.
This example illustrates read only access to an existing MeasurementSet and creation of an MDirection Measure for the phase center.
The attempt is to define a single, extensible, Table format that will be able to cope with all, or at least most, radio telescope data. Having a single MeasurementSet should make it easier to combine data from different instruments. The format of the MeasurementSet, table with subtables, was chosen to be able to cope with items varying at different rates more efficiently than a 'flat' Table layout would allow.
1.9.1