 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
T.J. Cornwell
1998 March 10
A postscript version of this note is available.This is in response to the second report of the AIPS++ Scientific and Technical Advisory Group (AIPS++ Note 218). We would like to thank the group for their generous donation of time, and we appreciate their advice on numerous issues connected with AIPS++. Overall, we do find the report to be helpful in directing AIPS++, though we are disturbed by the complete change in recommendation from the last report in one key area. We will address this point in the next section.
We are glad that the STAG recognizes the process made since the last meeting. Progress has indeed occurred in many areas, along the lines recommended in the last STAG report, such as stressing unique functionality and improving user interfaces.
There are three particular areas of concern that the STAG note in the introduction: first, the need for planning of the delivery of package functionality, second, the need for an improved user interface, and third, the question of the optimum strategy to garner support in the user community. We discuss these in turn.
First, we spend considerable effort on both planning and tracking development of AIPS++ as a whole and in the various components. Development plans for AIPS++ and for various components may be found in the AIPS++ Notes series. In particular, our release strategy, which follows the overall directions recommended by the STAG at the last meeting, is detailed in the AIPS++ Notes and has been regularly described in the AIPS++ Quarterly Reports. Tracking of existing tasks and allocation of new tasks is performed weekly, and list of accomplishments are given in the Quarterly Reports.
Second, our beta testing did indeed tell us that the user interface was too difficult for most users. Following the first beta release, we embarked upon an initiative to write GUIs for AIPS++ applications. As as result, GUIS are now being placed into use and our testers at the AOC and elsewhere are giving useful feedback. We anticipate that GUIs will be one of the major deliverables in the next, upcoming beta release. Our plans for an improved command line interface wait on our experience with the GUIs since we would finalize the GUIs before proceeding much with the former. Our current expectation is that a parameter-setting shell along the lines that we presented to the STAG can be placed in operation without too much additional work beyond that in the GUI.
Moving on to the third point of the strategy for garnering user community support, we think that initiating development of a VLA filler now is an excellent idea and we will start devoting some effort to the filler in the near future. We hope that this will send a reassuring message about our commitment to establishing VLA data reduction capabilities in AIPS++ as soon as possible. However, in a change from the last report, the STAG now believes that full end-to-end data reduction capability for all the consortium telescopes is a prerequisite for a first public release. After considerable discussion inside the Project, we are not convinced that this change would be wise. Our overall development approach has been to aim initially for highly targeted and unique applications that will attract key users who will lead the way to eventual adoption and acceptance of the package by others. There are a number of examples of packages that have evolved this way: AIPS, MIRIAD, difmap. In none of the initial versions of these packages could full end-to-end reduction for the relevant telescopes be accomodated. Instead, key capabilities attracted new users, and the packages subsequently expanded in functionality. The alternative as recommended by the STAG, of deferring the first release until we can support a full end-to-end data reduction path would prevent us from getting the support of those people for whom the package does have interesting capabilities. We identify the following as being deliverable as part of the first release: a complete data path starting from data initially calibrated elsewhere, incorporating sophisticated enhancements to calibration and novel imaging capabilities, and finishing with publication quality plots. Once this data path is in place, works well, allows new science, and the user interfaces are well-established, then we will work back towards providing full data reduction capabilities. Our reading of the North American community, via for example the NRAO Visiting and Users' Committees, is that a considerable majority of the interested parties favor this approach. However, in light of the STAG's change of mind from the previous report, this is an issue that we will revisit in our upcoming meetings with North American review bodies. The implications of the STAG's recommendations have the most impact for VLA data reduction since the filler and the various ancillary tools are a significant development cost. The situation with regard to supporting WSRT data reduction is somewhat different, since the existing package, NEWSTAR, is now being phased out in favor of AIPS++, and we have a commitment to provide calibration and imaging capabilities for WSRT on a short timescale. This is possible because the filler is largely in place, and since the tools required to support full calibration are less onerous to develop.
releases is realistic and will avoid exhausting
our testers' interest and patience, as well as our ability to
respond.
