[daip] strange DELAY error

[Eric Greisen]

Andrew Biggs wrote:
> Hi Eric. You're right about the header being corrupted. Instead of a
> 256x256 image, it now claims to be a 1024x1024 image. In fact, the entire
> header information for this file (facet 64 - the last) has been copied
> from facet 31!
> 
> This is probably an important clue - when the data are UVSUB'd (I'm
> peeling) AIPS does it in two passes, facets 1-30 and 31-64 - presumably
> this isn't a coincidence. So, it is probably nothing to do with CCEDT.
> 
> I tried to recover the situation last night by renaming the corrupted file
> and replacing it with a copy of a previous map of facet 64. I then copied
> the CC table from the corrupted to copied file - this looks fine with
> PRTCC. When I then ran UVSUB I got the following message:

> UVSUB2  TABINI: Recovering old CC table version   3
>
> The "recovering old CC table version 3" is a bit strange and, looking this
> morning, the copied facet 64 again has the header information from facet
> 31.

This is an odd error and it means that the header in which it was 
looking only had 1 or 2 CC files while there was a CC file 3 on the disk 
with the correct name.  This causes TABINI to update the header on disk 
so this is apparently the cause of the trouble.

Whether it has the correct data is a separate question....  It could be 
a left over file from some other time.  But perhaps not - if you are 
telling UVSUB to use CC vers 3 and some files (e.g. facet 31) have only 
2 then I think UVSUB could get into this problem,  It is told not to 
read the image headers for all facets from disk for some reason.

All of this comes back down to your making many facet images with 
different numbers of CC files and wanting to use all of them.  I may be 
able to make this work some day but we cannot count on it.  This 
avoiding of reading the image header for the current facet is very 
widespread.  I am about to go on vacation for 3 weeks and so do not dare 
change things now.

Eric Greisen