 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1367 |
|
In this document, we have described our analysis of the AIPS++ calibration and imaging requirements. Our key decision concerning calibration and imaging in AIPS++ is not to build a very general calibration/imaging model which could be specialised to particular telescopes, but rather to set up a scheme whereby support for a new telescope or new methods of calibration and imaging can be easily inserted. We feel that this provides the best guarantee that AIPS++ will be able to support calibration and imaging in the most flexible and efficient way. Clearly, there will be much to be gained by careful planning and coordination of the development of different TelescopeModels and ImagingModels.
We accept that our analysis is necessarily incomplete and perhaps incorrect in some parts. There are a number of points that we have left undecided in this document but which must be fixed in any design. For example, questions of whether operations act at the Yeg or at the YegSet level must be deferred until detailed consideration of various applications. Furthermore this analysis/design must be checked against the various user specifications in some detail to see if it conflicts with some requirement. While we have tried to ensure that no user requirement constraints are violated, this deserves closer scrutiny. We have tested our model for calibration and imaging both against simple cases such as self-calibration of antenna gains on a source using the ordinary two-dimensional Fourier Transform relation and beam-switched single dish imaging, and against very complex cases such as pointing self-calibration during mosaicing, and non-isoplanatic self-calibration as will be needed for the GMRT. In all these cases, it passes and leads to a pleasing simplicity. In the more complicated cases, the imaging and telescope models must be coupled so that, for example, the imaging model can incorporate knowledge of pointing errors.
Following the conventional wisdom in object-oriented analysis, we deliberately decided to avoid concentrating upon efficiency issues during the analysis and design stages. We managed to follow this course most of the time, with the exception of discussions of the database system where questions of efficiency lies very close to the heart of any analysis. Further refinement of the proposals here should necessarily concentrate upon implementation concerns.
We have assumed little about progress in other areas of AIPS++. We assume something called SkyImage, which is derived from Image, and which knows about coordinate systems. We have made no demands upon the user interface or task management sub-systems. Despite this decoupling from the user interface, we suggest that some of our concepts, such as ImageTool, would be easily implemented in many different types of interface and form a model for the implementation of the tools requested in some versions of the user specifications.
The Project sub-system could usefully be open to user comments immediately, perhaps from astronomers closely involved with the AIPS++ project but not involved in this meeting.
Simple prototypes of the calibration and imaging models should be quite straightforward to construct, and can be developed independently of a number of other systems such as the user interface. We suggest that imaging of a simulated data base using Direct Fourier Inversion and a simple CLEAN algorithm should be a first goal, followed perhaps by rudimentary self-calibration. This prototyping will identify and highlight any shortcomings in our model of calibration and imaging.