[daip] Fwd: BLAPP behaviour

[Arnaud Collioud]

Dear Eric,

Walter Alef made some AIPS/MK4IN debugging. I attached the emails about what he found so far. It may be helpful. 

Best regards,
Arnaud

Début du message réexpédié :

> De : Walter Alef <alef at mpifr-bonn.mpg.de>
> Date : 20 octobre 2011 15:59:49 HAEC
> À : Arnaud Collioud <Arnaud.Collioud at obs.u-bordeaux1.fr>
> Cc : David Graham <dgraham at mpifr-bonn.mpg.de>
> Objet : Rép : [daip] BLAPP behaviour
> 
> Dear Arnaud,
> 
> I looked at BLAPP and MK4IN and decided it should work. I debugged BLAPP and 
> found that it hangs when solving the rates. If I comment rate solving out it 
> runs through and ends normally. All parameters in the routine I checked are 
> fine or at least not critical. 
> I looked at the first record of the BS table and can't see anything abnormal 
> with the rates. The only peculiar thing is that the rate ambiguity varies 
> which is strange. But it varies also for the delays, and the same LAPACK 
> solving routine is used. At the moment I am stuck as I cannot debug the LAPACK 
> routines. I just can't understand them.
> 
> I will leave for holidays tomorrow so I cannot come back to this problem in 
> the next 2 weeks. Sorry! I would have expected that the LAPACK routines were 
> written to catch problems before they go into an infinite loop.
> 
> 
> Am Donnerstag 20 Oktober 2011 11:24:07 schrieb Arnaud Collioud:
>> Dear Walter,
>> 
>> Thank you for your detailed answer!
>> 
>> Le 19 oct. 2011 à 14:19, Walter Alef a écrit :
>>> Dear Arnaud,
>>> 
>>> I noticed the defective BS-table header which leads to non-matching
>>> columns. This is peculiar. MK4IN does not set that header. It is done in
>>> the AIPS subroutine BSINI. Then TABBS is used for writing. This might be
>>> an AIPS bug.
>> 
>> Yes, I had the same problem, which I solved by changing the name of the
>> appropriate columns in the header.
>> 
>>> After I had fixed the header it can't find any solutions. The problem
>>> here is most likely that the times of the baseline solutions disagree as
>>> the stations have different stop times (routine getsol). When MK4IN was
>>> written the concept of fourfit reference had not yet been invented, as
>>> far as I remember. So we took the start and stop times to determine the
>>> integration time which you can see in the BS-table. I guess that BLAPP
>>> refuses to solve if those times disagree by more than a small amount.
>>> This geodetic mode was not foreseen by us nor Chris Flatters who wrote
>>> BLAPP.
>>> 
>>> So I don't know what to do. It might be possible to get at the fourfit
>>> reftime, but I have to consult with Dave Graham who wrote this part and
>>> is retired by now.
>> 
>> Ok.
>> 
>>> And it would mean to rerun MK4IN.
>> 
>> No big deal here. It is just a matter of computing time...
>> 
>>> It might be possible to fool AIPS by modifying the BS table column No 2
>>> which is the integration time. You could make all values in that column
>>> the same, e.g. 30s. But no guarantee....
>>> 
>>> And then you have to run BLAPP for each subarray, I guess. As I said
>>> before, I do not have any experience with multi-subarray data and
>>> MK4IN/BLAPP.
>> 
>> I tried that but without success (no solution found). I will be waiting for
>> any news from you.
>> 
>> Best regards,
>> Arnaud
>>