[evlatests] Pointing data, with a fine-tooth comb

[Rick Perley]

    The successful synchronization of the EVLA and VLA for pointing has 
been established.  But there were some curious failures, which I decided 
should be investigated.  The results indicate some review of our 
procedures is needed. 

    I filled the data twice, once with all the flags applied, and once 
with all the flags ignored. 

    Important issues discovered:

    1) There were three good pointing scans for which no solutions *at 
all* were made.   For all three observations, good, unflagged data are 
present for all three scans.  What happened?  In all three cases, a 
'rogue' point was recorded at the beginning.  In all cases, the rogue 
point was 30 seconds before any other data appeared, and in all cases, 
the rogue point was a high value, masquerading as an 'on peak' 
position.  The following data were good, but not in synchronism with 
this first point.  Hence, the algorithm crashed.  There were a total of 
14 sources observed, and three of them were ditched!  That's too high a 
loss.  We need to find the origin of the rogue point.  Looks like some 
vestage of a previous scan, or what? 

    2) Five good points are needed to make a solution.  Typically, we 
are on source long enough to obtain 8 or 9 good points (the extra time 
is to ensure all sources get on target).  It's clear from the solutions 
that the system starts counting when the first pair of antennas think 
they are on source.  But not all get on source together, and (see point 
#1 above), we can get odd, incorrect data on the first apparently good 
scan.  It would be a lot smarter if the algorithm used the *last* five 
good points.  We'd need some memory for this, however.  Can this be done? 

    3) A good example of why the 'last' five is better than the 'first 
five' comes from one of the scans in this database.  We were on 3C286 
for nearly 10 minutes, but only two solutions were reported for this -- 
and none included the EVLA antennas.  It turns out that:
       a) The first solution was destroyed by the 'rogue first record' 
problem. 
       b) The next two solutions had no EVLA antennas because they 
weren't there (they got on source 8 minutes late -- presumably wrapping 
around).
       c) We had in fact 2.5 minutes of good data from the EVLA 
antennas, but because the system starts counting with the first 'good' 
record, the solution boundary line lay square in the middle of the good 
EVLA data, so the good data were split between the last two solutions.  
If we were to remember the data, then count 'backwards' in blocks of 5, 
we'd have gotten good EVLA solutions, as well as more good VLA solutions. 

    4) We are getting solutions when no good data are found!  In all 
cases, it was clear that the solver has a different idea of what 
constitutes shadowing than does AIPS.  Although I filled with all flags 
off, in fact the shadow flag was still set at 'zero' shadowing -- data 
with any geometric shadowing was not filled.  In all cases were a 
pointing solution was found, but no data was filled, it was clear from 
the geometry that the antennas so solved for utilized data which in fact 
are partially shadowed.  The 'pointing shadow limit' is clearly larger 
than zero meters, but probably less than 5 meters.  I haven't gone to 
the trouble to find out what it was, but state here that we shouldn't be 
using shadowed data *(at all!)* for pointing determinations!   And we 
should remake the pointing file so that low elevation observations are 
not even tried for D configuration observations. 

    5) A curious difference was found between EVLA and VLA antenna data, 
when filling was done with flags off and on.  It's clear that the EVLA 
does *not* flag the data when the antennas are moving from raster point 
to raster point!  Why not?  The extra data doesn't appear to bother the 
pointing solver. 

    6) Does the pointing solve make use of the IF B and D data?  It 
doesn't appear to.  This is relevant here because antenna 21 still has a 
serious problem on IFs A and C, while B and D look just fine.  We had at 
least one failed solution from 21 which seems clearly due to the AC IFs 
being weak or wonky.