[daip] [!7729]: AIPS - Large phsae errors with an antenna having different total bandwidth

Mon Dec 14 11:34:52 EST 2015

Jae-Young Kim updated #7729
---------------------------

Large phsae errors with an antenna having different total bandwidth
-------------------------------------------------------------------

           Ticket ID: 7729
                 URL: https://help.nrao.edu/staff/index.php?/Tickets/Ticket/View/7729
           Full Name: Jae-Young Kim
               Email: jykim at astro.snu.ac.kr
             Creator: User
          Department: AIPS Data Reduction
       Staff (Owner): -- Unassigned --
                Type: Issue
              Status: Open
            Priority: Default
                 SLA: NRAO E2E
      Template Group: Default
             Created: 14 December 2015 04:34 PM
             Updated: 14 December 2015 04:34 PM
                 Due: 16 December 2015 04:34 PM (2d 0h 0m)
      Resolution Due: 22 December 2015 04:34 PM (8d 0h 0m)

Dear Eric Greisen,

Hello, this time I have an issue related to the phase errors caused by a station with different total bandwidth.
It seems that phase-selfcal of any visibilities in same time and frequency coverage of that station introduces large phase scatters.
In the following please let me write down the situation in detail to illustrate what the actual problem (and potential reason for this) is.

Our observation was performed with GMVA at 3mm including the following stations: GBT, VLBAx8, Effelsberg, Onsala, Pico Veleta, and PdBI.
In the above list, all stations except PdBI observed in 2Gbps dual polarization mode and only PdBI used 1Gbps recording rate.
Here frequency range of PdBI covers only first half of that of the other stations.
Therefore the actual data file (i.e. standard FITS file) consists of 16 IFs and PdBI has actual data only from IF number 1 to 8. IF from 9 to 16 was just empty for this station.

In the very beginning of the data analysis, I applied UVFRE, a newly implemented AIPS task dealing with frequency structure of a data set, whose side effect is still not very sure for me.
Anyhow for manual phase-cal we first found one delay values in US stations using GBT as reference, then connected atlantic baselines using GBT and Pico Veleta, and finally found fringe solutions among EU stations.
After a few runs of FRING we finished this.
Then we tried to find time-dependent solutions by global fringe fitting (including PdBI) and we GBT was used as first refant and also Pico Veleta was used in the Search.
For this we combined all 16 IFs to increase the SNR as we aligned all IFs in the previous steps.
The result was that all the fringe fitting worked well as far as the POSSM plots show, regardless of how reference frequency was set up internally in AIPS for this data set.
I also attach an example POSSM plot of one of many scans.

The problem happened when I SPLIT'ed our sources (with aparm1=2; keeping IFs separately) and ran phase-only selfcal using CALIB in AIPS using a 1Jy of point source.
At this stage, as I mentioned, PdBI seems to transfer some systematic phase errors to many baselines.
More specifically, many baselines at IF=1 to 8 have large phase noises and this happens only for the time during when PdBI participated in the observation.
Interestingly, the data at IF=9 to 16 are okay.
Here I also attach an example VPLOT showing the phase of a specific baseline for IF number 8 and 9.
You may find that the phase of IF=8 is systematically off from 0 and has large noise until the time 2/02, around when the last scan of PdBI was performed.

So far I tried to (1) process the same data set without UVFRE, (2) SPLIT with only IF=1 to 8 and ran CALIB to see if blank data at IF=9 to 16 for PdBI are causing some problems, and (3) use other software such as Difmap for the phase selfcal as a cross check. But none of these solved the problem.

The only apparent solution was to flag PdBI in the data and continue the rest analysis but this is of course the last thing we would try if there are no clear ways to solve this.

Therefore, I am wondering if this kind of problem is easily expected for such a data set with different frequency setup or if the problem was caused in the very early stage of the data calibration due to different frequency set up, such as different reference frequencies for PdBI due to the narrow bandwidth.
If you have any suggestions to diagnose the problem or if there is any solution, could you please let me know?

Thank you in advance for your help and best regards,
Jae-Young Kim

------------------

PS : As a feedback to the newly implemented task UVFRE, AIPS printed the following error messages when I tried ACCOR after applying UVFRE:

# VLB100> ACCOR1: Task ACCOR  (release of 31DEC15) begins
# VLB100> ACCOR1: Writing to SN table  27
# VLB100> ACCOR1: UVGET: doing no flagging this time
# VLB100> ACCOR1: ACRCOR: NO VALID AC DATA FOUND
# VLB100> ACCOR1: ACRCOR: DELETED SN VERSION   27 DUE TO ERROR
# VLB100> ACCOR1: Purports to die of UNNATURAL causes
# VLB100> ACCOR1: vlb100 31DEC15 TST: Cpu=     20.6  Real=    311  IO=     59212

Therefore I made another data set, ran ACCOR, and TACOPed output SN table to the main file.

------------------------------------------------------
Staff CP:  https://help.nrao.edu/staff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GB.KP.IF.8.9.VPLOT.PS
Type: application/postscript
Size: 70286 bytes
Desc: not available
URL: <http://listmgr.nrao.edu/pipermail/daip/attachments/20151214/464eeab6/attachment-0001.ai>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: POSSM.PV.GB.ps
Type: application/postscript
Size: 5079848 bytes
Desc: not available
URL: <http://listmgr.nrao.edu/pipermail/daip/attachments/20151214/464eeab6/attachment-0001.ps>