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