[daip] [!7466]: AIPS - RLDLY not properly workin

[Thomas Krichbaum]

Thomas Krichbaum updated #7466
------------------------------

              Status: Open (was: Response Overdue)

RLDLY not properly workin
-------------------------

           Ticket ID: 7466
                 URL: https://help.nrao.edu/staff/index.php?/Tickets/Ticket/View/7466
           Full Name: Thomas Krichbaum
               Email: tkrichbaum at mpifr-bonn.mpg.de
             Creator: User
          Department: AIPS Data Reduction
       Staff (Owner): Eric Greisen
                Type: Issue
              Status: Open
            Priority: Default
                 SLA: NRAO E2E
      Template Group: Default
             Created: 21 October 2015 10:00 AM
             Updated: 30 October 2015 12:59 PM
                 Due: 03 November 2015 12:59 PM (4d 0h 0m)
      Resolution Due: 02 November 2015 10:09 AM (2d 21h 10m)



Hi Eric,

sorry for the late response. I appreciate the new task RLDLY, which for single subarray
and high SNR data already performs well.

However, in mm-VLBI the cross fringes are often weak and can be only detected during particular
times (not always in adjacent scans) and for small subsets of baseline combinations.
It is therefore necessary to explicitly specify the baselines to the reference antenna, namely
those which have high enough SNR (inspection via POSSM). 

In the past we used quite successfully the procedure RUN CRSFRING, which uses BLAVG to
average the cross-hand solution seen on different baselines. This procedure works very well,
under the assumption that the cross-fringes in a particular scan can be used to correct
the whole experiment (R-L delay and phase difference being constant). It would be desirable
that the new task RLDLY could replace CRSFRING. 

In global VLBI we have often subarrays, which are unavoidable. For the GMVA data sets
we have mostly 2 or 3 subarrays. It is therefore necessary that we transfer solutions
found in one particular sub-array (eg. where the strong source is) to all other subarrays.
For this I use the option subarray -32000 in CLCAL. 

Therefore it would be very desirable that RLDLY would write an SN output table always, and not only
when the program runs over many scans. The SN output table should be constructed such, that it will
not flag particular stations or IFs (see below). 

In my present experiment I have 2 subarrays, and I see cross fringes at a particular 3 min long
time intervall for PT-LA-FD.  When I set these parameters RLDLY  crashes. It produces a faulty CL table,
which has non-zero  delays in RCP, but not entry at all (even not zero) in LCP. This is the error 
message:

vlb056> RLDLY1: Task RLDLY  (release of 31DEC15) begins
vlb056> RLDLY1: UVGET: doing no flagging this time
vlb056> RLDLY1: WARNING: Input int. time (SOLINT) is greater than
vlb056> RLDLY1:          that found in the data.  Please be aware
vlb056> RLDLY1:          that this can cause odd errors.
vlb056> RLDLY1: Start subarray   1 of   2
vlb056> RLDLY1: Selecting and calibrating the data
vlb056> RLDLY1: Determining solutions
vlb056> RLDLY1: Time=   0/ 12 16 40  refant= 10
vlb056> RLDLY1: QINIT: did a GET  of      5120 Kwords, OFF        -57806348
vlb056> RLDLY1: Found       12 good solutions
vlb056> RLDLY1: Failed on       20 solutions
vlb056> RLDLY1: Average solution being applied to CL table:
vlb056> RLDLY1: RL delay IF  3     3.7733 +-   2.8936 ns; L phase   35.1 degrees
vlb056> RLDLY1: Corrected CL file from vol/cno  1    9 vers  11 to  12
vlb056> RLDLY1: Start subarray   2 of   2
vlb056> RLDLY1: Average solution being applied to CL table:
vlb056> RLDLY1: NO DATA SELECTED THIS SCAN/SUBARRAY
vlb056> RLDLY1: Purports to die of UNNATURAL causes
vlb056> RLDLY1: vlb056 31DEC15 TST: Cpu=      0.5  Real=      2  IO=       518

Obviously there is a problem in the sense that RLDLY crashes because it does not find data
in the 2nd subarray. This is due to the fact that my data set has 2 subarrays, but at this particular
time there is only data for one subarray.

This are the parameters I used
CALSOUR    ' '  *all
timer 0 12 15 0 0 12 18 0
ante 3 5 10   (FD, LA, PT)  ; other baselines do not show strong enough cross fringes
SUBARRAY 0    -> apply solution found in any subarray to all sub-arrays
docal 1
gainu 11
REFANT  10
SOLINT     3   ; to enforce a single data point within the 3min time range 
DOIFS       0 ;  want one solution per IF

My  suggestion for improvement would be:

1. always create an SN table, let the user apply it with CLCAL 
    This has the advantage that the primary output from RLDLY could be inspected
     and the user could run CLCAL with its many options. 
    It is also important that the output CL-table can have another extend than CL(N+1).
    The other advantage is that with subarray = -32000 we can copy the solution obtained
     in one sub-array to all other subarrays.
2. Introduce a SNR cutoff, which removes failed detections prior to the stacking/averaging.
    Low SNR solutions will badly affect the averaged delay or phase.
    Failed solutions would lead to the flagging of IFs, which must be avoided.

I could imagine runing RLDLY over a long time range, and on the output SN table run snsmoo
to clip outliers before averaging solutions.

best regards, Thomas


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