[daip] CLCAL disaster

Craig Walker cwalker at aoc.nrao.edu
Thu Jun 9 13:28:26 EDT 2005


I think I've run into a major CLCAL problem, although I can't believe 
this got past any testing that might have been done.  I ran CALIB on a 
multi-source data set but on only one source.  That created SN version 4 
and took a half hour on my Powerbook (64 spectral channels).  I then ran 
CLCAL to apply the solutions.  I specified SNVER=4, INVER=0.  CLCAL 
claims to have deleted SN 4 and applied SN 3.  WHY?  Indeed, there is no
longer an SN 4 associated with the data set and SN3 contains delays so 
it was clearly created by FRING, as expected.

Here are some of the CLCAL inputs:

AIPS 1: SNVER         4                    Input SN table, 0=>all.
AIPS 1: INVERS        0                    Upper SN table vers in a
AIPS 1:                                    range.  0=>SNVER
AIPS 1: GAINVER       4                    Input Cal table 0=>high
AIPS 1: GAINUSE       5                    Output CAL table 0=>high+1
AIPS 1: REFANT        4                    Reference antenna 0=>pick.
AIPS 1: BADDISK    *all 0                  Disks to avoid for scratch

Here are some of the messages written by CLCAL:

localh> CLCAL1: Processing SN table    3
localh> CLCAL1: TABINI: Deleting old SN table version   4
localh> CLCAL1: WARNING: SN table    3 has already been applied
localh> CLCAL1: Adjusting solutions to a common reference antenna =  4
localh> CLCAL1: SNMRG: Merging SN table
localh> CLCAL1: SNMRG: Write    5455 merged records from    5455 input 
records
localh> CLCAL1: SN2CL: Applying SN tables to CL table   4, writing CL 
table  5

Here are some bits from IMH after CLCAL ran:

AIPS 1: Maximum version number of extension files of type CL is   5
AIPS 1: Maximum version number of extension files of type FG is   3
AIPS 1: Maximum version number of extension files of type SN is   3


CLCAL wrote to the history file that it was processing SN version 3.

I had done an INP CLCAL just before and just after the GO CLCAL.  Both 
showed SNVER=4 as did the INP CLCAL after a TGET CLCAL.

Did CLCAL think SN 4 was a scratch merged SN table?  Why was it allowed 
to even consider deleting a previously existing SN table?

Neither Amy or Eric are here now.  I'll try a bit more testing to see 
what might have caused this.

I'm running the precompiled 31DEC05 version for MacOSX and did a 
"midnight" job yesterday.  I have version='rcwcode', but my private area 
does not have anything related to CLCAL.

Craig


-- 
---------------------------------------------------------------------
     R. Craig Walker            Array Operations Center
     cwalker at nrao.edu           National Radio Astronomy Observatory
     Phone  505 835 7247        P. O. Box O
     Fax    505 835 7027        Socorro NM 87801   USA
---------------------------------------------------------------------




More information about the Daip mailing list