[daip] FIXBX bug?

[Andy Biggs]

Hi Eric. I think the problem is the one you describe where boxes in 
BOXFIL are kept if there are no boxes in the new faceting scheme. I 
thought that I was removing all boxes from BOXFIL, but a look at some of 
my files shows that this wasn't always the case. This is perhaps where I 
was going wrong. However, it was always my intention to remove boxes 
from BOXFIL (having them there doesn't seem to make any sense) and I 
agree that any there should probably be ignored.

Thanks for all your help.

Andy

Eric Greisen wrote:
> Andy Biggs wrote:
>> Hi Amy. Sorry to bother you again, but I may have found a bug in 
>> FIXBX. Firstly, I should say that this is a wonderful task that's made 
>> my life a lot easier. However, after changing my faceting scheme 
>> (moving to a larger cellsize and therefore covering a larger area of 
>> the sky) and using FIXBX to re-set my clean boxes, I've found that 
>> certain fields in my map are not being cleaned by IMAGR, despite them 
>> containing sources.
>>
>> On closer examination it turns out that the output boxfile from FIXBX 
>> contained clean boxes for these fields which didn't correspond to any 
>> sources in the field. I've done some tests that show that the problem 
>> is probably occurring when FIXBX comes across a situation where, after 
>> mapping the clean boxes to the new faceting scheme, a field does not 
>> contain any 'new' clean boxes. If that field number has 'old' clean 
>> boxes from the previous faceting scheme then it leaves them in place. 
>> These naturally don't correspond to any emission in the new field 
>> resulting in IMAGR never trying to clean that field even if it 
>> contains bright sources. FIXBX should, of course, either write out no 
>> boxes for that field or write out one as large as the field itself. At 
>> least, I think this is what is going on. Otherwise, FIXBX is working 
>> perfectly.
>>
>> In some ways, this problem mimics that in CCEDT where the old clean 
>> components are left in place if the output file would contain none.
> 
> What FIXBX does at present is read in the boxes in BOXFIL.  It reads in 
> the old boxes in INFILE.  If a facet in BOXFIL receives some boxes from 
> INFIL then all old boxes are erased.  If no boxes go to a facet then the 
> old boxes specified in BOXFIL are retained.  This was really based on 
> the assumption that BOXFIL would contain no boxes or only the default 
> SETFC output circular inscribed boxes.  Thus the "old" boxes that are 
> retained are from the new faceting scheme not the old one since BOXFIL 
> should contain the new faceting scheme only.
> 
> Upon reflection, this seems inconsistent and boxes in BOXFIL should 
> probably be completely ignored although there really should be no boxes 
> other than those written by SETFC.  FIXBX would then add a default 
> circle to otherwise empty facets.
> 
> If you really believe that FIXBX is doing something else (as you suggest 
> above), please send me the 3 box files involved.
> 
> Eric Greisen

-- 

Andy Biggs
ESO, ALMA Regional Centre
Karl-Schwarzschild-Strasse 2
D-85748 Garching, Germany

tel. +49-89-32006471
fax. +49-89-32006898