 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
There are a number of critical issues which must be addressed concerning upcoming releases of the AIPS++ package. In particular, the content and audience of each planned release must be well defined to ensure that they will be effective. Furthermore, it is vital that each release be ``billed'' in such a way that no unrealistic expectations are generated.
It is our view that the so-called ``
release'' scheduled for
January 1997, must already be as bug-free as possible. In particular
the problems of memory management, and Glish-related crashes should be
solved, before even this limited distribution of the package is
undertaken. The functionality need not be excessive, but what is
present should work well. The audience of this release is presumed to
be only a very small number of ``friendly'' sites beyond the currently
participating consortium members. One of the primary purposes we
identify for this release is actually the definition of a concrete
deadline which should serve to focus the efforts of the group and lead
to a stable development environment at the earliest possible time.
Although we understand the increased logistics impact, we suggest that both source code and documentation be included with the initial binary release, even if there is no intention of supporting local building. The likely recipients should be able to look more closely at the workings of the package. The very limited functionality of this release make it critical that prospective users have the ability to get their data both in and out. The ability of the package to write at least calibrated single-source UVFITS files should therefore be given a high priority. We believe this would greatly enhance the number of early users.
The release scheduled for mid-1997, which has been referred to as the first ``full release'', might be better referred to as a ``Limited Public Release''. The term ``full release'' seems to us to imply a much greater degree of functionality than can be envisioned for this early date. This first public offering of the package will, in our view, be critical for defining the community perception of the project. For this reason, we feel that it is important that a high priority be given to further development of the user interface(s). Simple ``auto-GUIs'' should be reinstated to enable novice users to setup processing steps without the need for mastering a verbose and non-intuitive syntax. The command line interface should also be carefully evaluated and if necessary repackaged to insure a high degree of accessibility to the user community. The package needs to ``feel'' good to new users. This property is more critical, in the short term, than an enhanced functionality. During 1997, new users will have more tolerance for a reduced functionality, than for the frustrations which arise from an awkward interface.
At the same time it seems very desirable to have completed at least one high level application package which thoroughly exercises all of the major system components; including interactive image display and graphics. Only then will it become clear what the ``standards'' (in terms of user interface, documentation, performance, etc.) should be for new applications within the system. These ``standards'' need to be defined as soon as possible so that standard applications can be generated within the extended user and programmer community.
The clear limitations of functionality of this release make it important that data can be brought into, and removed from, the AIPS++ environment. A capability for both reading and writing multi-source UVFITS seems essential in this regard. If it is deemed impossible to reconcile the different table functionality of UVFITS with that of AIPS++, then it would be sufficient to provide calibrated output.
Based on the solid base of the mid-1997 release, increasing functionality will presumably accompany each subsequent release. A global plan to plot the development of all major processing components which are currently envisaged should be made to help in planning for a timely completion.
Planning for the early support of LINUX and NT platforms should receive a moderately high priority.
It is important that the target audience (astronomer/user or developer) be understood before a release takes place. Is the purpose of the release to support outside development, or to provide end-users with complete scientific packages to do serious work? Is the purpose of a release merely to involve the outside community and get feedback from users to guide further development? These decisions need to be made early in the planning phase of a release to guide development. The announcement of a release should make it clear to prospective users what type of user (end-user or developer) the release is targeted for. Probably several releases over a span of 1-2 years will be required to meet all goals for the baseline system and the emphasis of each planned release should be made clear so that prospective users can decide when to get involved. We feel this is essential, not only to focus development, but to avoid disappointing users who may expect a release to provide something that it does not.
Further planning by the AIPS++ group is needed to prioritize development for the next 1-2 years and specify the goals and contents of each release. Our impression is that the January 1997 release will have limited impact outside the AIPS++ consortium sites and will serve mainly to get a snapshot of the system out for testing. The mid-1997 public release is unlikely to contain enough scientific applications software to be interesting to most astronomers, but it will provide the user community with an early look at the system and should provide developers with the first stable and fairly complete version of the development environment. It is important that this version contain one or two complete scientific applications to demonstrate that a complete development environment exists, and to provide working examples of typical AIPS++ applications. A further release sometime in 1998 should provide the first fairly comprehensive scientific applications, as well as an update to the development environment.
Some mechanism for technical and user support should be in place by the time of the mid-1997 release. At a minimum this should consist of a project email address for technical support and perhaps a hotline for telephone support. Additional resources may need to be identified for platform support, preparation of distributions and patches, version control, and technical and user support.
A list of user-related concerns which we believe require attention in time for the mid-1997 release is given below.
It is especially important for a first package release to avoid establishing a bad reputation which gets passed on by word-of-mouth and which may take years to overcome.
There was significant concern that the performance associated with some AIPS++ operations is unsatisfactorily slow. Regrettably, few hard numbers on the speed performance of AIPS++ code are available, and the few that are, are not entirely encouraging. No systematic performance evaluation of, for example, the synthesis package has been performed. Such evaluation needs to be performed, and the code needs to be tuned so that it is no worse than about a factor of two slower than present packages, preferably much better. This problem was discussed extensively with Cornwell, Glendenning and Garwood. Clearly, the code can be sped up but it is unclear that manpower is available to implement all of the changes needed on a reasonable timescale. The committee feels that performance is an important aspect of AIPS++ and inadequate performance could result in poor acceptance by the user community.
The memory requirements of AIPS++, both for a programmer (256 MB) and a user (64 MB), tend to be larger than the workstations currently used by most astronomers. Although hardware and compiler improvements may diminish this concern over the next few years, the AIPS++ group needs to continue to investigate ways to reduce memory bloat. Memory leaks must be plugged.
The alpha testing of AIPS++ and the AIPS++ interface (Glish) has been minimal so far, yet it is a very important step towards acceptance of AIPS++ by the user community. To date, it appears that virtually no consortium astronomers have acted as friendly novice users or ``alpha'' testers. AIPS++ will not be a real system until it is in production use on a daily basis within NRAO and the other consortium sites. New releases should be beta-tested within the consortium for several months prior to any major release, by having the software used on a daily basis for routine data processing by the scientific and technical staff. This is in addition to the alpha-testing performed by the programming staff during development. We recommend the aggressive recruitment of consortium scientific staff for in-house testing.