[daip] CALIB issue?

[Bill Junor]

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)
> 
> Eric Greisen