[evla-sw-discuss] Some thoughts about pointing

[Barry Clark]

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