[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.
>

I'm following the second approach in CVEL, using APARM to set zero velocity for 
a specific rest frequency at pixel N, independent of the information in the 
header. This has always worked fine for me, but is failing on the present data. 
I'm also using the non-FFT version of CVEL, to avoid ringing; this too has 
worked fine in the past.

>
> 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.
>
>

Could the frequency-switching (i.e. using of BP tables from a different 
frequency) have something to do with it? I've certainly run CVEL recently on 
"normal" (i.e. non-frequency-switched) GMRT data for tests of detection of known 
lines and haven't noticed any problems. This was with an earlier AIPS 
version (31DEC15), though.

Thanks!
Nissim