From gmoellen@cv3.cv.nrao.edu Mon Mar  5 17:59:33 2001
Date: Mon, 5 Mar 2001 17:42:10 -0700 (MST)
From: George Moellenbrock <gmoellen@cv3.cv.nrao.edu>
To: gtaylor <gtaylor@cv3.cv.nrao.edu>
Cc: Steven T. Myers <smyers@cv3.cv.nrao.edu>,
     AIPS++ Core Testing Group <akemball@zia.aoc.NRAO.EDU>,
     dshepher@zia.aoc.NRAO.EDU, Frazer Owen <fowen@cv3.cv.nrao.edu>,
     efomalon@cv3.cv.nrao.edu, gmoellen@zia.aoc.NRAO.EDU,
     gtaylor@zia.aoc.NRAO.EDU, gvanmoor@zia.aoc.NRAO.EDU,
     jbenson@zia.aoc.NRAO.EDU, jhibbard@cv3.cv.nrao.edu,
     julvesta@zia.aoc.NRAO.EDU, tcornwel@zia.aoc.NRAO.EDU
Subject: Re: aips++ testing log of Feb 28-Mar 2


Greg, et al., 

Some comments, on Greg's points, with some general info you all might
be interested in.


> BBB: Bug AOCso02342 
> While trying to apply a calibration table just determined, calibrater
> crashes and gives the following message:
> "Server 'calibrater' has failed unexpectedly!
> You will need to create the relevant tool again.
> If that causes unexpected behavior, please restart AIPS++
> Please submit a bug-report using bug() if you can reproduce the problem.
> LocalExec::SetStatus: abnormal child termination for
> /home/cluster/aips++/weekly/linux_gnu/bin/calibrater"  
> I repeated this twice with identical behaviour.       
> 
> George told me that he encountered the same problem in 
> weekly, so I have to use stable to apply calibration.
> But the editing has to be done in weekly so some version
> hopping is necessary at the moment.
> 

This turns out to be a problem with a string field in the calibration
table, and is now in the hands of the proper authorities (Wim Brouw and
Ger van Diepen) as defect AOCso02351.  I am hopeful for a resolution
within a day or so.

> 
> (1) Some solutions in 'plotcal' are plotted where there
> are no data.  Turns out that the reference antenna has its
> times misinterpreted.  George is working on a fix.
> 

As of this week's weekly (currently available), plotcal properly labels
the time axis of the plot in HMS, and the bug you mention has disappeared.  
Note also that the weekly version of plotcal is plotting the inverse of
the Gain amplitude by default, i.e., the value which is multiplied against
the data to correct it.  It's an accident that this is occuring as default
behavior in weekly (and today's daily);  in future, the default behavior
will be to plot the Gain amplitude itself (that which is actually stored
in the table), and there will be an option to invert it.

> (2) If one IF the gains on 3C286 appear systematically
> depressed.  This must be related to the miscalculated
> flux densities.  George is looking into the causes for
> 3C286's severe depression.
> 

Plotting the inverse of the Gain amplitude reveals more obviously that
there is indeed a solution for AntennaID=26 (="4") during the 3C286 scan
in SpW=2 (R) which is an order of magnitude different from the rest.  
This is what is causing the implausible spectral indices you find in the
fluxscale() results.

My guess is that this is due either to some bad data (which, I, too, am
having trouble finding), or insufficient data in that particular solution.
I'll beat on this some more.

Cheers,
George