[daip] TY table entries associated with wrong data set.

[Craig Walker]

I have an observation, BW088P, observed on Nov. 2, 2007 on the VLBA at 
43 GHz in which I scheduled 4 frequency bands spread across 7mm.  The 
pipelined data sets that I am using have been separated by frequency, so 
there are 4 FITS files, each at one of the observed bands.  Yes, this is 
the same data set for which I was having APCAL problems.

I have been looking fairly carefully at the TY table entries and see 
some odd points that seem like they don't belong.  Cross comparing with 
the bw088pcal.vlba file shows that the odd points belong to the previous 
scan to the one to which they are assigned.  The time of the Tsys 
measurement in the case I checked in detail was about 1 second after the 
index record stop time, which is 2 seconds before the scheduled stop 
time of scan.  So it looks like Tsys records after the IN table stop 
time, no matter how close, are being assigned to the following scan. 
When I run VLOG and ANTAB, with OFFSET=0, there is no problem (I thought 
I'd have to use an OFFSET, but didn't).

For comparisons, here are the times of one scan boundary where the 
problem occurred.  The stop is for the preceding scan (band 4), start is 
for the following scan (band 1) that got the wrong TY entry.  The Tsys 
time is the time of the mis-assigned record.  I'm not cut and pasting 
the times because I'm typing this on a different machine from where AIPS 
is being run:

SCHED:        Stop:  12:19:24   Start:  12:19:29
TSM:          Stop:  12:19:23   Start:  12:19:24
LISTR SCAN:   Stop:  12:19:22   Start:  12:19:30   IN Table.
JOB SCRIPT:   Stop:  12:19:24   Start:  12:19:24
TSM Tsys Time  12:19.383  = 12:19:23
LISTR Ts Time  12:19:23

So it looks like the IN table has a stop time that is too early (not 
sure why - I have 2 second averages.  I guess if the last record got
thrown out for being partial, plus add in half of the last full record 
to get to the record time (middle of integration, I hope), then you 
could get back 2 seconds.  It's always dangerous when the IN table is 
the mean time of the last record rather than the scan end time just 
because of trying to deal with calibration data.

Anyway, this would really screw up my calibration so I'm going to go 
with the data loaded from the TSM file.  But some sort of tolerance or 
something needs to be built into calibration transfer.

Cheers,

Craig




-- 
---------------------------------------------------------------------
     R. Craig Walker            Array Operations Center
     cwalker at nrao.edu           National Radio Astronomy Observatory
     Phone  505 835 7247        P. O. Box O
     Fax    505 835 7027        Socorro NM 87801   USA
---------------------------------------------------------------------