Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1367

News	FAQ
Search	Home

Details

• The purpose of the columns and tables described here is to store information that one can expect to arrive from a telescope. Calibrated data will be the DATA column in a calibrated MS that is otherwise simply a reference to the original MS (note that the UNITs of the DATA column may therefore be different in original and calibrated MSes). Predicted data will similarly show up as a DATA column in an MS.

• There is only one subtable of each type and that is stored as a keyword of the table. This simplifies selection since it can be done on a table (e.g. SOURCE NAME is '3C84') and the keys then used to select from the main table.

• We want to keep as many columns as possible common to both Single Dish and Synthesis. Furthermore, we regard most of the columns identified here as required. It simplifies code tremendously and the Miriad storage manager avoids significant disk space usage. However, we have identified a couple of cases where following these guidelines would result in too much wasted storage and introduced some optional columns to cope with this (e.g., FLOAT_DATA for single dish).

• The model is that each ANTENNA has an unrestricted number of FEEDs. For each FEED there are some RECEPTORS, probably one per polarization state (e.g. R and L or X and Y). A number of SPECTRAL_WINDOW setups are allowed. Different setups are expected in different rows of the Main table. Thus, for example, different VLA IFs show up as different rows.

• We think that PHASED_ANTENNAS and PHASED_FEEDS table will be needed but since these are quite specialized, we have refrained from specifying contents. We think that these should be implemented first as TELESCOPE specific tables (e.g. NRAO_GBT_FEEDARRAY) and then a common format agreed upon. Such tables should probably index into the ANTENNA and FEED tables to get information.

• The SOURCE table contains information that is often not present in on-line formats, therefore we have made the use of the table optional. It could be added during later processing to organize the data by source. The FIELD table is the place to describe pointings.

• The CORRELATOR table is still unspecified. Instruments like the VLBA will require it, but at present it will usually be empty.

• The PULSAR table appears to be very telescope specific so we haven't described any format. Perhaps this possibility would provide a good impetus for the pulsar community to make common cause.

• Non-standard information may be added in various ways as per Bob Garwood's proposal:
  • As a new column in an existing table e.g. NS_NRAO_GBT_WHATEVER
  • As an e.g. NRAO-approved column NRAO_GBT_WHATEVER or NRAO_WHATEVER
  • As a Project approved column WHATEVER.

• Units and Measures. All columns representing physical quantities should be specified in the correct units, as specified in the table descriptions. Columns representing AIPS++ Measures should have a MEASURE keyword giving the AIPS++ Measure name minus the initial 'M' (e.g., DIRECTION or EPOCH) and a MEASURE_REFERENCE keyword giving the Measure enum type as a String (e.g., "J2000" or "UTC")