[daip] Possible problem with FRING

[Jim Ulvestad]

I spent years lobbying for APARM(5)=2 to be removed from the
documentation, because I disagreed with the recommendation.
But I never made it very far.  Of course, I'm sure we have
other recommendations that other people disagree with!

jim

Lincoln Greenhill wrote:
> 
> Hi Amy,
> 
> We run FRING twice, once for obtain a manual phase cal and once to obtain
> a multi-band solution.  We rely on the first run to remove difference in
> slope (phs vs freq) from band to band.  I do not know what the POSSM
> plots show for any particular CL table in this case, but I wanted you to
> know that our plan is not different from the S.O.P. for the VLBA.
> 
> I'll leave the specifics to Alice w/r to whether there are anomalies
> in this particular processing.
> 
> > phase cals.  Also if you want to apply a multi-band delay after
> > that then APARM(5)=1 should probably be used since that will
> > put the multi-band delay in the part of the SN table that
> > will be applied (the single band delay column, the multi-band
> > delay column is never applied).  In other words, if you use
> > APARM(5)=2 you never actually apply a multi-band delay.  So
> > our main question is why you use APARM(5)=2?
> 
> We normally use APARM(5)=2 because historically, it seemed to give us
> better results, i.e., better solutions (less scatter). And past
> documentation has supported the use of APARM(5)=2.  It is possible that
> our thinking is swayed by our past close work with Haystack, for whose
> software and definitions the multi-band delays are nonphysical in absolute
> value.  For NRAO hardware/software, it seems to me that the possible slow
> time variation in the phase offsets between the IFs will contaminate the
> multi-band delay value but not the single band delay number.  This is
> particularly important for dual polarization observing.
> 
> Regards,
> 
> Lincoln