Report of the AIPS++ User Group
1 March 2001
The Astronomical Information Processing System, AIPS++, is now in its third public release. AIPS++ embodies modern techniques of software development, and contains packages and generic tools, such as the Image Viewer, that can be used for a large range of astronomical data analysis tasks. In addition, AIPS++ has also shown itself to be a flexible environment in which to do new things. Examples include the Parkes multi-beam survey, the software used to test and develop the VLBI correlator at JIVE, the very successful work on distributed messaging at DRAO, and the GBT observer interface. For imaging of radio synthesis data, polarization and mosaicing are treated in a self-consistent way for the first time using the Measurement Equation formalism. The AIPS++ team is also developing parallel versions of some tasks. These parallel tasks will be crucial for processing the large volumes of data from, for example, ALMA.
The main task of AIPS++, however, is the processing and analysis of radio astronomy synthesis data, and this task puts the heaviest demands on the system. While the present release supports the end-to-end processing of VLA data, it is not for the faint hearted. Unfamiliarity with the toolkit-based design, and robustness and performance issues for medium and large size VLA data sets make for slow going. Some of the same issues apply to the single-dish tools that will be used by the GBT and Arecibo.
The AIPS++ User Group suggests that the AIPS++ team should give the following tasks their highest priority for the next one or two development cycles: user outreach and simplified user documentation; as well as further efforts in the areas of debugging, and robustness and efficiency. Below, after some general remarks about the overall project, we list in order of priority the major issues we feel should be addressed by the team.
It is crucial that the first impression a new user gets when starting to use AIPS++ is positive, and that the initial interface presented to the user offers an opportunity to explore AIPS++ before being presented with the Tool Manager. To this end we feel that there should be a Guided Tour of the package. It may well be that the Tour needs to have two threads: simple and advanced. The simple thread would cover all the basic features of the package needed to do simple tasks such as using the Image Viewer to display images, calibrating radio astronomy data, and making synthesis images from UV data sets. The advanced thread would introduce the tool-based philosophy of AIPS++, the Tool Manager, Glish scripts and scripting, and other advanced features of the package the developers want to showcase. The Tour would use canned examples for the most part.
The AIPS++ developers have already introduced the concept of wizards in the package. We feel that wizards may offer one of the best methods for new users to learn to use AIPS++ for their own work. Whereas the Tour provides a generic introduction to the package, a wizard acts as a personal guide to achieve a specific goal in a straightforward way. The map wizard, demonstrated at the User Group meeting, seems to be the right level of sophistication and should be an example for others. The wizards should produce a log of the session as a Glish script that can be edited by the user and re-used. The ImageTool and Dish package will certainly need wizards for beginning users.
Now is the time to make a concerted effort to reach the broader community to use AIPS++. In the near term, the outreach program should emphasize hands-on workshops at major AIPS++ sites (e.g. Socorro, Sydney, and locations in Europe). The workshops should train small groups of new users working closely with the AIPS++ team reducing and analyzing real data, preferably their own. The added benefit of these workshops is that the AIPS++ developers will be able to monitor performance, debug the system, and make it more robust. After completing the workshop, the new trainees would return to their home institutions to train others. As the robustness and capabilities of AIPS++ improve, visits to sites with large numbers of potential users should be fruitful.
The AIPS++ team needs to address the robustness and performance issues raised at the meeting. There is an immediate need to evaluate the speed and performance of AIPS++ for large data sets. The current release does not perform as well as other packages in this area according to several members of the Group.
We feel strongly that a major effort should be placed on the development of the Dish package. This package will be highly visible to the community, as it will be used at the GBT and Arecibo, and will, therefore, have a potentially large impact on the acceptance of AIPS++ in general. There should be very close collaboration between the Dish developers and users at Arecibo and the GBT on the evolution of the interface design and the development of tools. Single dish observing has a long history, and it should be possible to draw on the experience of the staff and users at these observatories.
It seems best to integrate Dish into the overall AIPS++ package as tightly as possible. This probably means using MeasurementSets as the basic data structure. This should allow the use of gridding and imaging tools, for example, and provide a unified approach to combining continuum and line data. This should be given a very high priority.
We see no need to work on fillers for other data formats at this time; concentrate on the GBT and Arecibo for now.
We feel that the Graphical User Interfaces still need to be more intuitive. We recognize that this is an area that is very demanding and time consuming and, therefore, recommend that the AIPS++ developers consider hiring an outside expert to consult on interface design. In the current release, the most successful interfaces are the custom GUIs. The philosophy of the tool manager, for example, is not self-evident, and the advanced thread of the Guided Tour will need to explain the tool-based design of AIPS++ as background to using it.
Where appropriate, a tool interface should include a message line that provides feedback to the user on the current status of the tool, or prompts the user about what to do next, perhaps based on the current context.
We recognize that a tremendous effort has gone into documenting AIPS++. In conjunction with the Guided Tour and Wizards, we feel that the documentation should include a directory of example Glish scripts for common tasks. It seems clear to us that repetitive processing will usually be done with scripts, and example scripts that the user can easily modify will yield results more quickly. We suggest that the AIPS++ group invite the more experienced users to help document the system with the goal of producing a simple step-by-step cookbook for the most obvious reduction tasks.
The proposal to put all documentation in PDF format will considerably simplify preparation, and we recommend that this take place as soon as possible.
We regard the current ImageTool as a very good start, with many good features. This tool has clearly benefited from the custom GUI approach. Providing a message line with status information or prompts to the user should be added as soon as feasible. High priority should be given to increase capabilities to visualize and analyze 3-D data sets, including, fitting spectral features in 3 dimensions, allowing slices to be made, and profile averaging. There should be a way to export fit parameters to a text file. It would also be very useful to be able to export animations. A simple way to reset the graphics seems warranted as well.
As mentioned above, a wizard for the ImageTool would be a great benefit. The wizard can show all the basic functions of the buttons, as well as simple analysis tasks and contour plotting.
Future development directions could include tools to analyze Zeeman splitting as well as a fitter for Galaxy rotation curves.
We strongly support the concept of vertically integrated (wizard) tools like map, and feel that the idea can be extended to other areas of the AIPS++ package. These types of tools will quickly introduce new users to the functionality of AIPS++, and allow them to do some real work with low overhead.
In the near term, we feel that support for combining single-dish and interferometer data should be part of the next phase of development, and effort should continue in support of VLBI processing. Future work should include the ability to transfer phase information from one wavelength to another, which will be needed for the transition to mm-wave work.
We feel that the current level of effort for parallelization within AIPS++ is about right, and we will be following developments in this area closely. Other areas that would probably benefit from parallelization are fringe fitting and the simulator.
Glish has proved itself to be very useful and easy to learn, and much of the day-to-day processing in AIPS++ will very likely be done via Glish scripts. We see no need at this time for major enhancements such as true object orientation, or the addition of a debugger. It seems a bit late to invest too much time in publicizing Glish to a wider audience, although it would be useful if it could be distributed as a separate product. The Glish - tk binding is extremely useful and should be maintained until something better/faster comes along. Upgrading the transport layer to CORBA seems reasonable, but should be transparent to current users, and should not break existing code.
Finally, a high priority should be given to bringing the user manual up to date so that it reflects the current state of the code and covers all its features.
Dana Balsar (NRAO) Tom Pauls (NRL), Chair
Helene Dickel (UIUC) Lister Staveley-Smith (ATNF)
Ed Fomalont (NRAO) Huib van Langevelde (JIVE)
Robert Lucas (IRAM) Francois Viallefond (Obs. de Paris)
Karen O'Neil (NAIC) Tony Willis (DRAO)