[evlatests] Integer zeros slipping through?

[Rick Perley]

    A further addendum to this:

    The program which loads data into AIPS has been trained to remove 
records with integer zero values.  What I hadn't really appreciated is 
that the program only removes records for which *all* of the 
visibilities are integer zero.  This means every channel for every 
polarization for every subband.  If so much as a single visibility was 
non-integer zero, the whole record (zeros and all) was passed.   Most of 
this was quite harmless, since the zero visibilities also had zero 
weights.  It was  Eric's TYAPL problem which made the data visible. 
    So with the fix that Eric has now put in, these zero visibilities 
will again be harmless to imaging, calibration, etc. 
    But the question then moves to:  Why are they there at all?   The 
zeros are not just in the last record of a scan (as I had earlier 
reported).  My 6cm data shows long stretches of zero data for some 
subbands, in the middle of a scan.  Although these records will no 
longer harm users directly, they do represent some sort of malfunction 
upstream. 



Eric Greisen wrote:
> Rick Perley wrote:
>>     In continuing to troll through the 3C273 data taken a couple 
>> weeks back, I find a curious problem that I thought had been dealt 
>> with long ago.
>>     One some of the scans, there are what appear to be integer zeros, 
>> on some baselines.  It's hard to prove these are pure integer zeros 
>> -- I can only state for sure that these numbers are much less than 
>> 1e-20.     The unique feature of these zeros is that they are all at 
>> the end of the scans.  None in the middle, and none at the start.    
>>     I had thought that the BDFin program automatically stripped out 
>> integer zeros.  Is this no longer so?  Or perhaps my 'integer zeros' 
>> are not quite integer zero?
>>   _______________________________________________
>> evlatests mailing list
>> evlatests at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>
> The initial data set read in by BDFIn indeed has a lot of pure zeros 
> in the last time sample of some of the scans.  But they are not all 
> zero - some spectral windows appear to be populated with real values 
> while others are not.  Which spectral windows are zero and which not 
> varies with baseline.
>
> Rick's deeper problems are, however, an AIPS bug now being fixed.  The 
> output of BDFIn had weight 0 with all the pure zeros so they would not 
> affect the analysis.  Unfortunately, a relatively new option in TYAPL, 
> caused the 0.0 weights to become positive which resulted in Rick's 
> analysis being corrupted by the zeros after application of the 
> SysPower tables by TYAPL.
>
> Eric Greisen