[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?

Not really - I know the general cause of the problem but not a good 
answer.  I suspect that CALIB can be defended against this but time 
really should be double precision.  A quick estimate of that cost would 
be 6 months of my time.  It is a nasty problem since the value cannot be 
guaranteed to be on an R*8 boundary in a buffer and so would have to be 
moved at each access (like I*4 in the earliest portable RANCID package)
and all sorts of places would require fixing and all UV file formats and 
probably some tables.  Not likely that your experiments justify this.
If you put the data sets as multiple subarrays the time differences 
might be less (5 days rather than 30 or more).

Eric Greisen