News
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 000 |
News
|
AIPS++ Report: 1996 July 1- Nov 30
December 15, 1996
This report summarizes the status of the AIPS++ Project at the end of November of 1996. It describes the achievements since 1 July 1996 and gives a list of planned developments for the period from 1 Dec 1996 to 28 February 1997. It also describes long-term plans for the Project. Reports from each active AIPS++ site are included in appendix A.
Development of AIPS++ is proceeding with the primary goal of making a beta release in early 1997 and a limited public release in mid 1997. The next release of AIPS++ is currently planned for mid 1998. More details of the planned release schedule are given below.
In Synthesis, we developed a simple cross-calibration package and also started alpha testing of the synthesis code. This led to a change in the interface to the synthesis code. In addition, many bugs and features have been corrected during the alpha testing (which continues). In addition, we started and have almost completed the extension of the synthesis code to handle spectral line data, including band-pass calibration. Tim Cornwell and Mark Wieringa made a presentation on the design of the synthesis code at the ADASS meeting in Charlottesville, September 1996. We designed and implemented a mechanism for modeling the sky brightness by discrete components. We also wrote a guide to synthesis processing in AIPS++ (see http://aips2.nrao.edu/aips++/docs/user/Synthesis). Finally, we finished MeasurementSet fillers for UVFITS, WSRT, and ATCA.
In Single Dish, we concentrated on the development of an interactive package, called SDCalc, for analysis of single dish spectra. Currently a prototype that allows selection and averaging of spectra is available. Development of SDCalc has been slower than hoped.
In Measures, we made a number of minor changes to and bug fixes of the Measures system. We also started development of a Glish interface to the Units and Measures classes. This will allow conversions to be made from Glish, either from scripts or interactively or via a GUI.
In Visualization and Image Analysis, we completed the extension of Aipsview to handle AIPS++ images and the AIPS++ coordinate system. We started work on a direct Glish interface to the PGPLOT plotting package. Our work on a tool-kit for visualization continued with a visit of John Pixton to ATNF to work with Tom Oosterloo on refining the design and starting upon implementation. We started development of a suite of image analysis routines, including statistics, histograms, and moments, all of which are available from the Glish interface.
In AIPS++ Infrastructure, we decided upon and implemented a consistent approach to providing end-user functionality in AIPS++. This was spurred partly by the alpha testing of the synthesis code. This testing quickly lead to the realization that the existing interface was too complex for end-users. A new, simpler interface was developed as an additional layer in Glish, using what we now call the application object format. In addition, we developed a second version of the AIPS++ Distributed Object system that facilitates binding of C++ functionality to Glish. The redesign was motivated by the desire to simplify as much as possible the coding of such bindings, expecting that application programmers will be the major beneficiaries of a simplification. These methods of providing end-user functionality are described in a memo: http://aips2.nrao.edu/aips++/docs/notes/197/197.html which thus defines the command line user interface of AIPS++.
We worked on improving the non-linear fitting classes, adding considerable functionality and also improving the speed of iteration.
In Glish support, we continued development of Glish in a number of different avenues. Firstly, a number of new facilities have been added to Glish with the major goals of supporting the interactive use of Glish and improving the robustness of scripts written in Glish. Second, we have continued finding and fixing bugs in Glish. We expect this activity to continue at a moderate level (perhaps half of Darrell Schiebel's time) for the next year or so. Third, we have worked on improving the installation of Glish inside the AIPS++ system. Fourth, the user manual for Glish has been updated to describe the new capabilities (such as the tk widgets) and to prepare for release of Glish 2.6.
In Documentation, we finished the framework for user documentation and started providing content. A User Reference Manual describes the functionality available to the end-user of AIPS++ (see http://aips2.nrao.edu/aips++/docs/user/Refman/Refman.html). User level help is written in latex with the principal goal of allowing astronomers to contribute and edit user documentation. The majority of the glish code expected to be used by astronomers is now documented in the Reference Manual. We intend to complete this before the beta release.
In the System area, we continued development on a variety of fronts: support of template instantiations, validation of the system via a test suite, rsh-based check-in and check-out facilities. All test programs in the aips package are run weekly and monitored for successful compilation and execution. The success rate is usually above 95%. We plan to use this mechanism as a way of qualifying updates to the system.
In Management, we organized the first meeting of the Scientific and Technical Advisory Group. This was held in Socorro on November 4 - 6, 1996. The members of the STAG are listed in Appendix D. Presentations were made to the group by members of the AIPS++ Project. The agenda and recommended reading list of material are available from http://aips2.nrao.edu/aips++/aips++/docs/project/stag96.html and http://aips2.nrao.edu/aips++/docs/project/readinglist.html. The group, chaired by Robert Braun, expeditiously produced a report which is available from http://aips2.nrao.edu/aips++/docs/notes/198/198.html. The advice given by the group was generally very useful in helping decide development strategies for the next few years, and has already been taken into account in revising our plans for the release of AIPS++ (see http://aips2.nrao.edu/aips++/docs/project/beta/beta.html). A detailed reply to the comments by the group will be given in Appendix E. It is planned that the STAG will meet again perhaps twice, the next meeting being some months after the Limited Public Release, and then will be replaced in function by an AIPS++ User Group.
The long term plans for the AIPS++ project were first presented in the previous Quarterly report. Here we present an updated list of AIPS++ goals in the next table:
| January 96 | First synthesis application polarization self-calibration and imaging | High | |
| April 96 | Simulation package for Measurement Equation | High | |
| April 96 | First version of tasking system and user environment | High | |
| May 96 | Initial version Measures system | High | |
| October 96 | Initial cross-calibration package | Medium | |
| Q3 96 | Framework for user and programmer documentation complete | High | |
| Q3 96 | First image analysis application (imoment) | Medium | |
| November 96 | First meeting of AIPS++ Scientific and Technical Advisory Group | High | |
| November 96 | Support use of TMS at WSRT: simple calibration and editing of synthesis data present | High | |
| November 96 | Support multi-beam observing at Parkes | High | |
| December 96 | Spectral processing in synthesis code | High | |
| Early 97 | First beta release of AIPS++ (V0.9) | High | |
| Q2 97 | Mosaicing applications | Medium | |
| Mid 97 | Limited public release of AIPS++ (V1.0) | Medium | |
| Q3 97 | Measures support for VLBI | Medium | |
| Q4 97 | Wide-field imaging for VLA data | Medium | |
| Q2 98 | Support GBT commissioning | Medium | |
| Early 98 | Calibration and imaging for VLBI | Medium | |
| Mid 98 | Second release of AIPS++ (V2.0) | Medium | |
| Late 99 | Complete migration of AIPS, Miriad, NewStar capabilities to AIPS++ | Medium | |
As before, the reliability gives an assessment of the probability of meeting that goal. This is based upon a number of factors: how well specified the goal is, the difficulty of the goal, and the intrinsic priority of the goal to AIPS++.
A number of milestones have been passed since the last report (denoted by the mark). Some have been shifted in time.
The previous section gave long-term plans. Here we summarize the expected developments over the next quarter.
In Single Dish support, we will continue the development of SDCalc, adding more functionality in addition to the averaging capability now present.
In Synthesis support, we will continue with alpha testing. We plan to develop a GUI for the imager module in accordance with the STAG's recommendations. Imager will then become the flagship application for the Limited Public Release. We will start on adding VLBI support to the synthesis system.
In Measures, we will continue the development of the GUI front end to the Units and Measures classes.
In Glish support, we will release version 2.6. We expect to continue bug fixing for quite some time.
In AIPS++ Infrastructure, we will make a number of changes and additions to the Image class to support the application development in Image Analysis.
In Visualization and Image Analysis, we will continue development of the visualization tool-kit, and we expect to produce a first application in this time. We will add a number of convenience features to Aipsview, the principal one being the ability to control the line-graphics from a menu. We will incorporate the Glish-PGPLOT binding in the system.
In the System area, we will work towards supporting the beta and limited public releases.
In Documentation, we will continue adding content. We will incorporate tutorials on basic synthesis imaging (drawn from the NRAO Synthesis Imaging workshops initially).
Discussions with the Scientific and Technical Advisory Group helped considerably in refining our release strategy. Following their advice, we plan to make two major releases, one in 1997 and one in 1998. The first is designated as a ``Limited Public Release'' since it will contain only a subset of the functionality expected to be present eventually. The second release, in 1998, is expected to have a more rounded set of capabilities. The limited public release is preceded by an explicit ``beta'' release. The goals for the various releases are as follows:
It is essential that the first impressions made by these releases of AIPS++ be good ones. Hence given a choice between adding functionality and improving quality of what already exists, we will go with the latter. Furthermore, it is vital that these releases be timely. The priority is timeliness, quality, functionality.
Response to a request for volunteers for beta testing has been minimal. The request (send out to the aips2 mail exploder and available from http://aips2.nrao.edu/aips++/mail/aips2/242) was written to emphasize the commitment of time that would be necessary to participate in the beta program. We plan to select a small number of beta sites chosen from consortium sites not currently involved, people who have expressed interest, and members of the STAG. We believe this will give a sufficient number of beta sites.
For more details on the release strategy, see http://aips2.nrao.edu/aips++/docs/project/beta/beta.html.
Resources
The ATNF currently has 5 people working in aips++. These are Neil Killeen (also local manager), Wim Brouw, Mark Calabretta, Tom Oosterloo and Mark Wieringa (see below for fractional time spent on aips++). Additionally, there is a collaboration between the aips++ project and the ATNF headed Parkes 21cm multi-beam receiver project which is contributing substantial effort to using and developing code within aips++. John Pixton (NCSA) is visiting us for November and December to work with Tom Oosterloo on the diplay library (see below).
System
Our weekly inhale woe (see last quarterly report) has been largely resolved. We now build the native system on our specific aips++ Ultra 140 server, but we build the Gnu system on another Ultra 140 (simultaneously). This has resulted in very few inhale hangs in this quarter which has been a very pleasant relief. Thus we did not need to go to a dual leap-frogging system. There are still occaisional problems with the aips++ server (but not related to the inhale) which we are still attempting to track down.
The port to the DEC Alpha (Unix) using the Gnu compiler succeeded and the Unix Alphas at Narrabri and Parkes do weekly inhales now. The Narrabri system is used by Mark Wieringa and the Parkes system by the multi-beam project.
STAG
Bob Sault and Lister Staveley-Smith represented the ATNF at the inaugural STAG meeting. Thanks to them for their efforts.
Individuals
Mark Calabretta's main responsibility is to the code distribution system. His time in the last quarter has been spent on
Mark has spent approximately 50% of his time on aips++ related work. His nominal aips++ allocation is 50%. At present, this level will be sustained indefinitely.
Wim Brouw's responsibility is mainly to designing and implementing the Measure and related classes. His time has been spent as follows.
Wim has spent 30% of his time on aips++ related issues in this quarter (lower level than usual because of 6 weeks overseas) His nominal allocation is approximately 50%. This level will be sustained indefinitely.
Mark Wieringa is a part of the team working on the interferometry related classes and is now back in Narrabri following stays at Socorro. He has spent his aips++ time on
Mark has spent about 50% of his time doing aips++ related work. Mark's involvement in aips++ is negotiated yearly with Narrabri since he has been seconded to the project from the Narrabri computer group. His nominal level is 30%.
Tom Oosterloo is working on visualization and image analysis software. Additionally he has been seconded to the multibeam group to help them with their aips++ software effort.
His time in the last quarter has been spent on
Tom's nominal aips++ allocation is 75%. He has spent about this amount on aips++ in the last quarter.
Neil Killeen spends his aips++ time attending to local ATNF aips++ management issues as well as generating image applications. He has spent his aips++ time on
Despite his claims in the previous quarterly report that he couldn't increase his aips++ time, he has spent some 75% of his time this quarter on it (to the detriment of other things, he claims).
The multibeam received project is using aips++ as its software base. A team consisting of Lister-Staveley Smith (ATNF), Tai-Sheng Ye (ATNF), David Barnes (University of Melbourne) and Tom Oosterloo (ATNF) is working on a data pipeline within aips++ taking data from the telescope format to SD FITS in real time. They report:
Unresolved problems
Remaining goals
Personnel:
We currently have 6 people involved with AIPS++: Dick Crutcher (25%), John Pixton (100%), Harold Ravlin (80%), Doug Roberts (50%), Yanti Maio (50%), and Peter Teuben (25%). Taisheng Ye will join our AIPS++ group in January.
AIPSview.
Most work since June has been on the conversion of AIPSview to compatibility with AIPS++. This has taken about 6 person-months of work, and has involved a rather complete re-writing of the low-level routines in AIPSview, which originally was designed with data being stored in arrays and information about the data being stored in a number of different places on a "need to know" basis. We replaced the low-level file handling and data access mechanisms by creating a new class which describes the data set access methods and which stores every piece of information about a data set in one place. Our FITS reader was re-written and an AIPS++ data-set reader added using AIPS++ classes. Although the initial version of the AIPS++ file reader was rather slow, by changing the retrieval method so that up to a full slice (rather than one pixel or one row) at a time is retrieved greatly improved the performance; this does increase the memory requirement for AIPSview to run, but that is still low enough not to be a problem.
We also incorporated AIPS++ world coordinates into AIPSview, although PGPLOT limitations for axis labeling still exist. The glish interface to AIPSview was extended so full header information may be sent to AIPSview along with the data, and cursor position information may be exported from AIPSview. An image buffer was installed so more than just the current image sent via glish is available for visualization. We also ported AIPSview to compile with the gnu compiler and fully checked the code into the AIPS++ system. New features which have been added include the ability to set the min/max fields of the data display range from the keyboard, a limited ability (the only module that is currently affected is contour drawing) to save and restore configuration settings (both for the current data file and globally), and independent scaling of displays in the X & Y dimensions.
TKPGPLOT.
So that all of the PGPLOT functionality for line drawing and vector graphics would be available from TKglish, we have been writing TK interfaces to each of the 92 PGPLOT functions. This is about 2/3rds finished and will be finished in December, although further work will be necessary for this to be completely useful.
Parallel processing.
We carried out a design study of how AIPS++ computationally intensive tasks could be written for parallel-processor computers and produced a document describing our conclusions, in preparation for beginning AIPS++ parallelization development work early next year.
BIMA filler.
We have worked on writing a filler for BIMA data into AIPS++ and expect to have that working by early December.
System
We purchased a SPARC ULTRA 1 machine to be our AIPS++ development machine at NCSA, which greatly improved compile performance. At Maryland installation difficulties with the inhale procedures have prevented its implementation, but a manual installation (which is updated infrequently) has enabled Teuben to work; the 17 hour AIPS++ compile time on the Maryland SPARC 20 with 64 MB of RAM produces complaints from others who try to use that machine during AIPS++ compiles.
Visits
Doug Roberts spent one week at Socorro to work on parallel processing design for AIPS++.
Yanti Miao spent one week at Charlottesville before beginning the TKPGPLOT work in order to coordinate this work.
Tom Oosterloo visited NCSA for 10 days to work with John Pixton on the visualization toolkit design.
John Pixton began a 7 week visit to ATNF to continue working with Tom Oosterloo. John attended the Visualization 96 conference in San Francisco on his way to Australia.
Dick Crutcher attended the Scientific and Technical Advisory Group meeting in Socorro and gave a presentation on AIPS++ visualization.
Local project members: Ger van Diepen (GVD), Jan Noordam (JEN, local manager), Friso Olnon (FMO).
General
There has been some technical interaction with the Gipsy group in Groningen, who have been invited by Ron Ekers to join the Image Analysis group there. No decisions have been taken.
An extra AIPS++ application programmer at NFRA seems less and less likely now. On the positive side however, our sister institute JIVE will shortly hire one for its own purposes, which will at the very least mean a strengthening of the local AIPS++ capability.
Friso Olnon and Ger van Diepen started a series of workshops to introduce the AIPS++ frameworks and classes to the members of the TMS team and other interested people.
Interaction with TMS
The local AIPS++ group is concentrating on the interface between AIPS++ and the new WSRT on-line system (TMS). In this stage, the bulk of this work is data-conversion: From TMS to the AIPS++ MS (GVD), from MS to the Newstar SCN-file (HJV), and from the existing WSRT archive format to the MS (FMO). The deadline in Febr 1st 1997, when the first module of the new correlator (DZB) arrives in Wbork.
The idea is that the uv-data from the DZB is not converted to the existing WSRT format any more, but directly to the MS. Hopefully, the beta release of AIPS++ will be able enough to do `normal' processing of this data. For this it is imperative that it has full spectral line capability. On the somewhat longer term (summer 1997), the NFRA priority is the WSRT Compound Interferometer mode, which produces very long spectra for a limited number of interferometers.
The WSRT filler is now able to produce time-ordered MeasurementSets from most recent WSRT datasets, from both the continuum and the line back-end. A structural revision using the newest AIPS++ support classes (TableRows, data-type conversions and IO/OS) is postponed till further notice. The main objective for now is to have the WSRT filler doing what the TMS and local AIPS++ people want it to do.
Jan Noordam has mostly been playing with Glish, in order to be able to support the TMS and MFFE commissioning teams with instant functionality.
AIPS++ Site in Dwingeloo
Quite some time has been spent by Friso Olnon, Henk Vosmeijer and Ger van Diepen on the port of AIPS++ to the HP. Some source code had to be changed for this purpose. Now everything works fine. We have abandoned the ObjectCenter compiler. The g++ compiler is now our main compiler. We use xxgdb as a GUI front-end to gdb debugger in a very satisfactory way. Initially it looked as if g++ did not work well with TestCenter, but now it works more or less smoothly. We had an evaluation of the SUN native compiler, but decided not to buy it.
An executable subsystem built on the HP in Dwingeloo, has been exported successfully to the HP at the telescope in Westerbork. We will perform more thorough tests in the coming months as part of the commissioning of the TMS system.
Infrastructure software.
Ger van Diepen has finished the IncrementalStMan and submitted it to the code-cop for approval. This storage manager is the successor of StManMirAIO, the Miriad-like storage manager. Similarly to StManMirAIO values are only stored when they change (like an incremental backup). The main advantage of IncrementalStMan is that it does not keep all values in memory. Instead it stores them in a file. It uses the BucketCache class to divide the file into buckets. Each bucket contains the values of multiple (consecutive) rows. A bucket is self-contained, so looking up a value requires at most one bucket access. Another advantage is that this framework is prepared for storing data in local instead of canonical format.
Apart from the finalization of the IncrementalStMan, the table system has been improved:
Personnel:
The NRAO group is: Tim Cornwell (100%), Bob Garwood (90%), Brian Glendenning (100%), Ralph Marson (100%), Darrell Schiebel (100%), Jeff Uphoff (100%) and Wes Young (90%). Paul Shannon and Shelby Yang left in group in November-December. We have one open position in GB for an astronomer to work with AIPS++ and the GBT, and one in Socorro. In addition, a number of scientists participate at various levels: Alan Bridle, Rick Fisher, Bob Hjellming, Harvey Liszt.
We have also an agreement that two members of the AIPS group will start to devote some time to AIPS++: Pat Murphy (30%), Athol Kemball (25% currently, increasing to 100% by October 97). These time allocations are provisional and subject to change given that NRAO must continue to provide the current high level of user support for AIPS, and must also provide support for the upcoming VSOP mission.
Hardware:
We have purchased two new machines to facilitate AIPS++ support: a Sparc Ultra-1 configured as the AIPS++ canonical machine (http://aips2.nrao.edu/aips++/docs/notes/188/188.html), and a Pentium Pro 200MHz machine running Linux. The latter was acquired in accordance with the STAG's advice that we support Linux as early as possible.
Meetings:
The entire NRAO AIPS++ group attended the ADASS meeting in Charlottesville, where a paper on the design of the synthesis code was presented by Tim Cornwell. A "Birds-of-a-Feather" evening discussion on AIPS and AIPS++ was well attended and elicited considerable interest.
In this section, we give the names of people in the various AIPS++ groups and the nominal fraction of time allocated to AIPS++.
The ATNF group is: Neil Killeen (75%, also local manager), Wim Brouw (50%), Mark Calabretta (50%), Tom Oosterloo (75%) and Mark Wieringa (30%).
The BIMA/NCSA group is: Dick Crutcher (25%), John Pixton (100%), Harold Ravlin (80%), Doug Roberts (50%), Yanti Maio (50%), and Peter Teuben (25%). Taisheng Ye will join the group in January.
The NFRA group is: Ger van Diepen (100%), Jan Noordam (25%), and Friso Olnon (50%).
The NRAO group is: Tim Cornwell (100%), Bob Garwood (90%), Brian Glendenning (100%), Athol Kemball (30% now, rising to 100% by October 1997), Ralph Marson (100%), Pat Murphy (30%), Darrell Schiebel (100%), Jeff Uphoff (100%) and Wes Young (90%). Athol and Pat both have responsibility for maintaining the AIPS system and will be diverted back there if necessary. We have one open position in GB for an astronomer to work with AIPS++ and the GBT, and one in Socorro. In addition, a number of scientists participate at various levels: Alan Bridle, Rick Fisher, Bob Hjellming, Harvey Liszt.
In Single Dish support, we did produce a prototype of the SDCalc single dish analysis application, but with less functionality than expected. We did support the use of AIPS++ for the analysis needs of the Parkes multi-beam survey. We did not finish a reader and a writer for single dish fits (SDFITS), nor did we conduct interoperability tests with other observatories, or write a paper describing the format.
In Synthesis support, we did implement the cross-calibration design and write documentation. We did not add a GUI or fitting of components to both images and visibility data. Cornwell and Wieringa did present a paper on ADASS on the design and implementation of the synthesis code.
In Measures, we did add support for use of IERS bulletins, and the code was reviewed and moved into the aips package.
In Glish support, we did not develop a test suite or make release 2.6. We deferred work on object orientation inside Glish.
In AIPS++ Infrastructure, a Table storage manager, the IncrementalStMan, for handling columns in which the information changes infrequently was completed. We have not yet allowed Records (containers of heterogeneous information) to be stored in TableColumns. We did write and document version 2 of the Distributed Object system. We did develop a class for non-linear fitting, and add constraints to the existing linear fitting classes. We did not design and implement new Gridding and FFT classes to replace the ones currently used, but we did as a temporary measure, re-implement gridding and CLEANing in FORTRAN.
In Visualization and Image Analysis, we did finish incorporation of AIPS++ Image and Coordinates classes into aipsview, and make a beta release of the new aipsview. We did start work on a C++-based tool-kit for visualization, and we did finish an image statistics program.
In the System area, we did not yet start work on improvement of the end-user installation procedures, particularly for installation from binaries alone.
In Documentation, we did finish the user help system and start to write end-user documentation using it. We did finish the initial version of the Programmer's Reference Manual.
In Management, we did organize the first meeting of the Scientific and Technical Advisory Group.
The following are members of the STAG:
Robert Braun NFRA (chair)
Jay Chengalur NCRA/NFRA
Roger Foster NRL
Dennis Gannon U Indiana
Walter Jaffe Univ. Leiden
Lee Mundy U. Maryland
Bob Sault ATNF
Lister Stavely-Smith ATNF
Dave Shone NRAL
Huib van Langevelde JIVE
Tony Willis DRAO
Al Wootten NRAO
General comments:
The report is generally very helpful in providing both perspective on the current state of AIPS++ and good advice on priorities for the future development of AIPS++. I believe the group is right to emphasize that the main task facing AIPS++ now is to move from development to production.
More detailed planning and project definition are both probably needed but this must be balanced against the other role that I play as applications developer. Changes in staffing are needed to remedy this (a replacement hire in Socorro being the most important) as the report rightly notes. I believe that the lack of focus that the group saw in synthesis is also better stated as being due to limitations in staffing. A development plan for synthesis was formulated some time ago (see http://aips2.nrao.edu/aips++/docs/notes/192/192.html). When we are able to carry this out in full, it will provide a large fraction of the functionality needed. On the question of staffing for VLBI processing, we do have a commitment that Athol Kemball will start immediately on a transition from AIPS to AIPS++.
The report also comments on a lack of focus in single dish processing. I believe that this area has not wanted for lack of specifications or requirements documents. The problem has been in our inability to execute them.
AIPS++ Release Process:
The report is very helpful in helping define the release process more clearly. Our current planning documents have been revised accordingly. We have adopted the name Limited Public Release for the mid-1997 release. We also have a target of Mid-1998 for a second release (AIPS++ V2.0).
We read one of the most important pieces of advice to be that for the Limited Public Release, we emphasize polish over functionality. Following the STAG meeting, we have discussed this extensively inside the project. We feel that if followed too strictly, we open ourselves to the criticism that we have simply reproduced the functionality of difmap, say, with a far greater expenditure of resources. Of course, this is not correct but we feel that it is important to demonstrate early on that AIPS++ can do more than one thing in synthesis processing. Nevertheless, we do accept the importance of considerable polish, and using one package, the imager, to define and exercise the entire AIPS++ system.
We will accelerate the development of a Linux port. We believe that an NT port would be premature at the moment, but we are enthusiastic about the possibility within a couple of years.
The list of detailed concerns for the LPR are quite reasonable.
Performance and Resources:
The report is rightly concerned about the performance of AIPS++ when first released. We agree that first impressions are hard to reverse. Timing of the synthesis code shows mixed results. The gridding and Fourier transformation sections are typically a factor of two times slower than the FORTRAN equivalent. The gain solution routines are much slower, perhaps an order of magnitude. We must investigate this with high priority. It is worth noting that an impression of slowness comes partially from the fact that the synthesis code as demonstrated is simply doing more: it is processing all four polarizations simultaneously at some immediate cost in CPU time but at an eventual gain in user time.
The report is concerned about the memory needed to run AIPS++ applications. We chose our target machine carefully with this in mind, after considerable discussions in various forums. We believe that on balance 64Mbyte is still a reasonable number, especially given the recent drop in memory prices. However, we agree that it is vital to limit this number as much as possible, and also to find memory leaks.
Alpha testing has been much more limited than we would have liked. We need to be more aggressive in recruiting alpha testers.
Visualization:
The completion of the binding of PGPLOT to Glish is a high priority and it should be done by the time of the beta release. We do appreciate the need for a more complete graphics package in the longer term. Completion of the image display library is vital if we are to develop high-end visualization capabilities. Given the divergence of opinions inside the project, we appreciate especially the advice on Java.
Glish/User interface:
The concerns of the committee over the Glish user interface are easy to appreciate but we are less clear as to what the advised course of action is. The STAG does not think that a simpler shell on top of Glish is called for. Our own opinion is split on this. We will therefore look into changes to Glish (such as a "with" clause to determine scope) that will help. We do feel that this is one area where significant user testing is vital.
GUIs:
In light of the report's recommendations, we plan first to develop a GUI for one specific application, and then to follow it up with a generic "Auto-GUI" for distributed objects. We don't believe that an AutoGUI by January is feasible.
Tasking:
We agree that asynchronous task execution is needed. We are less clear about the comments about isolating the transport layer. We believe that our current approach provides adequate isolation.
Single Dish processing:
We agree that a multi-dimensional approach is needed eventually but currently we are building what we know how to do. We will revisit the more complicated problem after SDCalc is complete.
Synthesis processing:
We are pleased over the very positive comments on the capabilities of the synthesis package. As expressed above, we agree with the concerns over performance.
The question of aiming towards a difmap-type application needs some careful careful consideration. Difmap is a tightly integrated application, written to do a limited number of things very well. It is not a programming environment, or a general package, as is AIPS++. This means that any AIPS++-based equivalent of difmap will inevitably be more loosely coupled than difmap itself. This does not negate the desire for a difmap-like capability but it does qualify how easy it will be.
Now that Athol Kemball has some time devoted to the AIPS++ project, laying out a development plan for VLBI is his highest priority.
Measures:
We now have a binding of the Units and Measures classes to Glish.
Library:
We agree that hunting and rectifying speed problems and memory leaks in the library code are important. We also accept that the core library must be frozen soon, probably before the Limited Public Release after which we expect to start to receive contributed code.