 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1367 |
|
The approach adopted follows object-oriented analysis procedures, typified by Coad & Yourdon (1991). Indeed, most of the diagrams in this report were generated using OOATool, an object-oriented design tool which follows the notation used by Coad & Yourdon.
Much of the difficulty experienced in any analysis is in defining the problem domain. In a note distributed via the aips2-structures exploder on 12th December, 1991 (Message-Id: <9112121756.AA08339@zia.aoc.nrao.edu>, hereafter referred to as CS1), Cornwell and Shone attempted to analyse the general problem of visibility data processing. This addressed a rather specific problem, namely that of how to handle visibility data for a limited range of applications. Whilst that analysis was adequate for the problem as defined, any attempt to generalise that analysis would inevitably force other applications into an unnatural model.
We have attempted to step back and consider the more general problem of radio-astronomical data processing, as suggested by Hjellming and Glendenning (``An Initial Design for Major AIPS++ Objects'' - AIPS++ group internal memorandum; 27th January 1992). Their analysis presented a highly abstract view of the problem, but one which can be used to set further development in context. We have, therefore, tried to steer a middle course between this and the approach in CS1. Our model for the problem assumes that some abstract astronomical instrument (Telescope) produces measurements (known as Yegs) related to the sky brightness distribution in a way which may be described by an Imaging Model. The measurements are assumed to be corrupted in ways which may be described in arbitrarily complicated Telescope Correction/Calibration Models. In doing this, we can consider the general problem as a kind of inversion problem, but with special treatment for data calibration and correction. In this approach, specialisation for a particular kind of Telescope may be achieved simply by changing the models for calibration/correction and imaging.
An inversion process using a particular ImagingModel produces an estimate of the quantities the astronomer is interested in, typically a SkyImage (a kind of Image with a sky coordinate system), but there may be many other possibilities. Whilst the ImagingModel typically involves a Fourier relationship, this may not always be the case.
The analysis described here is almost entirely at the level of an application programming interface, and thus most of the classes identified here should correspond to entities familiar to the observational astronomer using the system. As an object-oriented analysis, it inevitably provides a conceptual design for this level of the system, but details of the precise relationships between objects (and often the location of attributes) is unclear in many cases, and deferred to more detailed design.
Issues of implementation are rarely touched upon, and the development of the system will probably entail analysis and design for a number of ``layers'', with each being dictated largely by the requirements of the implementation of the layer above. In particular, issues of object persistence are not addressed here, nor do we say anything about strategies for input/output, interprocess communication or task/process management. Whilst this has occasionally led to difficulties in placing our analysis in the larger context of an AIPS++ system, it has also given us some freedom which will inevitably have some impact on the areas mentioned above, as well as the user interface.
Many individual areas, such as calibration and imaging, were identified for discussion by smaller groups. This eventually led to a coherent model with a number of components which have been analysed in some detail. We give a brief introduction here,
By coupling model parameters to the appropriate solver and corrector methods, model dependencies are largely hidden, and new models, with their appropriate methods for solution and correction may be introduced with minimal impact on the rest of the system.
Telescope models may include representations of any hardware which may be relevant (i.e., the appropriate parameters may be updated, and used to correct Yegs. For example, a simple interferometer TelescopeModel might include Receptors, (to which antenna-based gains are attached) which represent inputs to a Correlator (with which baseline-gains are associated).
These are usually related to a particular kind of telescope (e.g., an interferometer or a single dish), but there may be several models for each telescope; e.g., an interferometer user may require various approximations to the measurement equation, such as 2-dimensional approximation instead of the correct but computationally more expensive 3-dimensional version.
Like the Telescope calibration/correction models, it should be possible for the user to select and control imaging models, and it should be possible to implement new models without changing anything else in the system.
A number of classes we have identified match real objects, particularly in Telescope and its constituents. It is important to realise that these are not intended as complete models of these real objects; rather, our models are an abstraction relevant to the data processing problem, and they can only be described in terms of components for which parameters are available. There is no point in building a complicated model of the real telescope, when we cannot hope to be able to parametrize such a model. However, our scheme does not exclude the possibility of more complicated models; it simply ensures that instead of adopting fixed, predetermined models, where change has wide impact in the system, one can replace models in a modular fashion.
Abstract models are useful in associating entities which have something in common in the ``real world'' (e.g., such as Telescopes and models for gain errors), and we believe they aid in understanding the way in which data structures and associated methods are organised.
We recognise that our analysis is incomplete in many areas, and suggest that it should be seen as framework for more detailed analysis and design. We believe we have recognised the important classes, and their principal attributes and services, although these may have to be modified on closer inspection.
Some of the object classes we propose (particularly the ImageTools) seem procedural in nature, and initially, we tried to avoid them. However, it became apparent that these are valid and useful objects which may be identified as a particular kind of tool, with individual instances representing an algorithm with a particular set of parameters. We suggest that it may be interesting to carry-out further investigation of this idiom, in the context of the ``Tools'' specified in the user requirements, in order to determine whether it my be more generally useful.
The following sections describe the major areas of analysis in more detail. These should be read in conjunction with the Coad-Yourdon diagrams and associated notes. The diagrams immediately follow the text for each section, but the associated notes, which contain supplementary information are contained in appendices at the end of the document, in order to prevent the main body of the report from being disrupted.