[daip] New Ticket - [!OMT-302540]: MGMOD issues with LISTR and SNSMO

[R. Craig Walker]

New Ticket: MGMOD issues with LISTR and SNSMO

LISTR, when displaying gains, does not take MGMOD into account.  This
caused me considerable confusion.  It seems that some other program,
I'm guessing CLCAL, divides the gains by MGMOD and sets MGMOD to 1.0,
so if you look after CLCAL, you don't see a problem.  I spotted the
LISTR problem by finding gains, after gain normalization that clearly
did not average to unity - they were all above 1.0.

SNSMO also seems to treat MGMOD improperly.  I first ran it on SN 8 to
produce SN 9. At that time, SN 8 had MGMOD= 1.0561.  The resulting SN
9 had MGMOD = 1.0977.  I ran LISTR on those files, and got numbers
that did not agree with SNPLT which is what got me going on looking at
all this.  Later, after running CLCAL on both SN 8 and SN 9 (trying to
debug all this), both SN tables had MGMOD = 1.0.  I reran LISTR, and
the results were different from before, triggering the report above
about LISTR ignoring MGMOD.  Then I reran SNSMO to make SN 10.  Now
the MGMODs are all 1.0.  The resulting SN table has different results
in it than the earlier SNSMO table, even after the earlier on had the
MGMOD converted.

Perhaps to clarify, here are the same gain lines from LISTR for each
of the SN tables with the MGMOD shown:

SN   MGMOD    Time   Source  --01--02--03--04--06--07--08--09--10
 9  1.0977  18:19:04 3C279    135  99 103 109 116 115 103 101 106
 9  1.0     18:19:04 3C279    123  90  94 100 105 105  94  92  97
10  1.0     18:19:04 3C279    128  94  98 104 110 109  98  95 100

The first line is from the original SN 9 with MGMOD set.  It is
subject to the issue that LISTR is not taking MGMOD into account.

The second line is the same SN table, after MGMOD had been converted
to 1.0, probably by CLCAL.  Note the considerable difference - by
about the MGMOD.

The third line is from SN 10 which was made by SNSMO after the input
table had MGMOD converted to 1.0.  The fact that this line is not the
same as the second suggests that SNSMO is not treating MGMOD properly.

Eyeball averaging SN 8, after MGMOD was set to 1.0, demonstrates that
SN 10 has the correct values, not SN 9.  In fact, the values in SN 9
are outside the range of scatter in SN 8.

This issue has unfortunate implications for VLBI amplitude calibration
in cases were SNSMO is used after a gain-normalized CALIB.  In my
case, I was trying to use the results from a strong calibrator to
tweak the a priori calibration and wanted average results from the
calibrator.  Hopefully, this particular processing path has not been
too common, but I'm not sure.


Ticket Details
===================
Ticket ID: OMT-302540
Department: AIPS Data Processing
Priority: Default
Status: Open
Link:  https://help.nrao.edu/staff/index.php?_m=tickets&_a=viewticket&ticketid=499