[daip] Re: DELZN questions

George Moellenbrock gmoellen at aoc.nrao.edu
Tue May 23 19:52:14 EDT 2006


Hi Leonia-

Thanks for your quick reply.  A few responses:

> The text file is created for using it by CLCOR ('ATMO')  The file is at the 
> format required by the 'ATMO'
> You can use the outfile to solve the 10000 rows problem repetin CLCOR several 
> time with different time rag interval

I don't understand why there needs to be many copies of what are 
essentially the same set of coefficients, each shifted to a different 
timestamp.  Surely a single set is sufficient to describe the curve over 
the whole timerange to which you want to apply it.

>> 3. A couple of suggestions:
>>
>>   a. Why not do the plots in time units, since this will make comparison
>>      with plots of the input MBDs easier?
>
> The plots are in time units (days).

I mean the y-axis, in delay units; it is currently in mm.

>>
>>   b. Why not have an option (e.g., APARM(1)=3) to create all 3 types of
>>      plots in a single run?
>
> Let me discuss tha within the AIPS group. I persannelly consider it does not 
> need
>

This isn't very important, just a convenience.  I am running DELZN 3 times 
to see all of the plots.

>>
>>   c. Why not have an option to plot the residuals corresponding to
>>      each type of current plot?
>
> Let me discuss tha within the AIPS group. I persannelly consider it does not 
> need
> At the beginnig I thought that the plots themselve are not reqired, bcause 
> the could confuse the people.
> And it happened I spent a time to explain to the people what do the plots 
> show.
> The residual can add misunderstanding

I would find examining the residuals extremely useful.  It gives you an 
idea of the rms on a per-antenna basis, and unambiguously illuminates any 
remaining un-modelled systematic variations.  If there is significant 
variation in the delay model (atm+clock), the residuals can be hard to 
discern in the current plot.

>>   e. It would be good to have a REFANT parameter that would be used
>>      to force the solution to use only input MBDs that share the specified
>>      reference antenna.  I have found that just a few MBDs with a
>>      different ref ant can yield DELZN solutions differing wildly from
>>      what you get with a consistent refant.  It took me awhile to discover
>>      that I had a few MBDs with differing refant lurking in my input
>>      SN table, and things improved tremendously when I avoided them.
>>      In any case, DELZN should complain in this case that it is using
>>      solutions with differing refants.
>
> I spent so much time to find the solution for the rare case of several 
> refant. although the uniq refant is the most jeneral case. I'll look if it s 
> simple change of the codes

Does DELZN attempt to handle the multiple-refant case already?  As far as 
I can tell, they all just go into the solve as if they had the same 
reference.  And it is likely that low-elevation scans will be the worst 
offenders here, and, since these scans tend to have larger-than-typical 
residual MBDs, the different reference introduces a substantial error.

-George




More information about the Daip mailing list