[daip] calib solution intervals

[Eric Greisen]

Andy Biggs wrote:
> Hi Eric. Thanks for your email - this is clearly a very tricky issue, I 
> certainly didn't appreciate the whole complexity of the matter and I 
> won't pretend that I fully understand it.
> 
> I agree that the way it's now done is going to produce instances where 
> the last solution has a lower signal to noise than the others. But there 
> appear to be some other problems that are very confusing and which 
> manifest themselves particularly when I run CALIB with solint=0.
> 
> 1) Some scans have more than one solution. The timestamp of the second, 
> very low signal to noise, solution is always the time of the end of the 
> scan as given in the NX table. The other solution has a time close to 
> the middle of the scan, as expected.
> 
> 2) Some solutions have timestamps which place them in between scans. I 
> hadn't noticed this until now although I ran across the same problem 
> with a different dataset during the summer that you dealt with.
> 
> I have 55 scans in the MULTI source file and have 71 solutions. 13 of 
> the unexpected 16 scans are case 1 and the remaining 3 are case 2. Maybe 
> I'm doing something very stupid, but I particularly don't see how a scan 
> average can produce more than one solution per scan.
> 
You have not understood some of what I have tried to tell you about 
CALIB's end of scan difficulties and the issues of inaccurate time 
recording which are not solvable short of major political upheavals.
The new version available tomorrow should solve them (although given 
past experience it will create more problems some other way).

You are using a variety of versions of aips so it is a bit hard to even 
know how to respond to your queries - it is clear that the data were 
loaded with a by now antique version of FILLM for example (the times are 
record end times not centers)

There will be a new version of 31DEC08 and 31DEC09 CALIB tomorrow.  They 
should solve the end of scan problem.  I found on your data that the 3 
days times are sufficiently inaccurate that extending the scan 
milliseconds failed and there were in fact 2 low-noise solutions at the 
end.  The roundout I now use is 0.5*local solint.  Let's hope that never 
gets into the next scan.  I suppose that will be too much at times so I 
had better be more careful...

Problem 2 should never arise in a modern aips in which there are NX 
tables on single-source data unless the NX tables themselves identify 
the "scans" in a way that does not match your idea of what they should 
be.  You should check that (PRTAB on NX or LISTR w OPTYPE SCAN) in any 
case there problem 2 arises.

Eric Greisen