Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1556

News	FAQ
Search	Home

Subsections

• Maintenance
• Distribution
• Development

Core operational functions

The core operational functions for any package are maintenance, distribution, and development.

Maintenance

Maintenance of the package is needed to discover and eradicate bugs, and to track environmental changes such as operating systems changes and compiler changes.

Bugs

In any system, a continuing effort is needed to uncover, track, and eradicate bugs. For the mechanics of bug tracking, we currently use the GNATS package from the Free Software Foundation. This seems to be adequate currently but we may have to consider migration to another package if the current approach does not scale up. The current system has two potential bottlenecks. First, all bug reports currently go through the Project Center, and second, the bug reports are then classified by one person. We have to work to eliminate both these bottlenecks once the flow of bug reports diversifies and increases. A quick response to bug reports is vital to avoid the ``stale bugs'' problem whereby a delay in responding to bug reports means that many bugs have been fixed or are no longer relevant.

Tracking environmental changes

The environment under which AIPS++ executes will inevitably change over time as the underlying operating systems evolve and as improved version of tools such as compilers become available. An extreme example of an environmental change that must be monitored is the advent of Java and all it portends for computing in the future.

Distribution

System

In the current setup, the core AIPS++ system is maintained at the Project Center in Socorro, New Mexico.

System distribution for developers occurs via two mechanisms. First, periodically the system is distributed to sites over the Internet, either incrementally or cumulatively. This is usually done in a batch job, and uses ftp for transmission. Second, changes to the master are performed via an NFS mount of the master disks onto a local machine. The first function, downloading, is highly reliable and essentially presents no significant problems. The second function, uploading, is more problematical since the Internet is sufficiently congested that the necessary NFS mount is hard to acquire and maintain. This will be alleviated with the forthcoming modifications to NFS to use TCP/IP in place of simple UDP datagrams. Inside NRAO, we rely upon our own intranet in place of the Internet. Outside NRAO, we have the option of bypassing the mounting process by ftp'ing files directly to an NRAO computer.

For end-users, the system is currently distributed as both binaries or source by anonymous ftp. Our beta testing has shown this to be a simple, effective and reliable approach. About 90% of AIPS distribution is via ftp. However to service some communities, we will also distribute via two hardcopy forms: CD-ROM and various tapes: 8mm and DAT initially.

Data

Data in AIPS++ fall into a number of categories. First, there are data from telescopes. Second, there are data needed for the software to execute. Examples would be databases needed for the Measures system. Third, there are databases that aid the user in some process. Examples would be source parameters, antenna locations, scheduling information, etc. Fourth, there are data needed for testing and demonstration purposes. We are currently determining requirements for the latter three, and plan to put in place mechanisms for users to acquire such data either from the AIPS++ Project Center, or directly from the original source.

Knowledge

Knowledge about astronomical processing and analysis should be one of the prime commodities that AIPS++ can help provide to its clients. We should distinguish between knowledge generated by AIPS++, and knowledge funneled through AIPS++ mechanisms. In the former category we see conventional documentation such as reference manuals, cookbooks, tutorials and migration guides (``AIPS++ for AIPS users''). In the latter category, we think that AIPS++ should provide mechanisms for users to talk to other users, via exploders, list-servers, news-letters, etc.. The major value added by AIPS++ in this latter category would be a common framework in which the discussions can be couched, and an archive which can be searched (a database for knowledge). Thus, for example, the NRAO Synthesis Imaging workshops should be strongly coupled with AIPS++ documentation.

Schedule

The update schedule will be one of the most contentious aspects of operating AIPS++. We can imagine that a dynamic group in a phase of rapid development of some sub-system in AIPS++ will push for a rapid release schedule whereas more established groups with less rapidly evolving needs will prefer a conservative approach to releases. For help in understanding this issue, it is instructive to consider the evolution of AIPS during the development of software for the VLBA. During this time, the AIPS software was evolving rapidly in response to a deluge of new data (and concommitant problems to be solved) from the VLBA correlator. Groups tightly tied to use of the VLBA therefore wished to update their own working copy of AIPS more often than allowed by any reasonable formal release schedule. The answer was for them to be placed on the AIPS Midnight Job whereby the working version is updated every night. The advantage of this is obvious. The disadvantages are that the system is then more unstable, and, more seriously, that it is impossible to determine the state of the system on any given date. However, if an actual release is also available then these bad effects can be reduced. This may form a good model: the center should release stable, well-tested releases a couple of times per year, and then allow users to be placed on a periodic update schedule as dictated by their needs.

Development

From experience with other systems, it is certain that development of AIPS++ will continue until (or even after) it is supplanted by another system. Historically, development of an existing production system has been an extremely delicate proposition. To add new capabilities without compromising those existing capabilities was difficult, and the degree of success that AIPS++ has in the area will be the key measure of the success of the object-oriented design of AIPS++. It is apparent from our (and industry) experience that object-oriented methods work well if high-level interfaces do not have to drift over time.

Core library

Any significant continuing development of the core library after the initial programmer's release will need careful consideration. Additions to a widely-used interface are often acceptable but the cost of changing an interface can be very large. This means that the core at the time of the first developers release, the core libraries should be up-to-date and state-of-the-art. In practice, if a core library is changed, we think that the resulting cost of changing code has to be borne by the Project Center since otherwise the cost to end-user programmers of tracking continuing changes will be a strong disincentive to use the system.

Applications

Development of applications will continue throughout the lifetime of the system, and is clearly to be encouraged! Here the most difficult problem is deciding which pieces of an application can be moved to the core library. Advice on priorities for this process can come from our clients but detailed advice on what to migrate when must come from a technically knowledgable group. Integration of a new package will be viewed most favorably if the code obeys our coding and documentation rules, and if the expected lifetime of the package is more than one year.

System

Changes in the implementation of the system library will be necessary over time for a large number of reasons: operating systems change, compilers improve, new devices come along (e.g. better long-term storage devices, improved visualization devices, etc.). Determining which configurations will be supported is a function of the Project Center, but advice is particularly important here.

Development entails hard choices. These choices have to be made bearing in mind the needs of potentially all the clients, and making sensible guesses as to which lines of development should be followed with which priority. As we said above, this will probably be one of the most contentious areas in operating AIPS++. We think that a diverse but tightly knit group would be best suited to advising AIPS++ management on such issues. We return to this issue below.