 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
AipsView has a reasonable overall functionality but has inadequate publishable line graphics functionality (e.g. choice of fonts, tiling, annotation). It is probably best to freeze development and concentrate on the Glish/TK widgets and the image display library.
Completing the Glish/TK interface should have very high priority. This should be in place for the January 1997 release. It is not completely clear whether it will yield adequate line-drawing functionality from Glish. The group felt it was important to keep searching for more capable substitutes for pgplot on a 1 to 2 year timescale.
The image display library should receive fairly high priority, since interactivity of DOs depends on it. Early 1998 might be a reasonable target date for completion.
The group did not feel that it was advisable to adopt Java in the short term, but felt it important to keep track of commercial developments in this area.
Glish is one of the best features of AIPS++ and it provides a powerful capability for object oriented programming at the level of interpreted scripts. However, Glish as it currently stands, is not well suited as a CLI, and something more approachable is needed to avoid turning off users, especially novice users. GUIs provide one way of addressing the problem. Both application GUIs and auto-generated GUIs for controlling Glish level modules or objects will help. If much interactive use of the CLI is anticipated then a streamlined command line interface to Glish is needed, similar to that provided by existing astronomical data system shells and Unix shells. It should be easy to do simple, common operations without a lot of typing. Addressing this shortcoming has a very high priority before the mid-1997 public release. We wish to stress, however, that we are not recommending construction of a complete layer on top of Glish.
There is also a need for real feed-back from novice users to evaluate user satisfaction. It would be very fruitful for the developers to spend some time with existing systems, like IDL, to gain insight into successful CLI design.
Clearly it is critical that Glish be made robust against crashing.
Some suggestions of specific methods to reduce unnecessary typing are:
Specific goals for the mid-1997 release might be a number of standard Glish closure scripts that bundle standard imager functionalities. These should be accompanied with documentation, reliable failure modes, and GUIs. The logging of processing history from both Glish and DOs should also be enabled.
There should be an auto-GUI or standard GUI for all DOs and all ``standard'' Glish scripts (preferably in time for the January 1997 release).
We recommend development of simple GUIs created by DOs to enable interaction with asynchronous processes (preferably in time for the mid-1997 release).
Work should be done on developing a standardized GUI for major applications.
A capability needs to be added to allow large jobs to execute in the background (similar to ampersand in Unix). This should include provision for monitoring the progress of background jobs, interacting with jobs which require input, aborting jobs, and passing data back to the foreground context.
Ideally AIPS++ should not be tied to Glish as the only mechanism for managing intermodule (distributed object) communications. More powerful messaging system standards are sure to be important in the future, e.g. CORBA. The messaging subsystem should be abstracted and isolated so that new messaging system technology can be substituted in the future. In addition to protecting AIPS++ from technological evolution in messaging systems, this is important if AIPS++ is to be an open system capable of communicating with external non-AIPS software.
Some modest level of effort needs to be devoted to the discussion of parallelization, including the use of multi-threads, but this is clearly a goal for a future release. Taking advantage of specific software development talent on an as-needed basis is probably realistic at this point.
Within the modest overall priority of this topic, most attention should be given to supporting parallelization within small multi-processor machines, which are likely to become increasingly common within the general user community.
Some progress is being made at last on the single dish data analysis front. The committee was shown a prototype application (SDCalc) which had a good user interface for operations on single scans. While we felt this was a good prototyping experience we felt it lacked the scope necessary to deal with multi-dimensional datasets and the high data rates which will, in general, be needed. The committee strongly recommends a multi-dimensional approach which is more solidly based on the standard AIPS++ MeasurementSet. In particular, we envision users will need sophisticated bulk-analysis tools to cope with large datasets with several of the following dimensions: two spatial, one or more frequency, one polarization, one beam and one time. The flexibility of the MeasurementSet can accommodate these needs more easily than a FITS datacube approach. A multi-dimensional user interface approach will make this flood of data more comprehensible to the astronomer.
One area of synergy which appears bypassed is the interface between traditional single dish processing and the AipsView visualization world. For example, AipsView is capable of selecting and creating spectra from datacubes. These spectra, or collections of spectra, should be written into a MeasurementSet which could then be manipulated by SDCalc.
There was substantial concern that the envisioned needs of the GBT might not be met on an appropriate timescale.
All AIPS++ releases, starting with January 1997 should contain full application oriented documentation to enable users to run AIPS++ effectively. This documentation should include fully-worked examples using a test data set shipped with the release, and a description of the methodology being used by each application. The documentation should preferably be shipped with the software, so that network problems do not get in the way of the user. There should be an extensive tutorial on general AIPS++ and Glish use, including annotated scripts. Specific requirements include:
Polarimetric self-calibration and NNLS imaging are the jewels of the January release. This capacity is unique. A good implementation of these is most important. The speed of the processing, however, is a major concern. Conventional self-calibration and deconvolution should not be a factor of 5 slower than comparable systems in the January release, and preferably no slower than a factor of 2 by the mid-1997 release. If these speed requirements can be met, then spectral-line, multi-IF/multi-frequency processing should be addressed. Mosaicing and wide-field imaging are very desirable but should have lower priority in both January and mid-1997 releases.
Extending the above synthesis processing to include the functionality and user friendly interface of DIFMAP would be valuable for the VLBI community, as well as being of wider appeal among synthesis imagers. Once a better user interface has been produced, this should be comparatively inexpensive in relation to the product that can be delivered. DIFMAP should be used as a reference for performance.
Planning for VLBI processing is in its infancy within the project. The current requirements and planning for VLBI processing do not appear to be well integrated within the project. We appreciate the lack of manpower currently commited. However, longer term planning for VLBI is sorely needed.
The arrival of the measures toolbox was a welcome development. Full support of VLBI and pulsar applications will be important additions for the coming months. There is some concern regarding the need for extensive retrofitting of code to introduce the toolkit at all the necessary levels. Tools like this would ideally have been available in the early stage of application development. At this moment several application development projects can still profit from continuing effort in this area, notably VLBI and interferometer calibration.
We can see good reason to make some of the functionality of this system available at the user interface level in an early stage. Priority might be given to making the unit system available, in particular the use of physical constant and unit conversions from Glish. Furthermore, coordinate transformation (e.g. from B1950 to J2000) would be interesting as well as Doppler calculation (e.g. topocentric to LSR).
It is important that all physical constants, coordinate systems and methods of conversion be fully documented with appropriate references.
The AIPS++ library provides the programmer with a rich and versatile toolkit. At present, the main pending developments in the Table System part of the library appear to be ensuring that features such as multi-user synchronization and locking are implemented.
There are two critical items with regard to the libraries: Firstly, it is vital that memory leaks be hunted down and eliminated. Otherwise mysterious system crashes are sure to occur. Secondly, because there appear to be misgivings that AIPS++ applications are slow compared to the competition, every effort should be made to ensure that the library classes are optimally designed for maximum speed.
The time may be nearing when the core functionality of the library should be frozen, with a switch of priority to writing applications.