[daip] AIPS problems with tasks LPCAL and CCEDT

[Eric Greisen]

On 3/9/20 2:33 PM, Felix Poetzl via Daip wrote:
> Hello,
> 
> I am using the AIPS installation (31DEC20) at the MPIfR in Bonn and 
> since last week I have a problem with the AIPS task LPCAL. It gives an 
> error message when running it with "in2ver=2" and "ncomp = X 0" where X 
> is any number of CC tables that were previously produced by CCEDT. In 
> CCEDT, it does not matter if boxes are used or if automatic model 
> splitting is enabled. The error message in LPCAL states:
> 
> VLB108> LPCAL1: vlb108 31DEC20 TST: Cpu=      0.0  Real=      0 
> IO=         8
> VLB108> LPCAL1: Task LPCAL  (release of 31DEC20) begins
> VLB108> LPCAL1: Processing IF number    1
> VLB108> LPCAL1: UVGET: doing no flagging this time
> VLB108> LPCAL1: Sub-model   1:   1641+399     . ICLN   .   1 CCVER =   3
> VLB108> LPCAL1: Using Clean Component source model
> VLB108> LPCAL1: FACSET: 0.476291 Jy found from 160 components
> VLB108> LPCAL1: VISDFT: Begin DFT component subtraction
> VLB108> LPCAL1: VISDFT: fields 1 - 1 chns 1 - 1 in 1 CC models
> VLB108> LPCAL1: VISDFT: Model components of type Point
> VLB108> LPCAL1: QINIT: did a GET  of      5120 Kwords, OFF 17494967365643
> VLB108> LPCAL1: TABIO: BAD LRNO=         125 LIMIT         124
> VLB108> LPCAL1: TABCCM: TABIO ERROR  2
> VLB108> LPCAL1: VISDFT: ERROR    2 READING CLEAN COMPS REC  126
> VLB108> LPCAL1: Purports to die of UNNATURAL causes
> 
> After closer inspection, while having LPCAL run on each produced CC 
> table separately, it seems to work on some, but not all of them. I could 
> not really identify a pattern so far, but I think there might be a 
> tendency for odd CC table numbers to not work.
> When I looked at those tables using astropy, I noticed that the CC 
> tables produced by CCEDT have an additional line in their header at the 
> very bottom: ISORTORD=                -257
> Deleting this line, exporting the file, and reading it again into AIPS 
> does not do the trick, however, so I assume this is normal.
> 
> I tried this for 3 different datasets, so it has most likely nothing to 
> do with my data.
> 
> Any help on this issue would be greatly appreciated.
> 
> Best regards,
> Felix Pötzl
> 

I don't have a way to test LPCAL (I think).  I have added code to VISDFT
to prevent reading past the end of file.  I did test VISDFT extensively
when I changed from primitive IO (TABINI/TABIO) to the modern 
CCMINI/TABCCM.  The MNJ on Monday morning in Bonn should update your 
versions.  I cannot see how the code has changed to cause this.

Eric Greisen

BTW: The NRAO has closed all its office doors.  We are to try to work 
from home starting Monday.  That will be curious with AIPS support.