[evla-sw-discuss] Some thoughts about pointing

[Bryan Butler]

while making it a fixed pattern simplifies many things i am strongly 
against it.  the positions should be flexible so that down the road we 
may choose other patterns if we wish.

going to even more complex schemes (like the OVRO rotating triangles) 
may be too much, but having flexibility in the pointing positions is a 
key requirement and one i will not give up on.

	-bryan


Barry Clark wrote, On 7/15/09 09:11:
> 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.)
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss