[daip] TY table problem

[Jim Ulvestad]

This looks like a result of the same problem we discussed
previously, whereby the station monitor data don't report
the source change until a second or two after it actually
happens.  This causes some ambiguity in which source is
being observed at which stations at the ends of scans, and
I could see it causing something like this.

What happens if you run QUACK with option 'TAIL'?  This
won't do anything to the TY table, but it will flag the
offending data and may prevent unwanted interpolations.

jim

Craig Walker wrote:
> 
> It is possible that this is a calibration transfer issue, but I'm not
> sure who should get that.
> 
> My TY table after calibration transfer, and running VLBAPIPE which
> merges the tables, has some entries that are exact duplicates in every
> parameter except source number.  They occur at the ends of a few scans
> at a few stations.  These entries mess up APCAL and lead to SN, and
> CL tables that do not cover the end of the scan (2 entries missing
> for affected stations in a CL table with 30 second intervals.  That in turn
> causes calibration application to get messed up for the last minute of the
> scan.  I spotted the problem because I get full phase winds at
> some stations over 1 minute at the end of a couple of scans at a
> few stations after application of TECOR.  The CL table after TECOR
> does not have any entries that justify such a wind, but it does
> not have entries for the tail of the scan.  I suspect the calibration
> application is interpolating to the next scan which is in a very different
> direction on the sky.
> 
> Here is a sample PRTAB output for the offending TY table (note the entries
> at 08:03:48.5):
> 
>  eolus     PRTAB(31DEC02)   2263     26-OCT-2002  15:48:20    Page   14
>      ROW   TIME         TIME INTER   SOURCE ID   ANTENNA    SUBARRAY   FREQ ID   TSYS 1      TANT 1      TSYS 2      TANT 2
>     1165   08:00:07.5   00:02:00.0       3           4          1         1      2.260E+01     INDE      2.293E+01     INDE
>     1165                                                                         2.523E+01     INDE      2.405E+01     INDE
>     1166   08:02:11.0   00:01:53.0       3           4          1         1      2.255E+01     INDE      2.292E+01     INDE
>     1166                                                                         2.516E+01     INDE      2.407E+01     INDE
>     1167   08:03:48.5   00:01:22.0       3           4          1         1      2.250E+01     INDE      2.290E+01     INDE
>     1167                                                                         2.512E+01     INDE      2.399E+01     INDE
>     1168   08:03:48.5   00:01:22.0       1           4          1         1      2.250E+01     INDE      2.290E+01     INDE
>     1168                                                                         2.512E+01     INDE      2.399E+01     INDE
>     1169   08:06:54.5   00:01:54.0       1           4          1         1      2.335E+01     INDE      2.359E+01     INDE
>     1169                                                                         2.594E+01     INDE      2.475E+01     INDE
>     1170   08:08:51.5   00:02:00.0       1           4          1         1      2.342E+01     INDE      2.368E+01     INDE
>     1170                                                                         2.597E+01     INDE      2.476E+01     INDE
> 
> There is no apparent problem in the bw051bcal.vlba file from tsm
> (calibration data file generated for the pre-calibration transfer
> calibration scheme).  There are no duplicate entries or anything of
> the sort.
> 
> I will now either have to edit the data, or the TY table.  I think I
> will do the TY table, eliminating the values.  I have put the
> original TY table and all processing tables created by the most
> recent VLBAPIPE run (before editing) on eolus in
> >uc
> AIPS 1: Catalog on disk  2
> AIPS 1:  Cat Usid Mapname      Class   Seq  Pt     Last access      Stat
> AIPS 1:   36 2263 BW051B      .TASAV .    1 UV 26-OCT-2002 16:02:05
> 
> I have hardcopy plots of phases which show what happened.
> 
> I see two problems to address:
>   1.  The TY table shouldn't have the duplicate entries.
>   2.  The calibration application shouldn't interpolate across scan
>       boundaries to CL points deep in the scan (if that is what
>       happened).  This might best be handled by always ensuring that
>       there is are CL entries at the ends of each scan, even if they
>       have to be created by some sort of extrapolation.
> 
> 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
> ---------------------------------------------------------------------
> 
> _______________________________________________
> Daip mailing list
> Daip at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/daip