 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1367 |
|
The AIPS++ vision is very bold. It represents a unification of new astronomical algorithm and software ideas with state-of-the-art computing technology. In the paragraphs that follow we will discuss some of the potential technical problems as well as some exciting opportunities that we feel may be encountered in the year ahead.
This project involves two major core software technologies: AIPS++, the base object-oriented (OO) C++ class library, and glish, a software system that provides an interpreted programming language to allow users an interactive data exploration and manipulation tool and a ``software bus'' that allows AIPS++ and AIPS++ compliant applications to be distributed over a network.
One of the strengths of this project is its aggressive adoption of both object-oriented methodologies and distributed computing. Unfortunately, being such early adopters of new technology has caused a number of problems. More specifically, some of the early industry standards that they have adopted are not yet stable and widely available. In other cases, they have had to invent many OO and distributed computing tools because industry standards had not yet emerged. As an example of the former, the style of C++ programming in AIPS++ makes heavy use of templates and exception handling. While their use of these language features is part of a very good overall design, most compilers do not fully support these features. Consequently, the Project has a serious but temporary problem with portability. As compilers improve these problems will vanish.
Another example of technology maturity problems is the glish system. While it has a nice programming model, long-term support is uncertain and it requires many modifications to be everything desired. These modification include more complete support of programming language features appropriate to AIPS++ and fixing potential security and performance scalability problems of the distributed computing ``glish software bus''.
Recommendations:
Now that industry standards are appearing, some of the early technology decisions may need to be revisited. For example, the array class in AIPS++ may not be as sophisticated in performance and memory management as some others (such as the Los Alamos A++ library). Also, the glish software bus will need to be extended to allow access to other distributed object systems standards like MicroSoft OLE. Indeed, this layer of glish may need to be replaced by something compliant with OpenDoc or the OMG CORBA specification. Other examples of technology choices that may need to be reconsidered include the use of Mosaic as a forms and help system manager (tcl/tk may be more appropriate), or the use of persistent object data base systems as a base technology for the Tables classes.
One general recomendation is to look at a more formal approach to interfacing software components and distributed objects. ``Interface Definition Language'' approaches may be one possibility. In general more emphasis needs to be put on technology integration.
The primary reason for building AIPS++ is to improve the research productivity of the Radio Astronomy Community. Clearly the first priority of the design and implementation is correctness and utility. One of the goals of glish is to make it possible to for research to explore data and algorithms on an interactive basis. Consequently, performance will become an issue and implementation of parts of the system on massively parallel supercomputers may be an important consideration.
Fortunately, the design of AIPS++ and the incorporation of distributed computing principles into the design of the glish programming model make this well within reach. Indeed, the first demo of glish/AIPS++ programming demonstrated that it is relatively straightforward to partition some computational tasks, such as the analysis of independent spectral lines, into independent processes that may be allocated by a server to different processors or machines.
In a more general context, one can consider a future implementation of a modified AIPS++ server that runs on a supercomputer with key computational classes that encapsulate parallel implementations of the algorithms. A ``driver'' program written in AIPS++ or glish on a workstation can manipulate ``proxy objects'' which in turn employ the software bus to send requests to the parallel server where the real data is stored. The design and organization of algorithms using the A-Matrix formalism makes this approach very attractive.
Recommendations:
As a general recommendation, the AIPS++ consortium may wish to foster carefully targeted collaborations with one of the supercomputing centers like NCSA to experiment with this approach.
The procedures and tools for code acceptance, distribution, and documentation have been developed quasi-independently by several persons under only loose control by project management and technical leadership. On the whole, these elements have been developed in sophisticated and elegant ways, but there are some alternatives that should be considered.
The project is positioned to use the Internet as the principal distribution medium for all AIPS++ code, data, and documentation, with physical media as a rarely-used alternative. This appears to be a reasonable expectation, especially if the material is segmented effectively so that users can acquire the components they are interested in without having to deal with the rest of the corpus.
The acceptance procedure is central to the design of the ultimate AIPS++ operation. Decisions made in regard to the acceptance strategy will determine the level of interest in the community in contributing to the AIPS++ distribution. These decisions could result in AIPS++ ``writing itself'' through steady contributions from the community, or being a sterile framework with no users at all. The code acceptance strategy must be based on a simple, reasonable, enforceable model of what an AIPS++ component is.
A serious concern with the current acceptance plan is the restrictive, brittle definition of ``acceptance.'' At present, acceptance is a binary decision requiring various quality assurance (policing) steps. As demonstrated at this meeting, the community is very interested in rapid dissemination of tools even if they are not fully certified. The acceptance strategy in AIPS++ should be augmented to make it easier to get products into the AIPS++ distribution, but always with proper labeling of the level of certification and the intention (or lack thereof) of the developer to obtain a higher level of certification. (The AIPS++ Core should probably always consist of fully certified code. Acceptance into the Compliant and Freedom layers should be with varying levels of certification.) Labeling by certification level will also be necessary for the levels of integration described at the Review (core, compliant, freedom) since a likely (even desirable) strategy for the development of AIPS++ is to accept code into the Freedom layer, integrate it over time with AIPS++ classes and migrate it to the compliant layer, and if there is sufficient interest to fully integrate it eventually into the AIPS++ Core.
The code management and distribution system is very sophisticated, but there are aspects of it that may be overcomplicated. The system appears to violate the principle of locality, which says that all material relating to a particular piece of code should be located in close proximity in the overall structure. Control of this system is centralized in one individual and is perceived as a high-intertia design. That is, it is perceived as being brittle, so structural variations are not welcome, and high-inertia, so design changes are difficult to make and slow to take effect.
The vision of a hypertext system integrating documentation of all parts of the system is very attractive, and the use of HTML as the markup language for accomplishing this seems appropriate in spite of its current, temporary limitations for mathematical use. The realization of the vision will be expensive to contributors who must buy into this form of Literate Programming and to the Center in terms of developing tools for automatically extracting and linking submissions into the documentation system. This is another likely point of collaboration with computer science projects that are studying this possibility explicitly.
It is not clear that the difficulty of creating elaborate hypertext documents has been adequately assessed and incorporated into estimates of project effort and duration. The focus of the documentation effort has been new users, but in fact the most important documentation to develop depends on the strategic direction of the project. If programmability is declared most important, the most important documentation is the application programmer interface. If a complete analysis path is declared most important, then the most critical documentation is that for the tools implementing the analysis path.
The structure of the system seems to imply that there should exist a compilation, linking, and archiving formalism for documentation as well as library code. Documentation extracted from code must be linked into the overall documentation library just as executables must be linked into code libraries.
SDCI. The SDCI effort has produced a working AIPS++ application that could conceivably be used for astronomy within a few weeks: the On-The-Fly mapping tool. Unfortunately, however, the OTF effort did not capitalize upon the interest of local astronomers, but instead provoked a fair amount of unhappiness because of lack of consultation. Moreover, the plans for a simple interactive replacement for UniPops continue to be vague. While it may be possible to implement many of the language elements of UniPops in glish, it is not clear how long this would take or that this can be justified for any other than sociological reasons.
UVCI. The work required in the development of the UVCI facilities is potentially very large. We heard an estimate from an observer at the review that writing useful software for the VLA/VLBA would require roughly 10 staff-years. We believe this is a reasonable and realistic estimate. The ``travelling circus'' planned for the UVCI effort in Dwingeloo in early 1995 seems unlikely to work, given previous experience in arranging large collaborative design efforts. In addition, we perceive a politically motivated rapid expansion of the UVCI to cover many different types of telescopes as quickly as possible. This is unwise.
The Green Bank Model. The Green Bank Model, which is an abstraction of how complicated calibration and imaging algorithms are structured based on a physical model of the real world, remains controversial. Since its development at the February 1992 design meeting (Shone and Cornwell 1992) and subsequent refinements, little progress has been made in design or validation. There continues to be strong but hard-to-summarize opposition to the Green Bank Model from a small number of people (two). We find the criticisms hard to analyze and reproduce here.
IMAL and Visualization. The image display and visualization facilities developed by the Illinois group are both interesting and problematic. They fall into the category of ``AIPS++-Aware'' software, but it appears that this category of software was defined in order to provide a space for code that, for political and programmatic reasons, was not developed in an AIPS++ compliant manner. The AIPSView application is sufficiently well-developed that it should be made available to the user community, and if ``marketed'' properly it will bring much needed credibility to the overall effort. The application appears to be successful despite the limited user testing and feedback that has occurred (only one astronomer has looked at it in detail). This contains a useful lesson for the project: development of an initial version of a tool can be performed effectively by a close programmer-astronomer collaboration. However, the facility would have been much more impressive if AIPSView were usable as a general purpose display server for AIPS++ applications. In addition, there appears to be an unnatural split between the design and implementation work on visualization and image analysis in the Project. We see no real reason for this split.
The BIMA group indicated plans to incorporate extensive image analysis capabilities into the visualization toolkit. We have concerns about this approach, in that it burdens a self-standing display and visualization tool with a semi-infinite potential for growth and complexity. Image analysis must be done on the original data (not on display buffers) and could easily grow in scope beyond a supportable level if incorporated directly into the image display and visualization applications.
Astronomical Oversight. Links of programming efforts to interested and committed astronomers are missing. In the acerbic but well-chosen words of one observer at this review, the project is running ``open-loop,'' that is without sufficient oversight and correction from astronomers. This is especially pernicious given the all-encompassing nature of the main specifications document used by the project (Hjellming 1992). There seems to be a more fundamental communications problem: even after two days of presentations, one astronomer commented that he did not have a firm idea of what AIPS++ was.
The Relationship Between AIPS and AIPS++. The continuing existence of the AIPS package is both a hindrance and a blessing to the AIPS++ project. The advantage is that the pressure for applications is lessened. The main disadvantage is the same. AIPS++ has to demonstrate superiority over existing packages in some area to gain converts. There is an obvious schism between the AIPS and AIPS++ Project staffs. This is deeply regrettable.
Documentation. The plans for on-line user and programmer documentation seem sensible and well-thought out. We doubt that the staffing required has been accurately assessed.
Performance. The relative priority attached to performance issues is not stated in the AIPS++ mission statement. It was suggested by one observer that the AIPSMark benchmark be reproduced in AIPS++. This would require coding of all the DDT (Dirty Dozen Tasks) in comparable form in AIPS++.
Recommendations:
SDCI. The Project should continue with the development of the OTF mapping tool. It is important that the design be expressed fully in terms of the Green Bank Model. Add more functionality expressly to check the GB Model. Possibilities include baseline fitting and removal, multi-beam observations, and on-line calibrations. Install this software at the 12-m in Tucson and try to add functionality as suggested. Make this a ``flagship'' application for SDCI in AIPS++. Add more sophisticated imaging algorithms as possible. Analyze the need carefully and consult often with interested astronomers over the plans for a UniPops replacement.
UVCI. In the area of UV data calibration and imaging, focus on a telescope model sufficient to calibrate a single telescope's interferometric data (e.g., VLA, WSRT, or AT). Push this all the way from data filling to self-calibration before starting on other TelescopeModels and MeasurementModels. Arrange for a small number of people to work in this area. Avoid premature testing of the design against every conceivable type of telescope. When the basic features of the design have been demonstrated in this way, expand it out slowly to cover more additional telescopes. We encourage, at least initially, sequential development by one or two people rather than parallel development by a large number of people. This conservative approach is warranted by the difficulties expected in this complicated area. Note that this implies, not unexpectedly, that interferometric data reduction capabilities will not be delivered early in the Project.
The Green Bank Model. For both the SDCI and UVCI development efforts, the Green Bank Model should be tested and scrutinized. If it has significant problems, it should be modified or dropped. However, for the moment, continue with it.
IMAL and Visualization. For image analysis and visualization, release AIPSView soon as a stand-alone AIPS++ application. There seems to be a strange reluctance in the project to capitalize upon the success of the development of AIPSView. The fact remains that it is associated with the AIPS++ project and can be more closely incorporated with ``main-stream'' AIPS++ in the future if warranted.
The working relationship between the BIMA group and the rest of the Consortium needs attention, however. Now that more of the infrastructure is available, the BIMA group should incorporate AIPS++ classes into their visualization tools (e.g., FITS classes, image classes, and coordinate classes). This will allow for a tighter integration of the visualization utilities with AIPS++ applications, yet also allow these utilities to be used ``stand-alone'' -- to the benefit of the entire astronomical community.
Astronomical Oversight. The Project should establish programmer-astronomer partnerships. This places AIPS++ development in the personal ``critical path'' of the astronomer and thus will ensure continuing involvement of the astronomer, something that otherwise is difficult to obtain. This model of interaction will produce very capable applications in one or two narrowly focussed areas, rather than across a broad range of application areas, which should be demonstrated to the user community at every opportunity. Do everything possible to ensure that realistic deadlines are carefully set and are then met. Nothing is more destructive to a collaboration than promises that are broken time and time again.
The Relationship Between AIPS and AIPS++. Don't compete head-on with the AIPS Project or other existing astronomical packages. Choose areas where other packages are known to have deficiencies, e.g., real-time filling of data as is needed in On-The-Fly mapping. We doubt that a formal testing of the AIPSMark is warranted at the moment, especially given the work entailed in writing the DDT tasks in a comparable form. However, we encourage monitoring and correction of performance issues as a standard part of development, if appropriate. An AIPS++Mark may be worthwhile as a long-term goal. In addition, it would beneficial to both the AIPS++ Consortium and specifically to NRAO if the schism between the AIPS and AIPS++ Project staffs can be healed.
Documentation. Inform the astronomical community very soon of plans for user documentation development and ask for contributions. It may be that other groups have plans for documentation that complement those of the Project.