[daip] Scan listing problems

[Eric Greisen]

Matt Lykins wrote:
>
> 
> PROBLEM 1 - FILLM
> 
> Normally, I run FILLM twice for each day's data, once for qual 1 and 
> once for qual 2.  Then I run LISTR to list the scans that have been 
> found in each case.  However, I can also run FILLM for quals 1 & 2 
> together and run LISTR to list all scans in the data set.
> 
> * Attached file Q1.pdf is the LISTR output for qual 1 alone.  File 
> Q2.pdf is the LISTR output for qual 2 alone.  File Q1Q2.pdf is LISTR 
> output for quals 1 & 2 filled together.  All three attached files are 
> for the AT113 project observed on 13 to 14-JAN-91.
> 
> * I would expect the number of files in Q1Q2 to equal the number of 
> files in Q1 plus Q2.  Instead, Q1 contains two unexpected scans because 
> scan 49 of Q1Q2 has been divided up into three scans in Q1, namely, 
> scans 26-28.  Also, the beginning of the Timerange for a scan in Q2 is 
> often different from the beginning of the Timerange for the same scan in 
> Q1Q2.  An example is scan 25 in Q2 (beginning 04:47:30), compared to its 
> equivalent scan 52 in Q1Q2.
>
First - NX table entries are not "files" or "scans" despite LISTR's 
numbering them.  They are simply pointers into a sequential data set to 
assist AIPS in finding specific data more quickly.  When FILLM loads the 
data it knows a lot about the full data set - including for example the 
occurrence of qual 2 even when it is being ignored so the NX table from 
FILLM will reflect that knowledge.  What is knows is that some other 
source intervened, it does not know that the observations were at 
different frequencies since you told it to ignore that difference 
(otherwise they would be separate FREQIDs which you do not want).  When 
UVCOP runs, it sees the same source with no intervening source and so 
makes an NX table with one "scan" rather than 2.  It should not be a 
problem.  I do not know why FILLM broke up the one scan into 3 separate 
sub scans.  I note that there seems to be a missing 10 second record but 
perhaps the on-line integration time was 20 seconds.  It is odd that it 
would behave differently when loading all quals and when loading only 
one but it will not matter much if at all (it might affect interpolation 
of calibration and so a UVCOP would be advisable to merge them).

> Are these discrepancies worrisome?
> 
> PROBLEM 2 - UVCOP
> 
> After copying a multi-source uv data set from one AIPS disk to another 
> with UVCOP, the number of scans listed by LISTR is different.  Attached 
> file Q1_afterUVCOP.pdf shows this listing after UVCOP.  It is to be 
> compared with file Q1 (i.e. the listing before UVCOP).  Scan 7 in 
> Q1_afterUVCOP is actually a combination of scans 7 and 8 in Q1. 
>  Similarly for scans 10 and 13 in Q1_afterUVCOP, each appears to be a 
> combination of two scans in the Q1 file before UVCOP.
> 
> It appears that no visibilities have been lost.  But is are 
> discrepancies worrisome?

No see above
> 
> PROBLEM 3 - VLA ARCHIVE OBSERVATIONS SUMMARY TABLE
> 
> The VLA Archive Observations Summary Table for project AT113 shows a 
> nearly one hour time gap from 91-Jan-14 03:35:00 to 91-Jan-14 04:30:39. 
>  Yet the LISTR listing for the filled data show that observations took 
> place during this time period.  Again, is this discrepancy worrisome?
> 

I would not entirely count on the archive details for old data - be 
grateful that you got more than was advertised.  If there seems to be a 
real problem - send an e-mail to jbenson at nrao.edu.

Eric Greisen