[daip] Re: Question about DELZN

[Leonia Kogan]

Dear Richard,

Let me explain you  what and how DELZN is doing.

Lets note that VAL_IANT -VAL_RANT are the values picked up from the SN 
table as a function of time.
It can be multi band delay phase or ....
It is always supposed that the VALs are residuals.

THE MAIN POSSIBLE ERRORS (such a geometry, initial model of the 
atmosphere and clocks and....)  ARE COMPENSATED DURING CORRELATION.
THEREFORE  WE CAN CONSIDER THE VALs INCLUDES ONLY THE EFFECT OF THE 
UNCOMPENSATED
ATMOSPHERE AND CLOCKS.

Additionally  DELZN considers that the atmosphere behaviour is described 
as the function of senith angle elevation through
the mapping function as COSEC.
The SN table VALs are the difference of  antenna ANT and reference 
antenna RANT. For simplicity lets consider that the reference antenna is 
constant during the whole experiment although DELZN can handle the case 
of  many antennas served as a reference one.

Therefore the the SN table values can be described by the following 
equation:

VAL_IANT) - VAL_RANT = ZENATM_IANT(time) *MAPFUNC(el)+ 
CLOCK_IANT(time)        (1)
                                                -ZENATM_RANT(time) 
*MAPFUNC(el)  
DELZN fits polynomials to the   ZENATM_IANT,  ZENATM_RANT    and  
CLOCK_IANT 

Actually CLOCK_IANT = CLOCK_IANT - CLOCK_RANT 

So (for example) if the third order of polynomial (a*t+b*t^2+c) is used 
for both  ZENATM_IANT and  CLOCK_IANT
then 6 (six) parameters should be fitted for each antenna. 3 for atm and 
3 for clocks
You wrote:

>  I believe there are 5 parameters to be fitted per antenna (for 3rd
>  order polynomial for tau_a) (20 for VERA)

I do not know why 5 and what is it (20 for VERA)?

I want to ephasize again that the polynomials are fitted (for each antenna including the reference one(not the reference ant clocks)) into the zenith atmosphere, and clocks as 
functions of time.
The equation 1 (this message) can help. Of cource you can still ask me a question.
Now what is plotted by DELZN?. Having received many questions about that I clarified it
 ( I hope) at the help file (APARM(1)).

I hope this message will help. For any case I repeat the most important 
statement:

THE MAIN POSSIBLE ERRORS (such a geometry, initial model of the 
atmosphere and clocks and....)  ARE COMPENSATED DURING CORRELATION.
THEREFORE  WE CAN CONSIDER THE VALs INCLUDES ONLY THE EFFECT OF THE 
UNCOMPENSATED
ATMOSPHERE AND CLOCKS.
This is true for the VLBA correlator and may not !! be true for other 
correlator


Leonid Kogan

Richard Dodson wrote:

>Hi Amy, Leonia,
>
>Thanks for your quick answer to Maria and my questions. We have more.
>
>Also I started this email last week -- so somethings have been
>answered. I hope my re-writing has not introduced any incoherency.
>
>  
>
>>In an ideal world, what you did would work fine.  The problem is that
>>128MHz will, in most cases, be too small a bandwidth to obtain an
>>accurate multiband delay.  As you see in Figure 2 of Memo 110 a narrow
>>bandwidth can easily give errors of a few nsec, which is why your
>>multiband delays are large and give you nonsensical results from DELZN.
>>
>>There is basically no way to fix your data, next time you have to
>>observe with a wider bandwidth.
>>    
>>
>
>  With the VERA setup that is not possible, or more accurately not
>easy, to implement at this time. Therefore we are still looking to
>find some way to apply the correction. You will have to be patient
>with us, as we are stretching DELZN in ways that were never imagined
>or intended.
>
>  What may be possible, or even necessary, is to introduce a short
>section to the VERA schedules with scans of multiple known
>calibrators. Currently there is a single scan of a fringe finder, then
>the dual beams track (continuously) the reference and the target
>sources.
>
>  We are pretty confident, however, that the delay values should good
>enough to support this analysis. In fact it is being done at the
>moment (by others), by exporting the data and fitting externally. What
>we are trying to find is a route which is within AIPS.
>
>  128 MHz is only a factor of 4 less than your 500 MHz. The _scatter_
>in the solutions is less than 1 nsec (typically 0.3). The solutions of
>course include clock offsets and rates, so the actual values are much
>greater than this. However, if we have managed to understand your
>memo, this can be accounted for.
>
>  However, where VERA will run into problems is the number of freedoms
>with the fitting routines. Recall that VERA has only 4 antennae, thus
>only 3 MultiBand delays.  VERA has H-masers clocks,  but my experience
>with the Mitaka correlator (with VSOP data I admit) is that they don't
>usually bother to (or need to) produce perfect clock models for the
>correlation run, so there could be considerable offsets and non-zero
>rates.
>
>  Non-zero delays are also common with the VLBA. How have you removed
>these in your analysis? Or does the multi-band delay fitting mean the
>delays in the multiband column are somehow smaller than those in the
>single band delays. Memo 110 does not make this clear (to me ;).
>
> The values for the atmosphere we derive from the MB delays are very
>silly. The depth calculated is mega-millimeters! Now some questions.
>
>- Could you show us an example of a successful Atmospheric Zenith Depth plot?
>- When you say in the help file "a polynomial of the chosen degree for
>the zenith atmosphere delay" for the fitting against Zenith. Is this
>the fit to the point by point solution? I.e. the variation of delay
>with time, or is there a polynomial mapping function you are using?
>- What might have happened to destroy the fitting algorithm?
>
> Basically I am suspicious about the numbers of parameters in the fit
>and the consequences of it.
>
> You must be fitting
>
>\Delta \tau_{ij} = \tau_{atmos_i} sec Z_i - \tau_{atmos_j} sec Z_j +
>                                    \tau_{clock_i}  - \tau_{clock_j}
>
>  Where \Delta \tau is the MBD (to reference j) and \tau_{clock} is
>the linearly varying clock and \tau_{atmos} is the polynomially (in
>time?) varying atmospheric delay. Z is the zenith angle.
>
> So plotting against elevation (fig4) is unlikely to show much unless
>one assumes that the clocks are zero, and the plot is dominated by the
>effects from one antenna?
>
>  I believe there are 5 parameters to be fitted per antenna (for 3rd
>order polynomial for tau_a) (20 for VERA). There are {the number of
>antenna less one} delays per source and solution interval (3 per sol
>interval for VERA). This makes it clear why multiple sources should be
>scheduled. Depending on how the solution interval is defined and used
>it maybe possible to find solutions for our case. One would imagine
>that if one had (say) 7 independent solution intervals over the
>experiment one would be over determined for both of these kinds of
>delay.
>
> This is what I would expect, but this is what would appear to not be happening.
>
> We will experiment with trying to merge the calibrators into one file
>-- the sources are co-observed so have common antennae and time stamps
>-- but have not done this yet.
>
>  Does this make sense? I find it hard to express clearly. But there
>is no doubt that we would prefer to use the cleaner MDEL solution as
>the phase solution is a can of worms we don't want to open. But we
>have.
>
>
>  Part 2. The Phase based corrections
>
>  
>
>>I have never used the phase so I cannot tell you how accurate it should be
>>    
>>
>Oh dear. Is there some one we can ask about these? Mark Reid perhaps?
>I am aware that these questions are beyond the usual scope.
>
>  Maria has successfully generated a DELZN solution from the CALIB
>phases, but this is (possibly) contaminated by the dual beam phase
>referencing approach used by VERA. It is important in this VERA
>check-out-phase to ensure that this is not the case. In particular we
>want to be sure that the expression used by M. Reid for the Sag A*
>analysis is that used. I.e. for the _differential_ zenith delay. They
>were using the phases from the target source to calculate both the
>atmospheric corrections and the source offset from zero. The
>differential atmosphere delay correction is a function of \tau_0
>sec(Z) tan(Z) \Delta Z. (ApJ 524 p816). This is a very similar problem
>and you suggest in memo 110 that Mark `initiated' the DELZN approach.
>Does he use DELZN for this correction? In particular Mark fitted for
>the atmosphere and the geometry at the same time.
>
>  But as far as we can tell DELZN does not fit for geometry. Is this correct?
>
> Anyway, In the phase case the clocks are definitely zero, and so do
>not need fitting for. The zenith depths calculated are a reasonable
>4cm or so. The solutions have an odd curvature tho'. I attach the
>plots of the values. Is this behaviour expected? I would have hoped
>for a constant -- or nearly constant -- value for each site.  Further
>more if one changes the order of the polynomial one would expect a
>similar result -- I.e. the zeroth order would be the mean of the
>higher order curves -- but this is not what we find.
>
>  When we tried reducing the order of the polynomial we got very
>different solutions. What is _really_ being plotted as the routine
>runs. When we limit the number of terms for the atmosphere we get very
>different ranges of values plotted (aparm(2)=1 is a few millimeters
>(the attached zen_delay_0_order.ps), aparm(2)=2 is a some millimeters,
>aparm(2)=0 is a centimeters (the attached zen_delay.ps)). However at
>all times the line goes through the data. How can this be so? Is the
>data somehow different for each fit with different numbers of
>polynomial terms.
>
>  The default solutions, however, do do a good job of correcting the
>image quality: Reduced sidelobes, larger peak. However I worry that
>this is very similar to what we would have got had one done a simple
>selfcal. How is this different from a selfcal, other than smoothing
>with a polynomial fit to the data?
>
>  Thanks for your help with these many questions,
>
>                     Richard
>
>----------------------------------------
>Richard Dodson : Marie Curie Fellow
>email : r.dodson at oan.es
>Observatorio Astronomico Nacional
>Apartado 112 E-28803 Alcala de Henares
>Phone: (+34) 91-8855060/61, 62 (fax)
>----------------------------------------
>  
>