[daip] Re: something more aboutabout DELZN

[Leonia Kogan]

I forgot to tell something more:

It is desirable to have the calibrators with different coordinates. 
Otherwise it will be difficult to doscriminate
Zenith atmosphere and clock errors.

LK


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)
>----------------------------------------
>  
>