Associating a velocity with a channel

        

We are ultimately interested in knowing the velocity of each spectral channel. This has two components; the velocity of the observatory in some reference frame in the direction of the source, and the velocity of the source with respect to that frame (the redshift).

The ATCA produces channels that are equally spaced in frequency, and when imaged, are generally stored along the third axis of a cube (3-D image). In the AIPS header, such an axis would be labelled `FREQ'. If we then converted the frequencies to radio velocities, the axis would be labelled `VELO'. Note that the frequency increment can be converted to a unique velocity increment in the radio definition. However, if we converted to optical velocities, the above expression for the optical velocity indicates that the velocity increment would change along the axis because the observed frequency (rather than the rest frequency) is the denominator (see equations above). In this case, the axis is labelled `FELO', and the axis velocity increment worked out at the central observed frequency. Clearly this can give only an approximate representation of how the optical velocity changes along the axis. I leave it to the reader to work out how the error in the optical velocity varies with offset from the reference pixel (where the optical velocity is defined correctly); it can be quite substantial.

With the ATCA, on-line Doppler tracking is not used. This means that you have a well-defined sky-frequency axis with each observation, but not a well-defined velocity axis. Because of the earth's rotation, and the earth's motion about the Sun, the velocity that is correctly associated with a particular frequency channel will change with time.

If you have a single observation (12 hours say), then the velocity change at a given frequency owing to the earth's rotation is less than about 0.5 km/s (see the table above). For broad-line features generally encountered in extragalactic work, this velocity shift can be ignored (as you would have observed with a channel width much larger than this shift). However, for narrow-line Galactic sources such as masers, you may need to align the data so that each channel is correctly aligned with a specified velocity rather than frequency. Even if you are doing extragalactic work, you will definitely need to make this alignment if you are combining data taken on different dates (although I have never been on a date with a synthesis telescope) owing to the earth's orbital motion.

The procedure to align the data requires two steps as follows.

1. You should already have set the velocity scale, to first order, in the multi-source file via the SU (source) table and SETJY (see § 5). When you run SPLIT, and produce a single-source file, the velocity information in the SU table is maintained in the header of the new output file as an `alternative' definition. You can list it with IMHEAD. However, the frequency axis will be retained as the primary regular spectral axis. If at any time you want to switch the labelling of the spectral axis from frequency to velocity, you can issue the command ALTSWTCH, which toggles between the two. Note that the imaging tasks require that the spectral axis be labelled as frequency, not velocity. I suggest you restrict the use of ALTSWTCH\ to your spectral-line cube(s), rather than your visibility file(s).
2. The task CVEL is used to shift each visibility spectrum so that a designated channel becomes associated with a specific velocity. By running CVEL in the same fashion on all the files that need to be combined, they can be aligned ready for DBCON. You may also use CVEL\ on a single file to remove the small misalignents owing to the earth's rotation. CVEL is extremely CPU intensive; it Fourier transforms each visibility from the frequency domain to the lag domain, applies the necessary `phase' correction, and then Fourier transforms back again to effect the frequency shift (this is an application of the shift theorem of Fourier theory). This large computational load is another reason why you might like to time average your data before running CVEL. CVEL\ does a lot of complicated calculations to work out how much the shift should be, and these depend upon correct information being found in the antenna (AN) table (such as the antenna locations) as well as the source (SU) table. Try very hard to get it right the first time; you will tire quickly of running CVEL.

   In principle, CVEL should be able to work out for itself the velocity of the observatory at any given time in any given frame in the direction of the source of interest. By knowing the rest frequency of the spectral line, it is then possible to compute the velocity of the source in the relevant frame. However, AIPS and CVEL do not seem to be this clever. You have to tell CVEL which channel in the spectrum you would like to be associated with which source velocity. When you set up your ATCA observation, you will have worked this out because you had to set the central observing frequency to correctly deal with the source velocity (that is you applied the velocity definition equations given above). Note that MIRIAD correctly deals with velocities and the CVEL operation is done transparently by an interpolation scheme.

   CVEL works on single- and multi-source files. Unlike older versions, CVEL now (15JUK93 AIPS) reads FG tables, so that CVEL can be usefully run on multi-source files. This has two advantages. First, CVEL wants the apparent source coordinates which are stored in the SU table. These are lost in single-source files which contain only the mean coordinates. Second, you need less disk space if you stick with the multi-source file, assuming the file is dominated by the source(s) you plan to shift. For multi-source files, the FG table is applied to the data as it is read in and completely flagged visibilities are dropped from the output. Partially flagged visibilities are dealt with by setting the weight negative for the relevant channels. Therefore, there is no output FG table. Any source that is not selected for shifting is copied unshifted to the output multi-source file (but still the flags will have been applied).

   However, running CVEL on multi-source files has the following disadvantage. If you have a strong continuum, it is important that you subtract it before running CVELThis is because the cutoff in the spectrum at the edges from the large continuum value to zero will cause a ringing at the edges of the spectrum after CVEL. But, the visibility-based continuum subtraction programs are really designed for single-source files, as they have no calibration adverbs, including applying the FG table. Thus you cannot easily exclude bad channels from the designated continuum sections of the spectra.

   On balance, I would say that the error you make from having the source positions slightly wrong (J2000 coordinates as opposed to apparent coordinates) is sufficiently small that if you have strong continuum, you should generate a single-source file first (with SPLIT), do the continuum subtraction and then run CVEL on that subtracted single-source file (disk space allowing).

   Let us proceed with some of the adverbs to CVEL. Their use depends upon whether you are working on a single- or a multi-source file.

 
• Multi-source files
• Single-source files