[daip] Fittp/Fitld impact on indxr

[Arnaud Collioud]

>> Should I put zero for these two parameters ?
> 
> NOPCAL is normally 2 although 0 at this point is okay.  NUMORB is the number of orbiting telescopes in this AN file.  I suspect that this is 0.

Ok. 

>> I did not notice this. It concerns AIRA, BADARY, HN-VLBA, HOBART26, KASHIM34, PIETOWN, SC-VLBA, WESTFORD, WETTZELL, YEBES40M. It is strange that extensively used stations like SC-VLBA, HN-VLBA or PIETOWN were not recognized. Is this due to the station name used in this session ?
>> Can the list of known stations be changed or extended easily ?
> SC and SC_VLBA are recognized but SAINCROI, STCROIX, StCroix, etc etc are not.  Computers recognize strings literally not by mental association.  The association algorithm would be to look for SC anywhere in the string but are there no stations with an SC in the name somewhere?   If correlators just make up names for the stations and change them all the time, we are not able to list them all.  I can add some more but you will note that PIETOWN is not in the pattern of all the other VLBA names - somebody is just making things up for the fun of it.

I think I will change the coordinates for the corresponding antennas directly in the AN table (using TBOUT/TBIN).

>> The INDXR error occurs precisely when using 31DEC11 FITLD. 31DEC07 INDXR runs smoothly but I have an error after that with ANTA (that is why I wanted to test the process with 31DEC11):
>> VANOIS> ANTAB1: Task ANTAB  (release of 31DEC07) begins
>> VANOIS> ANTAB1: NXREAD: INCREASE PARAMETER MAXNX
>> VANOIS> ANTAB1: Purports to die of UNNATURAL causes
>> VANOIS> ANTAB1: vanoise      31DEC07 TST: Cpu=       0.0  Real=       0
>> 
> Your INDXR problem has changed from catastrophic failure due to an illegal format to something manageable.  You need to run VLBAFIX to take care of your extreme subarray condition.  Then INDXR will work.

I thought that VLBAxxx tasks (from vlbautil) were only designed for data produced by the NRAO correlator at Socorro...but I was wrong!

The problem in this case is that I have no GC, TY or PC tables for these data, since they have been loaded into AIPS by MK4IN; so VLBAFIX does not run:
>go vlbafix
AIPS 1: TABINI: REQUESTED GC FILE   1 DOES NOT EXIST
AIPS 1: TABINI ERROR   2 OPEN FOR READ GC, TABLE  VER=  1
AIPS 1: DISK PROBLEM   CODES:       0      0

I manually ran MSORT (order TB), then USUBA, but I got the following errors:

>go usuba
 ZMSGOP: FILE DA01:MSD000000.000;      NOT FOUND
 ZTTYIO: LUN =            6  NOT OPEN IN FTAB
 ZTTYIO: LUN =            6  NOT OPEN IN FTAB
 ZMSGCL: LUN =  6 ALREADY CLOSED IN FTAB ON SEARCH
 ZMSGOP: FILE DA01:MSD000000.000;      NOT FOUND
 ZTTYIO: LUN =            6  NOT OPEN IN FTAB
 ZTTYIO: LUN =            6  NOT OPEN IN FTAB
 ZMSGCL: LUN =  6 ALREADY CLOSED IN FTAB ON SEARCH
 ZMSGOP: FILE DA01:MSD000000.000;      NOT FOUND
 ZTTYIO: LUN =            6  NOT OPEN IN FTAB
 ZTTYIO: LUN =            6  NOT OPEN IN FTAB
 ZMSGCL: LUN =  6 ALREADY CLOSED IN FTAB ON SEARCH
 ZMSGOP: FILE DA01:MSD000000.000;      NOT FOUND
 ZTTYIO: LUN =            6  NOT OPEN IN FTAB
 ZTTYIO: LUN =            6  NOT OPEN IN FTAB
 ZMSGCL: LUN =  6 ALREADY CLOSED IN FTAB ON SEARCH
AIPS 1: TASK QUIT WITHOUT RESUMING ME
AIPS 1: Begin check for any 'standard' scratch files
AIPS 1: Scratch files -- destroyed:    0  still active:    0
AIPS 1: Resumes

I suppose the file DA01:MSD000000.000; is missing ? (but it is not one of my files...)

Since all this process had been done with AIPS 31DEC07, I tried to import the data into 31DEC11. Then the INDXR error occurred...I am a bit puzzled by all this.

Regards,
Arnaud