[daip] CALIB issue?

[Eric Greisen]

Bill Junor wrote:
> Hi Eric.
> 
>     Well ... it's not that I have let the times get too large ... it's 
> that this is a multi-epoch VLBA experiment over half a year so that we 
> can improve the SNR.  And my guess would be that the VLBA is going to be 
> doing more of this sort of stuff anyway.  Craig and I have similar 
> multi-epoch experiments from 2004 --- 3C120 and 3C274.
> 
>     As of last week, the NX table read was able to do the correct thing. 
> I don't believe that I have changed any of the steering parameters in a 
> substantial way but, with Real*4, it's probably not going to take much.
> 
>     Precision must be something like a part in 2^23 for IEEE so 1 in 
> 8.4*10^6 and therefore over 365 days that means "granularity" must be 
> worse than 3.8 seconds for routines to get the right timestamp.  So, I 
> should point out that not only do I have multiple epochs over 6 months, 
> I can't average the data up beyond 2 seconds to avoid time average 
> smearing in the extended structure.
> 
>     Any suggestions how to work around the problem just now?
> 
>                                        Bill
> 
> 
> 
> Eric Greisen wrote:
>> SUSAN BILL WIDER wrote:
>>> Good morning, Eric.
>>>  
>>> I'm running 31DEC08 AIPS on a multiple sub-array data set (18 
>>> sub-arrays).  After calculating solutions for the first 7 sub-arrays, 
>>> CALIB chokes in sub-array 8 when it writes the SN table ---
>>>  
>>>     Writing SN table    1
>>>     TABIO: BAD LRNO =     253 LIMIT      252
>>>     TABINDX:TABIO ERROR  2
>>>  
>>> Since CALIB seemed to work fine on this dataset as recently as 
>>> 17JUN08, I alert you to the possibility that something is broken here.
>>>  
>>> I'll check the change log later today to see if there are clues there. 
>>> I'll also experiment with earlier copies of the data.
>> Actually not I expect.
>>
>> This is an NX table read issue and it arises because you have allowed 
>> times in the data set to get very large (10's or 100's of days).  This 
>> makes comparison of times inaccurate and causes CALIB to look for an 
>> extra NX table record.  It is generally unwise to let times get so big.
>>
>> Perhaps I should work on CALIB to survive this but the issue is really 
>> very much more fundamental (Real*4 for time in days)
>

I have added code to avoid reading past the EOF of the index table.  The 
problem should not arise after tomorrow's MNJ.

Eric Greisen