 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
STAG, (ed. R. Braun)
1998 February 20
A postscript version of this note is available.The AIPS++ Scientific and Technical Advisory Group met for the second time in Socorro on 9 and 10 February 1998. Substantial progress has clearly been made in the project during the 15 months since the first meeting of the STAG. Functionality is being extended and reorganized into more useful components. Memory and performance problems have been remedied to some extent. The newly developed ``Display Library'' may provide a solid base for future developments. The recently appointed documentation specialist is a valuable addition to the team.
Even so, it is sobering to look back at the recommendations made by
this group in our previous report (Note 198) and realize how relevant
most of them still are. At that time we stressed the need for a
comprehensive and realistic plan (in terms of timetable and manpower)
for the delivery of package functionality. This has not appeared. We
also stressed that the highest possible priority should be given to
providing an improved user interface. Although some examples were
presented to the STAG during demonstrations at this meeting, these
have not yet been available for assessment and feed-back in the field.
In our opinion, the existing user interface is a formidable barrier to
user acceptance of the package and is the main reason for the lack of
tester feed-back in response to the 
releases. Simply put, it is
just too painful for working astronomers to even exercise the system
at this time.
Our gravest concern is that the project achieve some degree of community support on the shortest practical time-scale. The strategy which has been in place during the past year or so, was to provide a small number of truly unique applications that would demonstrate the power of AIPS++ to the sophisticated user. While we still support this goal, we would stress again the absolute necessity of a ``pleasant'' user interface, and in addition, stress the need to provide at least a few simple tools that allow a large fraction of the community to exercise AIPS++ in a useful way. To this end, we recommend that very simple end-to-end cross-calibration and imaging be provided for data originating at the VLA, WSRT and ATCA within the first ``limited public release''. Much of the recommended simple functionality is already present in the system, including limited archival data access for both the WSRT and ATCA. We fully understand the practical difficulties of providing direct archive access for VLA data. We also understand that providing such a capability may entail a significant delay in the public release schedule. We consider such a delay preferable to squandering the very limited patience of the user community for products that can't do anything useful for them. One reason we stress improved support for VLA data is our perception that the North American community in particular is both rather critical of the project at this time and represents an enormous untapped resource for constructive feed-back.
While we applaud the recent formation of a testing group of astronomers within NRAO Socorro, it seems to underline the very limited role that NRAO astronomy (in contrast to computing) staff has taken in the project to date. We consider it vital that this be remedied. More extensive and continuous astronomer input is critical at this stage to insure a relevant and successful product.
Releases
As significantly enhanced functionality or interfacing becomes
available it should be released for testing and feed-back via this
method. We can envision several more releases of this variety before
going public. A release frequency of once in 6 months might be
realistic, so as not to generate an undue amount of overhead. It is of
particular importance that all of the content of the Limited Public
Release receive thorough
testing before distribution.
The components that the STAG deemed essential for a successful limited
public release are listed below. As stated above, all components
should first be subjected to thorough internal and
testing
before public distribution.
It was felt that the programming community is sufficiently small and (potentially) well-connected to the project that a separate release aimed at external programmers did not deserve a high priority.
We stress again the dire need for a user-friendly interface. More sophisticated GUI interfaces including graphical inputs should be addressed in the medium term. The use of auto-GUI's, while convenient in the short term, do not seem to offer the final solution.
Glish has matured to an extent that little more development is needed apart from bug fixes and possibly a debugging environment. Similarly, tables and the low level library are reasonably mature and do not appear to require more development. This would suggest that a strong shift in emphasis is needed from system software to interfaces and applications.
In the area of data display and graphics, we commend the development of the ``display library''. However, this general area seems to have become splintered, with simultaneous use of several different plotting libraries in different applications. We would like to see a consolidated design of future graphics and display capabilities. Visibility editing/flagging might be a good application with which to test both the design and the library. An application to take over the functionality of AipsView should probably be developed within the next 18 months.
Hiring a documentation specialist is a commendable step that should provide ample pay-back. A well researched and tested cookbook is a critical component of the documentation. Although not optimal, there is no urgency to replace the current "latex2html" system. While we recognize the importance of Web-based documentation, this should not be pursued to the detriment of high-quality paper documentation.
Substantial progress has been realized in the evolution of SDCalc to the GUI-driven DISH environment. This is an example of the very positive role an interested and active astronomer can have in keeping a software effort focused on results. Unfortunately, much work still remains to be done to integrate DISH with AIPS++ MeasurementSets, while the more general problem outlined in our previous report, of planning support for multi-dimensional SD data-streams, is being approached in an add-on fashion rather than proceeding from a global design.
The canonical machine: It remains a worthwhile goal to achieve satisfactory performance on modest machines with only 64 MB memory, since this will still be typical of user machines for at least the next year.
Platforms: We recommend supporting only those OS's which are currently available on short to medium time-scales. A Windows port may be important in the longer term, but should not draw significant resources at present.
Compilers: It seems prudent to wait for the C++ standard to be widely available before moving to standard compliance. It also appears very desirable to retain a public domain compiler if at all possible.
Parallelization: Since the vast majority of the user community will not have ready access to this processing mode on a short time-scale, care should be taken that the efforts in this direction do not have a negative impact on other aspects of system readiness.
Performance: There have been encouraging improvements in this area. However, AIPS should not be used as the sole standard for performance comparisons. It is important that available resources in a machine should be utilized wherever possible to achieve performance improvements (e.g. big memory machines should use big memory models).
Native FITS support: Providing the capability of direct application access to FITS format files on disk did not seem to warrant a high priority.
AIPS - AIPS++ interoperability: While the transparent use of some of the AIPS functionality from within AIPS++ might be an effective method of testing applications in the short term, this effort should not be pursued if it results in a significant drain of system resources.
Error images and error propagation: This is potentially a bottomless pit. The framework for the association of an error image or data should be designed and implemented, but we do not advocate extensive work on error propagation within applications at this time.
As part of an overall plan to implement increased functionality, we recognize several areas where new applications would be particularly welcome and competitive: these include mosaicing, wide field imaging and polarimetric imaging.
Robert Braun (NFRA) chair
Jayaram Chengalur (NCRA) not present for this meeting
Roger Foster (NRL) not present for this meeting
Dennis Gannon (Univ. Indiana) not present for this meeting
Walter Jaffe (Univ. Leiden)
Lee Mundy (Univ. Maryland) not present for this meeting
Bob Sault (ATNF)
Lister Stavely-Smith (ATNF)
Dave Shone (NRAL)
Doug Tody (NOAO)
Huib Jan van Langevelde (JIVE)
Tony Willis (DRAO)
Al Wootten (NRAO)
