[daip] [!4000]: aips - SPLIT and BPASS troubles in 31DEC13

[Adam T Deller]

Adam T Deller updated #4000
---------------------------

SPLIT and BPASS troubles in 31DEC13
-----------------------------------

           Ticket ID: 4000
                 URL: https://help.nrao.edu/staff/index.php?/Tickets/Ticket/View/4000
           Full Name: Adam T Deller
               Email: deller at astron.nl
             Creator: User
          Department: AIPS Data Processing
       Staff (Owner): -- Unassigned --
                Type: Issue
              Status: Open
            Priority: Default
                 SLA: ALMA E2E
      Template Group: Default
             Created: 29 October 2013 10:45 AM
             Updated: 29 October 2013 10:45 AM
                 Due: 31 October 2013 10:45 AM (2d 0h 0m)
      Resolution Due: 06 November 2013 10:45 AM (8d 0h 0m)



Hi,

The following error is seen for 31DEC13 but not 31DEC12.  I have confirmed it on both of my machines at ASTRON and on capella at NRAO.  You can reproduce the error using the dataset at /lustre/adeller/split-killer_uv.fits.

When I run split with docal 1, gainuse 12, SOURCES    'IBC-3-0172', '' I get the following error:

SPLIT1: Task SPLIT  (release of 31DEC13) begins
SPLIT1: You are using a non-standard program
SPLIT1: Doing subarray  1
SPLIT1: UVGET: Using flag table version   1 to edit data
SPLIT1: Create IBC-3-0172  .SPLIT .   2 (UV)  on disk  1  cno    3
SPLIT1: Applying CL Table version    12
SPLIT1: TABIO: BAD LRNO=        6601 LIMIT        6600
SPLIT1: CSLGET: ERROR   2 READING CALIBRATION TABLE
SPLIT1: Destroyed  1 extension files of type NX

If I look at the CL table, indeed it does have 6600 lines.  The last entries in the CL table cover the time period 03:09:57.0  00:00:10.0, and according to the NX table the last scan relevant to the source IBC-3-0172 covers the time 03:07:18.0      00:05:18.0.  So as far as I can tell the CL table is fine, and for some reason SPLIT is trying unnecessarily to look for a next entry in the CL table which does not exist.

Probably this is a very simple fix; i hope this is enough of a start to track it down, but please let me know if you need more info.

Also, I had troubles with BPASS in 31DEC13 which I don't have in 31DEC12.  You can reproduce the problem with the same dataset; set CALSOUR    'J2148+0657','', docal 1, gainuse 9, timeran 0 01 59 53, 0 2 00 53 (none of these probably matter except the calsour), and you should see the following:

BPASS1: Task BPASS  (release of 31DEC13) begins
BPASS1: Weights in solution will be channel-dependent
BPASS1: Array name in AN table is VLBA
BPASS1: Will assume this is data from the VLBA correlator
BPASS1: and that it is all fringe-rotated to Earth Centre
BPASS1: Will remove effects of that fringe-rotation
BPASS1: to provide consistent bandpass calibration
BPASS1: If incorrect, abort and change array name keyword
BPASS1: UVGET: Using flag table version   1 to edit data
BPASS1: Selecting, editing and calibrating the data with CL vers   9
BPASS1: Dividing the spectral data by channel 0
AIPS 1: Resumes
>BPASS1: BPCOPY: copied       774 vis records for bandpass fitting
BPASS1: NOT ENOUGH FLUXES IN SU TABLE TO FIT SPECTRAL INDEX
BPASS1: Determining solutions
BPASS1: Writing BP table    2
BPASS1:  Time=   0/ 02 00 13 IFs=  1 -   4  Chann=   1 -   32 Polzn=ALL
BPASS1: QINIT: did a GET  of      5120 Kwords, OFF   17501538929161
BPASS1: BPSOL: wrote   10 records to the BP table
BPASS1: Adjusting solutions to a common reference antenna
forrtl: severe (66): output statement overflows record, unit -5, file Internal Formatted Write

The BP table itself is made and looks ok, there is just some overflow error at the stage of adjusting the phases to a reference antenna.  Weird.   Again, hopefully this is simple enough to track down.

Cheers,
Adam


------------------------------------------------------
Staff CP:  https://help.nrao.edu/staff