[evlatests] Content and editing of SY files

[Rick Perley]

    My recent perusal of the SY tables provided via AIPS for the Herc A 
demo project has revealed some problems, and some potential solutions. 

    Eric has now provided the capability of having the FG (flag) files 
applied to the SY tables so that when running the editing program SNEDT, 
one does not have to view the switched power values corresponding to the 
antennas/times for which the data have already been flagged.  This is a 
great help, but unfortunately it is not sufficient. 
    When running SNEDT, even after applying the FG tables as described 
above, the switched power displayed is remarkably bad, with absurd 
values (often the mega range) in PSum and PDif being shown.  It is a 
huge effort to have to flag these tables in order to 'clean up' the 
data, prior to its smoothing and subsequent application. This begs the 
question of 'why are those bad data there at all?'. 
    It turns out that these absurd values are all identified with times 
for which there are no visibility data at all!  Not just flagged 
visibilies, but *no visibilities*.  I ask again (as I have already asked 
this once before) -- why should we have SY tables values corresponding 
to times for which there are no data? 
    I tried a simple, but laborious experiment to demonstrate this:  I 
manually flagged the X-band data for those times lying between the 
listed scans, and for time preceding the first and following the last 
scans.  The resulting SY table displayed by SNEDT (with the flagging 
option turned on) were 'clean as a whistle'!  Virtually no table editing 
was required -- hugely reducing the amount of manual effort involved in 
cleaning up the SY tables. 

    So -- if it proves to be too difficult to prevent recording SY table 
values corresponding to times outside the times for which there are 
visibility data, perhaps somebody can write a simple task which does 
automatically what I did by hand -- runs UVFLG for all times between 
scans.  (For my test of this, there were 38 scans, so had to painfully 
enter 39 * 8 = 312 integer values ... ugh!)

    Something like this is going to be needed if our users are going to 
be able to make use of these data!