You must have already applied the calibration and editing tables (CL, BP, FG) with SPLIT before you attempt to run CVEL on a single-source file. You can supply the velocity information in two ways. Either it is in the header as the alternative definition already (via SETJY and SPLIT) or you can supply it with the aparm adverb. Whatever you supply with aparm(1) to aparm(6) overides anything already in the header.
CVEL | |
inname,inclass | Input visibility file |
inseq,indisk | |
outname,outclass | Shifted visibility file |
outseq,outdisk | |
timerang =0 | Select all times |
subarray =0 | Shift all subarrays |
aparm(1)=5353E3 | Specify velocity at |
aparm(2)=256 | this channel in |
aparm(3)=0 or 1 | this reference frame and |
aparm(4)=0 or 1 | this velocity definition |
aparm(5)=1667.0E6 | Rest frequency of line |
aparm(6)=0.359E6 | |
aparm(7)=0 | |
aparm(8)=0 |
You have now produced a shifted data base. CVEL will have told you (unless you set aparm(8)=1) if it considered any of the shifts to be unduly large. You can use POSSM to check some spectra before and after the shift (if you have a strong line that is seen easily). The frequency axis will be left labelled as it originally was (otherwise you will be unable to combine it with like data with DBCON\ (see § 14). You should be aware that this frequency axis description is now meaningless, as each spectrum has been shifted relative to every other one. It is the velocity description that is now meaningful, although, as mentioned above, only a velocity axis in the radio definition is entirely self-consistent.
There is a somewhat nasty-in-principle but generally negligible-in-practice side-effect of all this shifting about of visibilities, when it comes to imaging the data. As mentioned above, the labelling of the frequency axis is now less than precise. However, it is very important that the imaging tasks know how to work out the frequency of each channel. This is because the baseline coordinates, u and v, are stored in wavelengths at the reference frequency, . When the visibilities at each channel are Fourier transformed into an image, the imaging task must be able to compute what u and v are for that channel from the reference values, and . Before CVEL is run, this is straightforward given the channel number, reference pixel, reference frequency, frequency increment, and . But after CVEL this simplicity is lost. There is no scale factor that can be applied to and (which are stored in each visibility), so that a correct u and v would be computed for each channel from the mislabelled frequency axis. This problem is not addressed by AIPS, but as shown below, it doesn't generally matter because in practice the error is usually negligible.
In one dimension, the baseline coordinate is . Let us define a true computed from the true frequency at that channel, , and a false computed from the false frequency, as given by the mislabelled header. Each visibility has been shifted by some amount, , so that . Therefore, the error you make in computing u with the wrong frequency is . Now, what really counts is whether this would cause the visibility to fall into a different (u,v) cell when you grid the visibilities ready for the FFT. The size of a grid cell is where is the image cell size in radians, and is the longest spacing. Therefore, if we confine our interest to the longest baseline where the effect is worst, , and the fractional error is
Now about the largest shift of the spectrum that you should encounter is that caused by making observations six months apart, so a shift of 30 km/s is an upper limit. This gives so that
For a maximum image size of 4096 pixels, this leads to . Thus, in general, one can ignore the error, although for very large images and a need for high dynamic range, you might start to incur a small effect.
Last update : 03/03/94
1