[daip] UVGLU problem

[Eric Greisen]

Linda Watson wrote:
> Dear AIPS Help Desk,
> 
> I am using the 31DEC08 version of AIPS to process 21cm emission line data 
> from VLA.  We are using bandstitching to cover our spectral region of 
> interest using the two IFs.  We would like to combine the IFs with UVGLU 
> before continuum subtraction and imaging.
> 
> When I run UVGLU, AIPS completes the task without error.  But when I tried 
> to use UVLIN to subtract the continuum from the glued file, AIPS gave the 
> following error:
> 
> hypati> UVLIN1: Working on visibility record   150000
> hypati> UVLIN1: ZMI2: REQUEST FOR BYTES 349282305 THRU = 349480796 BEYOND 
> EOF =
> hypati>         349408256
> hypati> UVLIN1: ZMIO: OPER=READ LUN=25 BLKNO=      341097 
> 8-BIT-BYTES=198492
> hypati> UVLIN1: ZERROR: IN ZMI2 ERRNO = 22 (Invalid argument)
> hypati> UVLIN1: ZWAIT: ZWAI2 RETURNS ERROR 3 FOR LUN = 25 BUFFER = 2
> hypati> UVLIN1: ZERROR: IN ZWAI2  ERRNO = 22 (Invalid argument)
> hypati> UVLIN1: DATGET: ERROR  3 READING UV DATA
> hypati> UVLIN1: UVLIUV: ERROR  3 READING VIS FILE
> hypati> UVLIN1: Destroyed  1 extension files of type NX
> hypati> UVLIN1: Destroyed UV image file: catno=     21 disk= 1
> hypati> UVLIN1: Purports to die of UNNATURAL causes
> 
> I also tried to make an image of the glued file and tried to look at 
> it in POSSM and both of those also gave the same error.  So it seems that 
> I did something wrong in UVGLU.  The glued file perhaps is not as large as 
> AIPS expects it to be?
> 
> Do you happen to have any suggestions for what I might have done wrong? 
> I'm new to AIPS so this very well could be something simple.
> 
> Here are some basic tests that I did that might help you exclude 
> possibilities:
> 
> 1) I confirmed that I input the individual IF files in the correct order 
> so that the first file is the lower frequency IF.
> 
> 2) I have confirmed that I correctly trimmed overlapping channels between 
> the IFs so that the first channel in the higher frequency IF is 0.024 MHz 
> larger than the last channel in the lower frequency IF, where 0.024 is 
> the number of MHz/channel.
> 
> 3) I was able to image the individual IF files that I attempted to glue 
> together so they do not seem to be corrupted.
> 

UVGLU is a very simple minded program (I had to look up that it exists 
since it has been a while since I heard of it).  The 2 input files must 
match exactly in the number of records and the output file must have 
only the number of records present in each of the input files.  If you 
have used UVCOP to separate the 2 IFs, then it is possible that a fully 
flagged IF will disappear and the records will not match.

The task you actually want is called UJOIN - it allows for overlapped 
IFs, averaging the overlapped channels, and since the IFs do not need to 
be spearated, they remain matched up even if one is fully flagged.

The sort of message above arises when a task does not work right and the 
header contains a number of visibilities that is too large or that some 
other parameter (e.g. number channels) is wrong, implying a larger data 
set than is actually there.  The latter sort of error of course would be 
disastrous for reading any of the visibilities.

If you think you really need UVGLU, let me know and I will take a deeper 
look.  VBGLU, which does a similar operation for VLBI data, is a very 
difficult program indeed - much more complex than UVGLU at this time. 
But I think you are trying to do what UJOIN is all about....

Eric Greisen