[evlatests] Managing collimation errors

[Barry Clark]

I was not unaware that redefining other parts of the pointing model
can change the collimation errors more than the actual change in pointing.
I was not concerned about the mere correlation effects that Craig mentions,
because we are pretty conservative about having a lot of good data before
we actually change the model parameters, and because collimations are much
better separated than for VLBA (one of the (few) benefits of over-the-top
observing).  However, if we suddenly wanted to add another parameter to
the pointing model, yes, that part of it that was previouosly absorbed in
the collimation would all change together.

> From: Craig Walker <cwalker at aoc.nrao.edu>
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040806
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> Subject: Re: [evlatests] Managing collimation errors
> 
> Actually there is a moderately likely event that can cause the 
> collimation offsets for all bands, in azimuth or elevation, to change 
> together and that Barry did not mention.  That is a change in other 
> terms in the pointing equation.  Some terms (at least on the VLBA with 
> which I'm more familiar) are highly correlated so a pointing solution 
> might give fairly large, but compensating changes in the correlated 
> terms.  The collimation offsets are correlated with other terms that 
> depend on the  sin or cosine of the elevation, for which we only have a 
> small  fraction of a turn (terms like sag, azimuth encoder offset, 
> encoder centering etc).  The risk is that when the pointing equation is 
> changed, only the collimation offsets of the band at which the solution 
> was made would be changed.  Since the correlated terms go together, 
> there could end up being large pointing errors at other bands.   If you 
> treat the collimation offsets as differentials to the band of the 
> solutions, you are protected against this behavior.  If they are 
> independent and are treated as such in pointing maintenance, you will 
> want data from all bands for your pointing solutions.
> 
> But, as Barry says, most physical effects do not affect all bands the 
> same.   Whether to use the VLA scheme of offsets or the EVLA scheme of 
> totals (which is the VLBA scheme) is a matter of choice.  Your pointing 
> analysis software can effectively switch regimes for you if set up to do 
> so.  Also note that, once far wider bandwidths are available, I wouldn't 
> be surprised if the best pointing results will be at a higher frequency 
> where the beam is smaller.  Then the offsets to X band won't make that 
> much sense.
> 
> I've gone back and forth over the years on whether I liked the VLBA 
> totals scheme or would prefer a differential scheme.  Ultimately, I 
> built differential capability into our pointing analysis software for 
> when that is appropriate and have not suggested any changes to the 
> on-line scheme.  I suspect for the EVLA you could live with either scheme.
>