[daip] [!11028]: AIPS - problem VLBI data averaging over IFs

[Gisela Ortiz]

Gisela Ortiz updated #11028
---------------------------

              Status: Open (was: Response Overdue)

problem VLBI data averaging over IFs
------------------------------------

           Ticket ID: 11028
                 URL: https://help.nrao.edu/staff/index.php?/Tickets/Ticket/View/11028
                Name: Gisela Ortiz
       Email address: g.ortiz at crya.unam.mx
             Creator: User
          Department: AIPS Data Reduction
       Staff (Owner): -- Unassigned --
                Type: Issue
              Status: Open
            Priority: Default
                 SLA: NRAO E2E
      Template group: Default
             Created: 20 September 2017 09:23 PM
             Updated: 26 September 2017 08:36 AM
           Reply due: 28 September 2017 08:36 AM (2d 0h 0m)
      Resolution due: 18 June 2020 12:00 AM (995d 15h 23m)

Hello,This is just a reminder that this ticket has not been seen yet.Quote On: 26 September 2017 08:35 AMDear AIPS analysts,We are reducing with AIPS some new VLBI data from the Event Horizon Telescope project and have found an issue related to averaging the data over frequency. Our data consist of two bands with 32 IFs each, 116 channels per IF, dual polarization. Each band has been reduced separately with no major problems during calibration, however we do not understand why amplitudes show "two branches" when they are averaged in frequency either with the task SPLIT or by setting AVGIF=1 in the task VPLOT. I attach two figures showing the output from VPLOT. In the first figure I plot amplitudes of IF=2 and IF=3, separately, where you can see that the amplitude values are pretty consistent with each other. However, if I average the two IFs (by setting AVGIF=1), I see that amplitudes get separated into two groups (branches) and do not understand why. This seems to be happening only for LL data. If I average all IFs the amplitudes look even worst (third figure). W. Alef here at the MPIfR pointed out that this could be due to a problem with too many IFs and the addressing of AIPS internal pointer to the data. In AIPS the data are internally sorted with RR usually coming first and then followed by LL. So we need 2x32 IFs. If for some reason there is a maximum number of IFs (i.e. less than 64), an overflow in the pointer could lead to some IFs being averaged and at the high end some IFs in LL remain unaveraged.In the following link, you can download a portion of the data you can inspect and use to help us to understand this issue. https://www.dropbox.com/sh/m7sybr1rt4rvuvw/AABu7iOvkv2VygfskJznabi0a?dl=0

------------------------------------------------------
Staff CP:  https://help.nrao.edu/staff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/daip/attachments/20170926/8e437157/attachment.html>