[evla-sw-discuss] Some thoughts about pointing

[Barry Clark]

Pointing pattern.

We currently use a five point pattern - on source, approximately
half power in plus/minus azimuth/elevation.  Although various
alternatives have been discussed over the years, none has
attracted much enthusiasm.  I suggest this pattern be hard
coded.  It would make things a bit more flexible and robust,
though, to send along the offsets in arcminutes, rather than
relying on doing the same calculation in the Executor and in
Telcal, as the current system does.

Basebands and subbands.

I am inclined to think that we should do pointing with a single
subband.  I think that doing more costs more due to more exposure
to interference and other problems than is gained by better SNR.
I suggest a compiled in table showing what subband to use as a
function of observing band.  There might be a way to change that,
either through an intent or via the telcal console, but I regard
this as a safety measure rather than something that would be used
in practice.

Handling solutions.

The current pointing solver expects to start with a given subscan
and uses it and the next four.  I suggest it is slightly more
elegant and robust to have a cache for each subscan type, and
after stuffing current results after each subscan, going through
for each antenna and seeing if a successful pointing reduction
can be made with the data in hand; if so, the cache for that
antenna would be cleared, and if not, it would just wait for
more data.  The cache would also be cleared for a new scan.

Current pointing solver saves solutions and averages over the
whole scan.  Probably worth doing this here as well.  If we
don't, current Executor code would simply pick the last solution,
except in the case of second order reference pointing, when it
might get confused.  (I'm not sure it would - things are
complicated.)

Attempting a solution.

Obviously, data must be present for all five positions.

It is not helpful to have low SNR solutions.  So we should
have a SNR cutoff on the on-source position.  7 is about
the right number - this results in a statistical uncertainty
of about 0.10 beamwidth.  If we are dealing with correlation
coefficients here, we can readily calculate SNR -
     Amplitude / sqrt(subband bandwidth * subscan duration)
(If we are dealing with the current odd units, we might need
a better expression).  So a low on-source amplitude is a cause
for rejection.

Algorithm.

The current itelcal code employs the conceit that beams are
roughly gaussian.  It takes the logarithm of the amplitudes
and fits a parabola.  An alternate approach is to assume that
beams are roughly inverted parabolas.  The two approaches
give the same answers if the pointing error is small, but the
gaussian beam approach is probably slightly more robust for
errors exceeding a quarter of a beam (though we tend to not believe
the results in such cases anyway).

Each axis and each polarization is solved independently.  If
for one of these solutions, the three measured amplitudes are am,
a0, ap for the minus offset, on-source, and plus offset respectively,
the curvature of the fitting function is
     q = (2a0 - ap -am)
and the required pointing correction is
     x = (ap - am)/q/2
in units of the position offsets used.
The true peak of the beam is given by
     p = a0 + q*x*x/2
The beamwidth is 2p/q, again in units of the offsets.  (In the
case of processing log data, half power data will show up at
log(0.5) level which can be computed.)

In the existing implementation, itelcal is pretty tolerant of bad
data, and the programs that use it, peek and reference pointing,
can choose to be a bit more selective.  I think I would rather
see the choosiness put into telcal.  That is, if the beamwidth is
very different from 2, say by 20%, (either in the azimuth or
elevation solution) I would fail the solution.  More controversially,
if one polarization solution fails, I would fail the other.  (We
might want a switch on that so we can point an antenna with a
broken receiver.)