[daip] strange DELAY error

[Andrew Biggs]

Hi Eric. The reason I was ending up with different numbers of CC tables is
because I was running CCEDT with up-to-date (often smaller or fewer) clean
boxes. If a facet has no clean components, CCEDT will not write a new CC
table. Also, when peeling a source, I run CCEDT on it with a very high
CUTOFF to ensure that the new CC table has no clean components. Therefore,
when I subtract all the facets, this one is not subtracted and I don't
have to run UVSUB twice i.e. it doesn't need to be added back in like in
PEELR. This saves time and seems better in terms of not doing any more to
the data than absolutely necessary.

I can be more careful from now on if the above is asking for trouble.
Before running CCEDT, I used to copy CC1 to CC2 for all facets and set
OUTVER=2 - this ensured that all facets had the same number of CC tables.

Have a good vacation.

Andy


On 12/03/2013 15:38, "Eric Greisen" <egreisen at nrao.edu> wrote:

>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