[evlatests] Managing collimation errors

[Craig Walker]

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.

Cheers,

Craig


Barry Clark wrote:
> Apologies that many of you will get two copies of this - there is a 
> large, but not complete overlap between these lists.
> 
> The system of a priori pointing model management that has been found to 
> work best is that primary pointing parameters are determined at X band, 
> and that the pointing at other bands differs only by the band-dependent 
> collimation errors.  
> 
> For the VLA, the custom has been that collimation errors for other bands
> are relative to the X band beam.  That is, the collimations stored in
> the on-line system are the difference between the X-band beam location
> and the location of the beam at the other band.  The two are added together
> by the on-line system in the construction of the pointing model.  The
> EVLA infrastructure has been built with each band's collimations as 
> independent, absolute quantities.  This could easily be changed, or 
> superstructure can be added fairly easily, to make the EVLA work like 
> the VLA.  The question I am raising is the extent we want to do so.
> 
> Ken has just described (in messages to [evlatests]) determining the 
> offsets between the beams at various bands.  This is, I think, beyond
> doubt the best way to determine the numbers to use for the band dependent
> collimation.  So updating collimation errors involves doing pointing at
> the band in question and at X band, differencing the results, and, for 
> EVLA adding this difference to the X band collimation, and storing it 
> in the database.  (VLA just stores the difference directly in the database.)
> 
> The question comes up about what should happen if we change the collimation
> at X band.  With the current VLA software, this also changes the effective
> collimations of all the other bands.  It is not clear to me that this is 
> a reasonable thing to do.  It is the right thing to do or not, depending
> on the physical cause of the change in the X band collimation.  For 
> elevation collimation, there is a simple physical effect that changes
> all collimations together - a change in the elevation encoder coupling,
> or in the encoder itself.  I know of no physical effect that causes all
> azimuth collimations to move together.  There are simple physical causes
> that cause the X band collimation to change by itself - removing and 
> remounting the X band feed in a slightly different location is one.  There 
> are lots of effects that lead to a jumble of collimation changes, for instance
> differential tightening of the focus structure guy wires.
> 
> It is clearly a balancing act about which things one would like to accomodate
> without being explicit, but my inclination is to say that the VLA behavior
> of having all collimations change in concert with a change to the X Band
> collimation should not be emulated.
> _______________________________________________
> evlatests mailing list
> evlatests at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests


-- 
---------------------------------------------------------------------
     R. Craig Walker            Array Operations Center
     cwalker at nrao.edu           National Radio Astronomy Observatory
     Phone  505 835 7247        P. O. Box O
     Fax    505 835 7027        Socorro NM 87801   USA
---------------------------------------------------------------------