[daip] Problems with CVEL on WSRT and GMRT data.

[Nissim Kanekar]

Dear Eric,

>>
>>  I've recently come across some strange problems when using CVEL in
>>  31DEC16 andd 31DEC17 on GMRT and WSRT data. The data were taken with
>>  simple in-band frequency-switching, where a single IF band (of
>>  bandwidth=5 MHz or 6.25 MHz) is used and the line is kept within the
>>  band by shifting the band centre frequency by 2 MHz and then back to the
>>  original value every 5 minutes. We then run BPASS separately on the
>>  original data set and the frequency-shifted data set, and copy the BP
>>  tables from the original data set to the frequency-shifted data set, and
>>  vice versa. And finally run CVEL on the two single-source SPLIT files to
>>  shift each to the LSR frame before obtaining the absorption spectrum by
>>  averaging the visibilities in POSSM (the target sources are phase
>>  calibrators). The procedure has worked fine in the past (we used this
>>  for both GMRT and WSRT data in 2006-2011) but we find a velocity offset
>>  between the spectra obtained from the original and frequency-switched
>>  data sets after CVEL. The velocity offset between the spectra is
>>  different for different sources and is seen in both WSRT and GMRT data.
>>  I've also checked the header of the GMRT data and compared it to the old
>>  GMRT data (where CVEL used to work fine) and find that the headers look
>>  the same. Further, I ran dopset to work out what the velocity shift to
>>  the LSR frame should be (ignoring the 0.5 km/s due to earth rotation)
>>  and find that the shift computed by CVEL appears close to correct for
>>  the original data set but is wrong (by a few km/s in some cases) for the
>>  frequency-switched data set. I'm actually not sure whether the problem
>>  here is due to the frequency-switching or just something in CVEL on
>>  single-source files; the only place where frequency-switching has been
>>  done is applying the frequency-switched bandpass table and I wouldn't
>>  have thought that this should have an effect on the frequency axis. I
>>  was wondering whether you might have some idea as to what might be going
>>  on.
>
> Look closely at the IMHEADER for the 2 data sets.  There needs to be line 
> rest frequency and a velocity and pixel number for the alternate reference 
> value.  They should be approximately correct before CVEL in both cases - so 
> the alt ref pixel will be different for the two.
>
> Alternatively, you can tell CVEL in APARM the velocity you would like at 
> pixel n in the output aparm = v, n, 0, 1, restf1, restf2
> where you need to give all parameters of aparm independent of what is in the 
> header.  If you want to bring the shifted and unshifted so that the line is 
> in a specific channel this is what you need to do.
>
> Perhaps what is ending up in the headers these days is a bit different than 
> it used to be.  CVEL has not changed substantially in a long time.
>

I had also noticed that there was a bug in CVEL upto 31DEC08, related to 
applying CVEL to single-source SPLIT files with an NX table. The GMRT and WSRT 
files are exactly of this category, but my impression was that this bug had been 
fixed. Could there still be a residual problem?

Thanks,
Nissim