[mmaimcal] Beam Squint

[Mark Holdaway]

Concerning Beam Squint in ALMA:

VLA:

The effects of Beam Squint on VLA images can be thought of in two
different ways:

1) The mean beam squint.  For imaging Stokes V, this results in some
fraction of the "I" image leaking into the "V" image.  The leakage
fraction is position dependent.  For Zeeman experiemnts, this leakage is
solved for in the cube.  It could also be calculated given the known beam
squint and the parallactic angles of the observation, but is not for
the VLA.

2) The rms beam squint.  If the beam squint on the sky did not change
(ie, if you only observed a snapshot or you had equatorial mount
antennas), then the dispersion about the mean would be zero, and all
you would have is the mean beam squint.  An image plane correction
would be trivial and very good.  But we don't have that case often.
So, in effect, a bright "I" source off the beam center will produce,
via the instantaneous beam squint, spurious stokes "V" which is
time dependent.  Many stokes "I" sources will have their spurious,
time dependent Stokes "V" going up and down, but not the same way
(ie, direction dependent...).  One could make a bunch of snapshots
and deconvolve each, and correct for the mean beam squint;
one could do it right as AIPS++ does (see below), or one could live
with it; in this case, the errors in stokes "V" will be like
the brightness of the Stokes "I" image times the rms beam squint (ie,
dispersion about the mean) times something like the rms sidelobe level in
the PSF.  IE, this turns into low level mud all over the image
(or not so low level mud if you have a wopping bright source).

------------------------------------------------------------------------

AIPS++ currently includes beam squint in the primary beam models
(ie, for the VLA).  Data are simulated by multiplying the model
image by the primary beam, suitably shifted by the beam squint
and rotated by the parallactic angle, then Fourier transformed and
degridded.

When imaging, there are two tricks that can be employed:

1) basically treat each different parallactic angle range
as its own "pointing" in a mosaic.  This is CPU-expensive,
but should make a nice image.

2) do a round of imaging ignoring the beam squint; then calculate
the model visibilities correctly, including the squint.  The
portion of the model visibilities due to the squint can be
subtracted from the data visibilities to simulate what observations
WOULD have been if there were no squint.

In principle, in a perfect world, if cokes were free and there
were no pointing errors and we knew the squint and the beam shapes
perfectly, we could correct the effects of beam squint perfectly.

However, the world is NOT perfect; (ie, we work for the ALMA project). It
seems that 2-4 weeks of work on this type of stuff could answer a lot of
questions, like:

	* How well will the software correction of beam squint
	  work as a function of the beam squint magnitude?

	* What if we don't exactly know the beam, how will that
	  affect our beam squint correction?

	* What about pointing errors, which will limit the beam
	  squint correction?  (OK, this requires me to write
	  some more software.)

======>  and on and on, it could become a full time job if you wanted it
         to!


HOWEVER:

I don't quite understand the beam squint effects for X/Y receptors.
Larry said that the beams do not separate on the sky, as they do
for R/L receptors subject to squint.  In which case, we need more
software.

Can anyone enlighten me (aside from Larry)?


EVEN IF NOTHING GETS DONE HERE:

We can walk away from this knowing that some level of improvement is
possible via a software beam squint correction.  We can wave our hands
and make guesses -- can we improve the effects of beam squint by a
factor of 10?  Maybe.  If so, a 4% beam squint is probably acceptable,
at least at low frequencies where the pointing errors are small and the
beams will be, hopefully, well known and not highly dependent on elevation
and wind direction and solar this and that.  The Larry people did the
right thing in picking the higher frequencies to be closer to on-axis,
as that problem will be harder to fix in software.


	-Mark