[daip] Source correction with CLCOR

[Eric Greisen]

Andrew Biggs wrote:
> Hi there. I'm trying to correct the position of a phase calibrator in a
> global VLBI observation using CLCOR. The positions are:
> 
> correlated - 01:32:44.1275    43:25:32.675
> actual -     01:32:44.1268050 43:25:32.661270
> 
> The shifts are small, but I want to combine the target data with multiple
> epochs and these were observed with different phase cal positions. The
> above are the J2000 coordinates and so I've run CLCOR using:
> 
> OPCOD='ANTC'
> clcorprm(5) = -6.95e-4 * 15 * cos(43+((25+(32.675/60))/60))
> clcorprm(6) = -0.01373
> 
> 
> After running CLCOR, LISTR shows that the position is now exactly as
> requested:
> 
> 2 P0128           : 0000         01:32:44.1268  43:25:32.661  625185
> 
> 
> However, the CLCOR corrections are huge i.e. the phase wraps incredibly
> quickly thus preventing the data from being fringe fitted. I then noticed
> that when I ran CLCOR, it gave the following message:
> 
> CLCOR1 13:05:49 SOUMOD: change in Epoch    RA,DEC -7.57132E-03
> -1.37300E-02 asec
> CLCOR1 13:05:49 SOUMOD: change in Apparent RA,DEC  1.18498E+02
> 5.90945E+01 asec
> 
> The changes in the apparent RA and Dec seem to be far too large and are
> presumably the origin of my problem. Any idea why this might be? It almost
> sounds as if it isn't using an epoch of J2000. I'm using 31DEC12 that was
> midnight job'd this morning.
> 
> 
> By the way, there's a small inconsistency in the documentation. The
> explain text below the inputs describes how CLCORPRM(7) needs to be set
> although this is apparently no longer being used.

Thanks for noticing this - I will fix the explain.

What has happened is that the source table has a correct J2000 
coordinate and 0.0 for the apparent coordinates (I expect - please 
check).  Unfortunately, apparent coordinates need to be used for the 
actual correction leading to the nastiness you see.

How were these data loaded into AIPS?  I thought that we had code in 
place nearly everywhere to recompute the apparent coordinates on reading 
source tables rather than depending on the data provider (EVLA at least 
from CASA, VLBA, and ?? do not provide).  I will have to see if we can 
get this code even more places...

Eric Greisen