[daip] FRING problem in NEW and TST

[Walter Alef]

Hi Eric,

This is getting more mysterious. When I switched back to TST and NEW this 
morning the problem could not be repeated anymore! On our cluster where we 
only have 31DEC10 and 31DE09 the problem is still repeatable. 

One thing I noticed is that when I changed the version to OLD, IN2NAME was 
claimed to have an illegal character in it. (It does not do that now anymore 
when I change versions.) But if a bad character was in IN2NAME why did TST 
and NEW not complain about it?
I had the same on the cluster AIPS installation. Another one I saw there was 
an IN2CLASS which needed to be reset to ''. On the cluster we have an illegal 
content of a variable occasionally even though we don't change the AIPS 
version between sessions. I don't know whether this has any relation to the 
problem. 

I could send you another file with 6 SN tables from different runs of FRING, 
some of which show good results and some the wrong ones I described. Don't 
know whether that would be on any help as long as the problem cannot be 
provoked in a reliable way. I also have the message file which shows large 
discrepancies between FFT search results and LSQ results for some IFs.

Am Mittwoch, 19. Januar 2011 schrieb Eric Greisen:
> Walter Alef wrote:
> > Hi Eric,
> >
> > We encountered a problem with FRING in the TST and NEW version. OLD is
> > not affected. We think that the problem was introduced after about summer
> > 2010. We saw this with data with single and full polarisation.
> >
> > The found the problem when we set up FRING for determining manual
> > phase-cals which means fringe fitting 2 mins of data with aparm(5)=0 and
> > dparm(8)=1 We see that the fits in the FFT step look reasonable (low
> > residuals), they close as I verified by hand, but in the LSQ step
> > occasionally extreme delays and phases show up which totally disagree
> > from the results of the FFT step. Typically some of the higher IFs of
> > some stations are affected, visible in a POSSM plot as strong phase slope
> > in the affected IFs/antennas.
> > One of the datasets for which we found this can be found under
> > ftp://ftp.mpifr-bonn.mpg.de/vlbiarchive/correlator/c101a_077.fits (is a
> > bit big I am afraid)
> >
> > I hope this is all the info you need. Otherwise please tell me what else
> > you need.
>
> I loaded your data onto my computer which runs LNX64 and on another
> computer which runs LINUX (as in Bonn).  I then ran 3 versions of FRING.
> On mine they were TST (GNU), CVX (Intel 64), and OLD (GNU).  On the
> LINUX one, they were TST (as at Bonn), my debug one (GNU), and OLD (as
> at Bonn).  To a large extent the 6 SN tables were identical.  There is
> one difference in that OLD gets an extra record due to mishandling scan
> boundaries.  The solution at that time is still quite reasonable.
>
> I have not looked at the detailed set of messages that appeared, just
> run SNPLT for 'DELA'.  Is there something I am missing?
>
> Eric Greisen



-- 

	Best regards,
			Walter 

walef at mpifr-bonn.mpg.de=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html