|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.atnf.csiro.au/computing/software/karma/user-manual/node14.html
Дата изменения: Unknown Дата индексирования: Sun Feb 13 04:24:53 2011 Кодировка: Поисковые слова: dark nebula |
Karma Home Page
Radio telescope interferometers exhibit chromatic aberration effects. This is because the resolution of the instrument changes with wavelength. For low-bandwidth spectral-line observations, these effects are minor and can usually be ignored. However, for high-bandwidth observations (say 128 MHz) these effects can pose a problem.
Reduction packages such as AIPS and AIPS++ will produce a beam pattern image for each frequency channel. This allows these packages to compute a spectral-line cube which has a pixel size (cellsize) independent of frequency. The chromatic aberration manifests itself in the dirty cubes as a changing antenna pattern. In other words, if you play a movie of the channel maps, you will see the grating ring pattern change. Once the cube has been properly cleaned, you should no longer see grating rings and hence the cromatic aberration has been effectively corrected.
Reduction packages such as Miriad will only produce a single beam pattern for a nominal reference frequency channel (this approach has the advantage of saving disc space). Because of this, Miriad produces cubes where the pixel size changes with frequency. You can see this when you play a movie of the channel maps: an object distant from the phase centre will appear to move, although the grating ring pattern will not change: it only shifts with the source object. This shifting of an object with frequency is of itself not a serious problem, however it is important that the co-ordinate system takes the variable pixel size into account, so that it tracks the moving object correctly.
The scaling of the cell size with frequency is accounted for in the coordinate handling within Miriad. The correction is quite small for narrow bandwidths (e.g. 4 MHz), but quite noticable for cubes with 128 MHz bandwidths at 20cm (a 7 pixel shift is not unheard of).
The FITS convention assumes that pixel sizes are constant. The visualisation software also makes this assumption.
Since June 1997 Karma has taken account of this chromatic
aberration by adding the new ``CELLSCAL'' keyword as it reads in
Miriad cubes. This keyword is used in the astronomical world
co-ordinate package to correctly track variable pixel sizes. At the
same time Miriad was modified to add the ``CELLSCAL'' keyword when it
writes FITS files. Prior to this, old FITS cubes written by Miriad did
not have this keyword, and hence violated the FITS convention. If you
have such old cubes, you should either regenerate the FITS from the
original Miriad cube or else manually edit the FITS header by adding a
line such as:
CELLSCAL = '1/F'
If you use a current version of Miriad and Karma then the co-ordinate system will correctly handle the chromatic aberration effects. Note that the source object will still appear to move as you play a movie of channel maps. I have been asked to change this, but this would require the visualisation software to regrid the cube. Apart from the computational cost involved, it is also not the correct approach, as subtle artefacts can be introduced. The correct approach is to produce a cube in Miriad which does not have a variable pixel size. This is possible to do (although a little awkward). It involves computing each channel image independently. This will mean that Miriad computes a beam pattern image for each channel. If you manually specify the pixel size, each computed image will have the same pixel size. After this you clean each image and collect them into a single cube. You can make this procedure easier by writing a script. Once you have produced such a cube, check the header to ensure that you don't have a ``CELLSCAL'' keyword with value ``1/F'' (Miriad should only do this when a 3-dimensional ``invert'' is performed).
Karma Home Page