[daip] Incomplete CL tables.

[R. Craig Walker]

It seems I was premature in my conclusion of the nature of the problem.  I
now have a CL table that is complete, but still cannot access data with
UVPRT (docalib=-1) that PRTUV finds.  VPLOT and FRING also fail to find
such data.  So now I'm lost.  I'll report back if I find the problem, but
I may abandon this sinking ship.

Cheers,

Craig



> I wasted most of my available time today trying to figure this out so I
> thought I'd bring it up.  I have a file, the result of a DBCON of two
> MULTI source data sets.  Both data sets were made from the same original
> data set, one with SPLAT, and one with SPLIT (to single source) - UVFIX -
> MULTI.  The latter file does not have a CL table.  The DBCON file has a CL
> table, but only with entries from the source that came via the single
> source file - ie not the sources that came with the SPLAT file which has a
> CL table.  The result of this odd situation is that the scans (sources)
> that do not appear in the CL table do not register at all, with no
> warnings, to programs that use the calibration capabilities, such as UVPRT
> even with DOCALIB=-1.   Programs that do not use calibration, such as
> PRTUV, see those scans.  I was going nuts trying to figure out why VPLOT
> etc would not see data that LISTR (OPTYPE='SCAN') and PRTUV could see.  I
> even ran INDXR.  It found all the scans, but it did not recreate CL table
> 1.
>
> Finally I tried deleting the NX and CL tables and and running INDXR in the
> mode to create the CL table.  There were massive numbers of complaints
> about missing IM table entries, but it ran and now I can see the scans.
> Since all previous calibrations got applied in SPLAT and SPLIT and all I
> need is the FRING SN table, I think I am now ok.
>
> In case you are wondering how I got here - it is the result of wanting all
> sources in a file on which to run FRING to give an input SN table for a
> rate based DELZN.  Unfortunately one of the sources, the one with by far
> the most data, was correlated with a 1 arcsecond offset in the position,
> so I needed to run UVFIX on it first.  But UVFIX only claims to work on
> single source data sets.  I could have tried with CLCOR, but I already
> wasted another day thanks to using a file produced by someone else where a
> CLCOR position shift had been done, and then the CL tables deleted.  The
> modified (unknown to me) SU table position was good, but the fringes were
> clearly for the offset position.  Massive confusion.
>
> Anyway, I think I now have a workaround.  I'm not sure if there is a way
> to keep others out of this trap, but thought I'd let you know about it.
>
> Cheers,
>
> Craig
>
>
>
> ---------------------------------------------------------------------
>     R. Craig Walker            Array Operations Center
>     cwalker at nrao.edu           National Radio Astronomy Observatory
>     Phone  575 835 7247        P. O. Box O
>     Fax    575 835 7027        Socorro NM 87801   USA
> --------------------------------------------------------------web
>
>


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