[evlatests] Managing collimation errors

[Barry Clark]

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.