Version 1.9 Build 1367

News	FAQ
Search	Home

Next: Splitting Calibration Up: Recommendations for the AIPS++ Telescope Model Previous: Introduction

Summary of the recommended Imaging Model

The logic in the first memo leads to the idea that the Imaging Model be regarded as an class representing a linear equation AI = D where I is the sky brightness, D is the data and A is an operator (usually a matrix) which converts sky to data. The only services required of the Imaging Model are:

invertable: returns true if the linear equation is invertable,
invert: returns A^-1I for given I,
predict: returns AI for given I,
solve: returns A^TwD for given D, optionally normalized by the diagonal elements of A^TwA (if A^TwA is diagonal, the normalized version is the solution to the normal equation),
residual: returns (AI - D)^Tw(AI - D) and A^Tw(AI - D) for given I and D, optionally normalized by the diagonal elements of A^TwA,
observe: returns A^TwAI for given I, optionally normalized by the diagonal elements of A^TwA,
Hdiagonal: returns the diagonal elements of A^TwA.

Bob Hjellming pointed out the utility of the first two services for simple well-conditioned imaging problems like single dish processing. In many cases, however, A is singular and so a non-linear algorithm must estimate the sky I using some extra information. In doing so it calls upon the services of the Imaging Model to interact with the data.

One could imagine defining a special Imaging Model such that the matrix A is supplied explicitly in the constructor. These various services would then be realized by actually calling the relevant Math routines. In view of some misunderstanding of the first memo, I should emphasize that only in the rare simple cases will any of these operations be implemented using simple matrix algebra. In general, special properties of the matrix A must be used to make the computation feasible. A particular example which should reassure those who are nervous of this abstract formulation is that programs like APCLN will have nearly all the same basic operations but arranged in a slightly different way. There should be no efficiency loss in adopting my proposed definition of Imaging Model.

In current AIPS++ terms, D is a YegSet and I is an Image.

At this point it is worth restating just why we have a need for the Imaging Model. The answer is that we want to decouple some aspects of deconvolution algorithms from the details of the data. In this proposal, deconvolution algorithms interact with data only through the services provided by the Imaging Model. Hence new deconvolution algorithms can be introduced easily without having to explicitly write a version for each type of Telescope. If we accept this goal for deconvolution, the next obvious step is to see whether it can be extended to calibration. This really leads to two quite separate questions: first, can we abstract the calibration of Telescopes into an equation part (analogous to Imaging Model) and a solver part (analogous to the deconvolution algorithm)? and second, can we abstract the calibration of a Telescope into a class which can be called upon in selfcalibration? I address these two questions in turn.

Next: Splitting Calibration Up: Recommendations for the AIPS++ Telescope Model Previous: Introduction