Details

• The purpose of the columns and tables described here is to store information that one can expect to arrive from a telescope. A later proposal will address how to store calibration information and predictions, but for the moment I can say that I expect calibration information also to be stored in tables attached to the MS (where appropriate). 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.
• In the original proposal, subtables were stored in columns to allow the possibility of numerous subtables. Brian suggested that it might be better to transfer the variability to each subtable. I like this and have done so in this version: 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.
• For the moment, all columns should be considered as common to both Single Dish and Synthesis. Furthermore, I think that we should regard all the columns identified here as required. It simplifies code tremendously and the Miriad storage manager avoids significant disk space usage.
• 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 FREQUENCY 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. One might want a special Storage Manager to cycle between a limited number of possibilities.
• I've added tables for information that I think we should have available in AIPS++, although as far as I know, few telescopes actually provide all of the required information. Ensuring that this information is passed on will require some pressure but having places to put such stuff will help immensely, I believe.
• I've added a OBSERVATION_LOG table that should contain whatever information is written on-line. This is just a repository for text at the moment. Eventually, though, I think that AIPS++ will generate telescope schedules and the circle will close.
• I've added tables for WEATHER, and OBSERVATION. These have been thought out to varying levels. I've taken very seriously the injunction in the Users spec not to lose information. I think that being able to plot out the weather at each antenna during a run should be a no-brainer. Similarly one should be able to get the actual schedule on-line (in the OBSERVATION table).
• I think that PHASED_ANTENNAS and PHASED_FEEDS table will be needed but since these are quite specialized, I have refrained from specifying contents. I 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 PULSAR table appears to be very telescope specific so I haven't described any format. Perhaps this possibility would provide a good impetus for the pulsar community to make common cause. Before that I suggest an NRAO_GBT_PULSAR table along the lines that Rick recommended.
• The question of what defines a MS remains. I think a possible rule is that the subtables must be the same format. Thus one could not concatenate two MSes having different specialized tables such as NRAO_VLBA_CORRELATOR and EVN_CORRELATOR.
• 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.
• Finally, it would be unrealistic to expect this memo to be unduely definitive. The details of each table are much less important than the overall philosophy and basic methods of indexing into tables. Some obviously vital tables are missing e.g. Interferometer models for VLBI correlators. I suggest that we regard the definition of such tables as a specialized endeavor to be entrusted to the relevant domain experts. Examples of unspecified tables are: ORBIT, PULSAR, BEAM, INTERFEROMETER_MODEL, FLAGGING, EPHEMERIS, PHASED_ARRAY, PHASED_FEEDS