[daip] [!11758]: AIPS - CALIB puts different SNR into output SN table depending in APARM(6)

[Michael Bietenholz]

Michael Bietenholz updated #11758
---------------------------------

CALIB puts different SNR into output SN table depending in APARM(6)
-------------------------------------------------------------------

           Ticket ID: 11758
                 URL: https://help.nrao.edu/staff/index.php?/Tickets/Ticket/View/11758
                Name: Michael Bietenholz
       Email address: mbieten at yorku.ca
             Creator: User
          Department: AIPS Data Reduction
       Staff (Owner): -- Unassigned --
                Type: Issue
              Status: Open
            Priority: Default
                 SLA: NRAO E2E
      Template group: Default
             Created: 09 March 2018 10:28 AM
             Updated: 09 March 2018 10:28 AM
           Reply due: 13 March 2018 10:28 AM (4d 0h 0m)
      Resolution due: 03 December 2020 12:00 AM (999d 13h 32m)

[31DEC18 AIPS updated yesterday on Ubuntu 16.04; VLBA data]CALIB produces a different SN table depending on whether APARM(6)=0 or =3.  I would have thought it should just produce an identical SN table with APARM(6)=3 but print more messages, but the SNR in the output SN tables is different.  In my case, the amp and phase gain solutions seemed to be identical, so it probably doesn't affect the output data, but it makes results harder to interpret.Here's a LISTR,OPTY=GAIN printout of an SN table made with APARM(6)=0.  Note the presence of a number of values  with SNR[scaled]=500 (ie. exactly 5.00) which seem unlikely given the other values are >10000 (sorry - column alignment seems to get munged when pasting into the ticket window).  I'm guessing (see below) that the SNR=5.00 is some kind of flag indicating closure errors.Solution SNR, 1000 =      10.0Stokes = R    IF =  1 Freq = 15.143875000 GHz   Time   Source    -----01-----02-----04-----05-----07-----08-----09 Day #   013:27:23.0 SGRA            117693    500    500         47687 14244614:29:07.0 SGRA            334927    500    500        121146 28777915:29:08.5 SGRA      22712    500 124377    500           500  9269416:29:10.0 SGRA        500    500  90437    500           500 58985317:29:12.0 SGRA        500  37507 273674    500    500    500  73031Here's CALIB run exactly the same way, but with APARM(6)=3 (same LISTR scaling factor)13:27:23.0 SGRA             59529  26567 117378         47154 14244614:29:07.0 SGRA            119715  57391 140007        117627 28777915:29:08.5 SGRA      30344 127393  89305 121082         35837 10558716:29:10.0 SGRA      22930  36051  23348  51927         85758 21277017:29:12.0 SGRA      19386  40394  41224  50993   3123  73856  40852Looking at CALIB.FOR, I note that in the case APARM(6)=0; DOFLAG=0, you get XDOFL=2,5, whereas if APARM(6)=3 you wind up with XDOFL=99, so I think its somehow treating closure errors different depending on whether APARM(6)=3 or 0.  I can of course send you the data set that produced the above results, but I think it probably is not due to a peculiarity of my data other than perhaps that there are significant closure errors in it.

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