COMMONLY ENCOUNTERED TABLES IN AIPS

 

AIPS files generally have a number of tables associated with them which contain ancillary information about the file. In this Appendix I will describe briefly what the most common tables you will encounter are for. The AIPS command    IMHEAD\ will enable you to see which tables you have associated with a file and you can list the contents of these tables with the task     PRTAB.

inext='FQ' Select table type, FQ for example

inv=0 Highest table version

xinc=1 Print all rows

docrt=-1 List on printer

docrt=132 List on terminal, 132 char per line, must switch terminal to 132 char output too

dohms=1 HH MM SS times instead of decimal days

1.   Primarily, the antenna (AN) table keeps geometric array information such as the locations and names (e.g. CA03) of each antenna. It also contains some time (e.g. earth rotation rate and conversion from atomic to sidereal time) and polarization information (such as the polarization states of the feeds; circular or linear). This table is needed should you have to recompute the (u,v,w) coordinates in a single-source visibility file with    UVFIX, for example. All the calibration routines will access this table for its more mundane entries about antenna numbers, but in general the user does not need to worry about it. It is created by any AIPS task that reads in UV data (specifically ATLOD for ATCA data) and can be printed in a nice format with PRTAN.   
2.   The baseline (BL) table contains complex gains for each baseline necessary to correct for errors that are not antenna based (see § 3.1). These errors are assumed to consist of a multiplicative and an additive portion. We try to correct for baseline-based errors only if extremely high dynamic range is required as they are usually small. The basic calibration will not require the BL table; it is created by the task BLCAL. The desired version of the BL table is selected with the adverb blver.      
3.   The bandpass (BP) table contains the response across the band. Since the complex antenna gains are frequency dependent you need to know how they change with channel (frequency) as well as time. If you are making standard VLA continuum observations then there is only one channel and no bandpass to correct for. However, the ATCA, even when making continuum observations, produces multi-channel data so that unless you choose to average them all into one channel, you should determine the response across the band. The BP table is created by the task BPASS or the procedure ATBPASS.. The desired version of the BP table is selected with the adverb bpver.         
4.   The calibration (CL) table contains calibration information and the corrections which should be applied to the data to calibrate them. Essentially, this is where the complex gains as a function of time are stored for each source in the data base that you are interested in, whether it be a program source or a calibrator.

   You can have many versions of CL tables, and select the appropriate one with the adverb gainuse. For ATCA data, CL table 1 is a pristine copy with values appropriate to ideal gains. It is created by ATLOD. You should not delete this pristine version, but if you do, you can regenerate it with the task INDXR.

   The gains are stored in the CL table at time intervals generally of the order of minutes (although the integration time might be seconds). They are arrived at by smoothing and interpolating the gain solutions stored in the SN table with the task CLCAL or the procedure ATCLCAL.

   Note that CL tables are cumulative. This means that when you generate a new CL table, you always do it by first reading a previous version CL table (selected with adverb gainver), apply the gain solutions in the desired SN table (selected with adverb snver) to it and write out the new CL table (selected with adverb gainuse). In this way you can incrementally build up a better and better calibration which is useful for self-calibration applications (see § 17).

                       

5.   The flagging (FG) table contains information specifying which visibilities are bad so that they may be ignored. It is generated by the editing tasks (TVFLG, SPFLG, IBLED, UVFLG). The desired version of the FG table is selected with the adverb fgver.

                

6.   The frequency (FQ) table contains information about the different frequencies and bandwidths in the multi-source file for different sources. It is possible in this way for the multi-source data base to contain multi-frequency and multi-bandwidth data. For ATCA data, the FQ table is generated by ATLOD. It cannot be rebuilt without rerunning ATLOD if you delete it (although if you are careful, you could copy it from a like file with TACOP).

      Each different group of simultaneously observed frequencies (such as the two simultaneous IFs you get with the ATCA) is designated by an integer number (the FREQID). Each FREQID has one logical row in the FQ table. For each simultaneous frequency (IF) contributing to the FREQID, the logical row has an offset in Hz from the reference frequency in the header, a channel width, a total bandwidth and a sideband indicator. Thus, the logical row is multi-dimensional; there are as may actual rows in the logical row as there are simultaneous frequencies (IFs).

   If you observed, say, at 3 cm (IF 1) and 6 cm (IF 2), and then changed to 13 cm (IF 1) and 20 cm (IF 2), you would get two FREQIDs in the FQ table. The first would describe the 3/6 combination, the second the 13/20 combination.

   You select the desired FREQID in the FQ table with the adverb freqid.

   For tortuous historical reasons, the channel width is now a signed quantity, and the sideband indicator is now always written as +1. The true sideband indicator is written to the screen when you load your data with the task ATLOD. It is also written into the history file if you forget it. It varies from band to band.  

   Occasionally you may come across CH tables. These are old deprecated versions of the FQ table. The FQ table is created by ATLOD. Do not delete it or you will have to make a new one with ATLOD.        

7.   The index (NX) table indexes the multi-source data base for rapid access by containing information about scan boundaries such as times and visibility number ranges. It is created by ATLOD or INDXR. If deleted, it can be regenerated with INDXR. There is only one version of the NX table and you should not need to concern yourself with it.   
8.   The solution (SN) table contains the complex gain solutions determined from the calibrator sources. It is generated by the tasks CALIB or KALIB and the procedure ATCALIB. The values in the SN table are interpolated to the times where you have observed your program source. YOu select the desired version of the SN table with the adverb snver.            
9.   The source (SU) table contains source specific information such as flux densities, positions, and calibration codes. This table is built by ATLOD. It cannot be regenerated by any other task so don't delete it. Each source in the multi-source visibility file is given a number which is an index to the SU table entry. There is only one version of the SU table. Do not delete it.

Last update : 27/11/93

1