[evla-sw-discuss] Some thoughts about pointing

[Bryan Butler]

ahh, OK.  sorry i misunderstood.  i'm fine with specializing it for now, 
then extending it later.

	-bryan


Barry Clark wrote, On 7/15/09 13:31:
> I was not suggesting writing the capability out forever, just not
> coding the reduction right not.  Fancier patterns could be invoked
> with a different intent, and code specific to that pattern added.
> Problem with a general solver is, I think, that it would have to
> have a reasonably accurate beam shape to be able to make sense of
> things, and putting that into telcal is getting a bit fancy.
> 
> Bryan Butler wrote:
>>
>> 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