[daip] BLAPP behaviour

[Eric Greisen]

Arnaud Collioud wrote:
>> How do you get USUBA to work?  I ran it on your data and it converted subarray 1 into subarray 2 everywhere.
> 
> There is nothing peculiar to do: just remove the NX table and launch USUBA.
> (By looking at your next emails, I suppose that you were able to run USUBA)
> 
>> At present I am very concerned about INDXR since its output
>> seems to disagree with what is in the data after USUBA.  I
>> am looking at it....
> 
> 
>> INDXR seems fine - I was confused.  
> 
> Ok. Good.
> 
>> When I try BLAPP in my debugger it gets into an infinite loop almost immediately.  The problem is that the task assumes that the BS table has been filled in properly.  Instead, many of the error columns are pure zero.  The weights are then infinite which causes no end of trouble.
>>
>> Perhaps you should ask Walter Alef about this - he has much to do with MK4IN and may know about the BS table.  People around here have used it following BLING but were unaware of this mode
> 
> I just forwarded your email to him.
> 
> In one of my previous mail, I remarked that INDXR did not correctly indexed subarrays in the BS table. Did you also notice this during your tests?
> 
>> I am curious about your data in other ways.  Many of the data samples have u = v = w = 3140.8928 which reminds me of magic blanks (although I am not exactly sure if the value).
> 
> What is a magic blank?
> What task did you use to see that?
> Are these set by MK4IN?  
> 
> Best regards,
> Arnaud
> 

I will look a bit more to see if things look wrong in the BS table.  I 
suspect not.  USUBA corrects those times for which there are actual data 
points in subarray - say 2 - for baseline 10-21 but leaves alone those 
points for which there is not actually any data.

Magic blank is a special value we use internally for "not a number" 
other than NaN which causes some computers to die.  I used PRTUV with 
dparm(6) = 1 which lets one look at the random parameters such as u, v, 
w, baseline, source, subarray.  I assume that MK4IN sets them from the 
data being read.  I do not know if astrometric applications care about 
them however.

Eric Greisen