[daip] Re: return of a CALIB failure (31DEC04 AIPS)

[Eric Greisen]

Daniel Lebach writes:
 > 
 > In response to:
 > >  > 
 > >  > CALIB5: WARNING: PURE BASELINE RATHER THAN ONLY ANTENNA SOLUTIONS ALLOWE
 > >  >         D
 > >  > 
 > > 
 > > What are you trying to tell me?  I added this message to warn the
 > > naive user of CALIB that he is doing a two-antenna solution.  You, as
 > > someone deliberately doing this, should mentally respond to this
 > > message by saying "good."
 > > 
 > Indeed!  I just wanted to confirm for you that I was using a version
 > of CALIB for which you enabled this capability.  I guess my use of
 > such a version was obvious -- apologies for the confusion.
 > 
 > > Was the inclusion of all the stuff that has been reflected a couple of
 > > times supposed to suggest that there are more problems?
 > >
 > I showed you our earlier exchange to help remind you of both the
 > symptoms of the problems I had back then and (I hoped) your fix.
 > There are not more problems, just the same old one that has returned
 > after it had gone away for a while... although perhaps it's now just
 > an adverb setting problem?  If so, I don't get what it is yet.

       I do not see that you have a problem.  Please tell me what your
problem is.  The message above is - for you - not a problem.  It is an
indication that you are using the CALIB that allows you to do what you
want.

 > 
 > > Did you set DOFLAG?
 > > 
 > DOFLAG is a new adverb, huh?  I saw it described as a flag for
 > closure errors (w/o reading the CALIB explain file) and promplty
 > ignored it.  I used DOFLAG = APARM(6) = 0.  I just read the CALIB
 > explain file... should DOFLAG not affect the output SN table, just
 > the FG table?  The FG table is not affected by these CALIB runs (nor
 > is a new one created).  The explain file does not make entirely
 > clear in "-1.0 < DOFLAG <= 0.0   ->  -2.5" that this is different
 > from DOFLAG=2.5 since ABS(DOFLAG) is what gets evaluated, but I
 > assume the "-2.5" is what you use for ABS(DOFLAG) so that no data
 > get flagged but "ABS(DOFLAG)=2.5" for the purpose of CALIB printout
 > to identify misclosures.

   Right.  However, setting DOFLAG=-99 might be something to try.  At
-2.5  it will mark some of the data as bad and this will change the
apparent S/N which might just flag the solutions - frankly I do not
know about the guts of that part.

 > 
 > I just tried CALIB w/ each of:
 > ANTENN 1 4 0
 > ANTENN 1 4 8 0
 > ANTENN 1 4 8 9 0
 > (DOFLAG=0 still)
 > 
 > In my quick look at the output SN table, it seems that any scans w/
 > only two sites available get bad SN solutions.  I also saw several
 > rows in the SN table for scans w/ > 2 sites that indicate one bad IF
 > out of 4 when none should be bad.  That looks to me (frankly) like a
 > CALIB bug, but really I'd have to run more tests to identify the
 > cause.  I ran FRING with basically the same adverb setttings (except
 > for DPARMs, which CALIB does not use), and the FRING output SN table
 > looked fine -- there were no phase components with "INDE" like CALIB
 > produced in multitudes.
 > 

Oh - you do have a problem - this is the first time you have mentioned
it!

Never having attempted closure phases with 2 antennas I am not sure if
they should work although you claim that they do.  I can try my new
version, the old is basically history although it could be recovered
if that is essential.  What I did was to change GCALC and friends to
be able to do robust solutions - so long as you leave SOLTYPE = ' ',
'l1', 'gcon' you will not get the robust method, just about the same
as before.  However, on the way out of GCALC it now compares the input
data to the solution and if the data are > abs(doflag)*rms from the
solution, it will mark them flagged.  The later routines that examine
closure for printing purposes and solution weights etc pay attention
to this flagging.  At 2.5*sigma you will have flagged some and so will
change things, at 99*sigma there should be no flags and no change.

Please try that.

Eric Greisen