 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
This document summarizes the status of the AIPS++ Project at the end of the v1.6 release cycle. Key developments during this cycle include the following:
This report summarizes the status of the AIPS++ Project at the end of the v1.6 development cycle, which ran from approximately 7 May 2001 to 15 November 2001. We discuss the overall status of the project, the milestones achieved in the v1.6 development cycle and current plans for future releases.
AIPS++ is in a final integration phase at present, as is common for large software engineering projects in active deployment. While code growth curves do not form the basis of planning in the project, they provide useful quantitative diagnostic information on the project status. The integration phase is clearly evident in the code growth curve for AIPS++, as depicted in Figure 1. For comparison, a standard code growth curve under canonical software engineering assumptions is shown in Figure 2. As the AIPS++ infrastructure has become more mature and scientifically complete, integration efforts have consumed a greater fraction of project efforts as planned. From the turn-over in code growth, and the project development planning, the integration phase started in earnest around the time of the v1.3 and v1.4 releases and continues through the present.
The code growth measurements also show typical features common to all projects, especially the mid-implementation code reconciliation which occurred immediately prior to the first public release. This dip in the code production rate reflects the discarding of code developed early in the project but which was not used in the subsequent public releases. This is a common mid-implementation adjustment, as shown in the canonical code growth curve. One final point evident in the code growth curve is the slow design and prototyping phase at the beginning of the project, which reflects the uncertainty in the early project period. From the linear implementation phase, the code production rate in AIPS++ has been approximately 13,000-15,000 physical lines of code per developer per year, well above industry standards.
The planning priorities for v1.6 are: i) scientific completeness; ii) usability improvements; iii) robustness, correctness and performance improvements, and iv) continued deployment of the package to an expanded user base. The code development planning for the v1.6 release was undertaken guided by these priorities. Other activities, such as user outreach and testing, have also been scheduled in keeping with these overall objectives.
Scientific completeness in this context means the provision of full end-to-end reduction paths for required observing modes at all consortium telescopes. We have audited these at most consortium telescopes and have identified any missing elements which need to be provided during the integration phase. The strategy in this area is to check in a fixed dataset in the specific observing mode, and associated Glish scripts for their reduction. These scripts verify the end-to-end reduction completeness in the specific modes, and can also be used for testing the continued integrity of the system as part of our correctness monitoring during the development cycle and immediately prior to each release. We also make an attempt to use these scripts in our user cookbook-level documentation, as the example datasets are distributed with the system and can be used in tutorial form.
Usability improvements are a common focus during integration phases. A significant effort was made during v1.6 to improve the uv-data visualization tool, msplot and continuing improvements were also made in the viewer tool. In addition, the cookbook-level user documentation was expanded by adding new chapters for some consortium telescopes, and was re-edited by Neil Killeen (ATNF) to improve substantially the overall consistency and readability. User feedback in the documentation area was solicited where possible from user groups, and incorporated in the edited or revised material. GUI work is notoriously expensive and we have had to balance usability improvements in areas such as the automated GUI, toolmanager, against work in scientific completeness. However, we did expend a considerable effort in understanding and improving our GUI speed and responsiveness which we believe is dominating user perceptions of our GUI interface in general. This proved to be a subtle technical problem, but after evaluating several different possibilities and strategies, we believe we have determined the best course of action in this area. This is being pursued at present by Darrell Scheibel (NRAO). Usability by astronomical users is a subjective issue, and we have taken some care to obtain as broad an ensemble average of opinion as possible across the consortium before undertaking major user interface revisions. To this end, we conducted a user interface survey at the end of the v1.6 development cycle, and these results will be used in guiding future development in this area. At present, the project strategy in this area is to rectify major user interface deficiencies which most users agree are a problem, and then to work with user groups directly in refining their own views on further changes beyond that.
The work in robustness, correctness and performance improvement, in all cases continue longer-term programs in this area within the project. We monitor robustness using test scripts and unit test programs which we run regularly to ensure the health and integrity of the system. We have expanded these during v1.6, and have also made greater use of testing against simulated data where possible.
Performance problems in some areas of the package have become visible in recent development cycles. We have devoted effort in v1.6 to try to isolate and analyze these effects in the package. In almost all cases, the performance problems are found to be due to unrelated code evolution which has had an unnoticed, but negative, impact on performance. These code changes can be innocuous but at times have profound performance implications not obvious on inspection. This is a very common code development problem. An additional complication in the case of radio astronomy reduction packages is the large set of parameters on which performance may depend. This includes, for example, the uv-data set size, the imaging algorithm employed, the image size, and a host of our user-adjustable parameters. Frequently users encounter and flag these performance issues in new areas of parameter space, and most packages rely on this feedback to monitor and correct performance drift of this type. This has been happening in AIPS++ as well, but we have also tried to be more pro-active in this area by developing performance benchmarks we can run regularly, like our correctness benchmarks, to catch performance drift before it is noticed by our users. This benchmark effort was started in earnest in v1.6, but will continue in several subsequent development cycles. Performance analysis requires good performance tools, and we have suffered to some extent from compiler support problems for the tools we have traditionally used in this area in the past. We have worked actively on trying to work around this problem by finding alternatives where possible. We take performance questions very seriously, and will rectify any major problems in this area.
In the area of package deployment, we have continued our efforts in user outreach and user training, both through interaction with user test groups at several consortium sites, and by conducting user tutorials outside the consortium as requested. This is an important aspect of the integration phase, in which it is particularly important to get user feedback on usability and integration efforts. This is part of a continuing transition to full operational status, and the increasing workload in this area has necessitated the formation of an Operations Division within AIPS++ to coordinate and handle all activities related to the expanding user base. This was established in October, 2001, and is headed by Joe McMullin.
Although the project is in the final integration phase for most consortium telescopes, the package also has to be responsive to new instruments under development in the community. Many of the calibration and imaging features in AIPS++ were specifically added early on in the project to support these anticipated telescopes, and AIPS++ has to make sure that it can meet the needs of these instruments as they move closer to construction. The particular new telescopes that are immediately relevant are ALMA, LOFAR and the EVLA.
During the v1.6 development cycle, AIPS++ took several steps to establish a closer relationship with ALMA. In response to an ALMA request in mid-2001, we have proposed a closer mechanism for ALMA-AIPS++ interaction, including ALMA representation on the AIPS++ Executive Committee. In addition, we agreed to an evaluation of AIPS++ for ALMA reduction, using test millimeter spectroscopic data from the IRAM interferometer on Plateau de Bure, in order to provide sufficient information for the ALMA project decision on off-line package adoption. This test started in the Fall of 2001, and will continue through the end of April, 2002.
Developments for LOFAR/SKA are more mixed. At present the community efforts in SKA are distributed and quite diverse, especially in the area of simulation and algorithm development. The reduction algorithms have much in common with aspects of EVLA imaging, and in this area we are in a much stronger position to develop common capabilities within AIPS++, as the EVLA has adopted AIPS++ as the reduction package.
We have had queries regarding AIPS++ adoption from other instruments during this cycle, including the SMA, who are using AIPS++ in commissioning and imaging, but who have yet to make a final decision regarding off-line reduction. We have collaborated with some developers from the SMA in their commissioning use of AIPS++ in this regard.
The JCMT and Arecibo are similarly involved in either using or evaluating AIPS++ in their data reduction efforts. Both sites have regular development builds, and are making good progress in using the system, and have provided documentation for user-level reduction of their data in AIPS++.
At the end of the v1.6 development cycle, Ralph Marson (NRAO) took an internal promotion transfer to the ALMA project, and left AIPS++ in early December, 2001. His position is being advertised at present and will be re-filled. Joe McMullin (NRAO) moved to Socorro from Charlottesville and became the deputy project manager in early August, 2001. ASTRON participation in AIPS++ has declined during v1.6. Ger van Diepen remains at 50%, as he has done for the past few development cycles, while Oleg Smirnov and Jan Noordam have moved to work on LOFAR. This leaves a big gap in coordinating testing of the package on the Westerbork telescope, and in some areas of the main package development. BIMA/NCSA has increased their FTE investment in AIPS++ during the v1.6 development cycle, and this has had strong benefits for BIMA development and the main package as a whole. Jodrell Bank have advertised a position to work within AIPS++; this is being filled at present.
In table below, we show the workload per consortium partner for the v1.6 development cycle The work is assigned in the planning for each cycle in units of weeks. Defect fixing is set at a fixed fraction of the overall time per developer. Note that the NCSA Alliance provides funding for two positions at NRAO. During the v1.6 cycle these were being re-hired, and one position has subsequently been filled by Sanjay Bhatnagar.
Like most academic software projects, AIPS++ has always been under-funded by some substantial margin. Compared to larger astronomical institutions, such as ESO or STScI, we may be under-funded by a factor of two or three given the scope of the project. This is becoming particularly noticeable in the user support area, and in general operations. The target market for the package is large, and the flux of defects and user support requests has risen sharply as the package has found increasing scientific use. Within NRAO for example, AIPS++ developers now spend a great deal of time in direct user interaction with scientists and user test groups. This is an expected and healthy aspect of the integration phase. The project as a whole has a current allocation of 30% to address defect correction and user support, but this is being exceeded in some areas of the project in practice. In addition, the number of outside sites developing with AIPS++ has also risen, precipitating some developer support costs in setting up builds and in providing rudimentary code development advice. User training and tutorials, though important, are costly, and we need additional dedicated staff in operations as a priority if we are to continue to service user support requests in a responsive manner. This has been very difficult to do in some areas of the package during the v1.6 cycle, as these needs have escalated.
Expectations on software usability are also higher today than they were in the past due to substantial advances in the intuitive nature of packages developed for personal computers during this period. Increasing requests for highly intuitive user interfaces for AIPS++ could represent a significant cost in the future if they are to approach the levels of those in the commercial market. The project will need to take particular care in managing requirements in this area while still meeting user needs.
This section provides a more detailed listing of development in AIPS++ in this development cycle. These are sub-divided by project area.
In Operations, a separate Division was formed within AIPS++ in late October 2001. This division integrated numerous day-to-day activities during an AIPS++ release cycle. The key personnel for this division are Joe McMullin and Wes Young. We review the activities within the key areas of responsibility below.
In Synthesis development a number of targets were assigned in v1.6 to address scientific completeness issues at individual consortium telescopes. This included improvements to the fillers, calibration tools and test scripts for BIMA, the ATCA and the VLA. For the ATCA, specific tools were added to improve the support for polarization self-calibration. In collaboration with the SMA, improvements were made to the FITS-IDI filler, including support for a greater range of MeasurementSet (MS) sub-tables.
A significant effort was made to upgrade the msplot tool for uv-data visualization this cycle. This tool is used heavily by the current scientific users of the package and there were many pending requests for enhancements and defect fixes. It was re-engineered in places to improve robustness, and many new features were added in response to user requests. The revised tool has been used actively since then, and this investment of effort has improved the scientific completeness of end-to-end reduction considerably.
Support was expanded for heterogeneous spectral windows in the synthesis system, including proper handling of variable-shaped calibrated data columns. This capability was always incorporated in the system design, but had not been actively tested until BIMA data were fully processed in the system. This capability is needed by many telescopes within the consortium however. Additional work in calibration concerned improvements to the calibration table access classes to allow full incorporation of parametrized solvers, such as those already developed for the ionosphere and VLBI fringe-fitting.
During the v1.6 cycle, an evaluation test of AIPS++ for ALMA was agreed with the ALMA project using test data from the IRAM interferometer on Plateau de Bure. During this cycle, the filler for ALMA-TI data was started, Dominique Broguiere (IRAM) visited NRAO for two weeks, and an evaluation of the IRAM algorithms was started. This test will run through April 2002.
In imaging, a substantial effort was devoted to performance monitoring and enhancement. This work is ongoing. This included some gridding optimization for both the wide-field and the narrow-band spectral-line case. A imaging test suite using simulated data was developed to monitor imager correctness, and will be used in routine imager correctness testing in v1.7 and above.
In Single dish, this release cycle saw major development by the single dish group (Braatz, Garwood, McMullin) mainly in response to the commissioning efforts of the GBT. AIPS++ is an integral part of the GBT. The filler has tracked the evolving FITS output of GBT devices, assembling them into actual astronomical observations. A real-time display system was implemented for assessing data quality for continuum and spectral line observations, providing feedback to the GBT M&C system. Calibration routines were developed for the initial modes of GBT operation and a new command line interface was implemented to improve ease of use and broaden the user base.
Main stream DISH development also continued. In particular, numerous infrastructure changes were made, in response to User Group recommendations, to merge single dish and interferometric development. A new display tool was unveiled, utilizing/sharing image module utilities. True multi-component gaussian fit routines were also implemented. New tools were also developed for calibrating and analyzing continuum OTF maps; the result was the highest dynamic range image ever produced by a single dish telescope. In addition, a significant realization of AIPS++ generalization of telescope data was attained through the first combination of single dish (GBT) and interferometric (VLA) data.
Significant outreach efforts were initiated or maintained. Numerous demos and presentations were made at astronomical meetings. A lecture on AIPS++ was presented at a single dish summer school. Demos were also conducted at NRAO-CV to inform/involve staff of AIPS++ and GBT commissioning. Contact with the JCMT was also initiated, culminating in a scheduled meeting in Jan 02.
In Image analysis, the following work was completed:
In Visualization, work continued in work on both image-plane and uv-plane visualization. In uv-data visualization, the initial version of a gridded (TVFLAG-like) display library tool for MeasurementSet data-MSAsRaster-has been implemented. This object is capable of being used via the normal viewer interface, but is also intended to allow embedding and reuse in custom user interfaces (such as msplot) that are more specifically oriented toward visibility data. The intention is to move the compute- and I/O-intensive tasks of msplot out of glish into more efficient and larger-capacity C++ modules.
MSAsRaster displays visibility data as a 5-axis hypercube, with axes of time slot, baseline, channel, polarization, and spectral window. The axes can be assigned arbitrarily to the display or to animation/slice controls.
Future effort will focus on editing/flagging capability, selection of MS data, and world coordinates for axis values. MSAsRaster was not included in the release until these are available, although it now appears in the post-release development master. There are also plans for complementary plot-like viewer components.
In image-plane visualization, this development cycle was dedicated towards improving consistency in the interface. Image analysis is now directly accessible from the viewer tool. Some time was also spent on designing a new infrastructure to accomodate on-the-fly regridding, more flexible animation as well as fixing other existing limitations and defects. An initial WorldCanvas based on ths has been implemented. A colorbar/wedge has been added to show color-intensity mappings. Handling of table overlays (skycatalog) was improved and the viewer module documentation was restructured.
In Parallelization and high-performance computing, effort continued though this was hampered by the vacant positions in this area at NRAO and NCSA/BIMA. Anuj Sarma (NCSA) continued with profiling of the parallel wide-field imaging application. We also continued to maintain the SGI build at NRAO, and there was some work on the parallelization infrastructure. Several of these vacant positions have since been filled.
In Documentation, the primary focus has been on the Getting Results cookbook. New chapters have been added during v1.6 and the entire cookbook was edited by Neil Killeen (ATNF) for consistency and style. This re-editing substantially improved the user documentation in this area.
In the General infrastructure, there were significant improvements in the Functionals and Fitting classes by Wim Brouw (ATNF). Ger van Diepen (ASTRON) added the Table system storage managers required for data compression, and also added facilities for deep copying of Tables. There were also improvements in LEL, Lattices and masks by a collaboration between Ger van Diepen (ASTRON) and Neil Killeen (ATNF).
Planning for the next development cycle, version 1.7 to be released in June 2002, is now complete. Feedback from the various user groups has been very influential in determining the priorities.
Scientific completeness Demonstrated end-to-end reduction capabilities for targeted instruments in all scientifically important observing and reduction modes.
Usability by the astronomical community Quality of the user interface, applications presentation and user documentation.
Robustness, correctness and accuracy Prove the correctness and robustness of existing capabilities and ensure comparable performance to other disk-based packages.
Continued deployment to an expanded user base Continue to increase the scientific user base for AIPS++.
Performance Continue to measure and improve the performance of AIPS++ applications.
Detailed information may be found at:
http://aips2.nrao.edu/daily/docs/notes/248/248.html.
The upgraded WSRT (and the JIVE correlator operations) continue to
rely heavily on AIPS++
he WSRT has finally switched to MS2, and a
newer version of AIPS++he on-line system (TMS) uses AIPS++ Tables, Measures and Glish, and MS2uvfits for data export. Data
inspection is done with (at least) three different uv-data
visualisation tools, which have been written locally with Glish and
AIPS++ modules.
However, it continues to be difficult to entice local astronomers to
start doing their own data reduction with AIPS++hey are used to
the older packages, and feel (rightly or wrongly) that these serve
their everyday needs better, especially in uv-data processing. The
argument that all the older packages are frozen does not appear strong
enough for them to make the investment in the only package that is
being actively developed.
AIPS++ also plays an important role in the design of the new low-frequency radio-telescope LOFAR. Glish is used extensively for 'analytic' simulations, and the AIPS++ synthesis simulator should play a role in simulations of actual data, since it has the most complete instrument model (Measurement Equation). The prototype of the LOFAR processing system will rely heavily on AIPS++ modules.
As the LOFAR project accelerates, the pressure to divert ASTRON programmers away from AIPS++ work increases.
Ger van Diepen and Arthur Coolen have contributed mostly to the AIPS++ infrastructure, and between them they keep the local site going. Ger continues maintaining and (modestly) upgrading the various data converters. Oleg Smirnov has finished the synthesis applications flagger and ionosphere calibration. Tom Oosterloo uses AIPS++ (modules) for WSRT off-line processing, and Jan Noordam does the same for LOFAR/SKA design and simulation. Between them they promote and assist local astronomers in the use of AIPS++.
For release 1.6, the ASTRON contribution in FTE's was as follows: Ger van Diepen, 50%, Oleg Smirnov 25%, Jan Noordam 10%.
Various defects and enhancements requests have been resolved.
Oleg has completed numerous revisions of the interface, arising from discussions during the Green Bank meeting, and from further hand-on experience of individual users. Generally cleaned up the interface, completed documentation, and provided an autoflag_meta.g.
He has been interacting with a number of users of autoflag. This has resulted in a number of improvements and new features, as well as a few defects that were fixed.
Work on second-order corrections was halted, pending an integration of FVisJones into the synthesis package. Over the summer, Oleg supervised a trainee, who did some in-depth exploration of GPS vs. PIM data. This has resulted in a number of insights into the problems of instrumental bias and PIM corrections, which should save some effort later, if and when GPS-based corrections are actually incorporated into AIPS++.
This cycle we had Neil Killeen, Wim Brouw, Malte Marquarding and Mark Wieringa.
Uptake of the system is continuing to improve. This is mainly through our efforts to help people with scientific scripting using the generic tool kit. In particular, we ran practical sessions at the ATNF synthesis workshop this year to allow the students to see what they could with the system. They responded positively to this.
Ben Chan (University of Sydney) has helped us with pushing Compact Array data through the system. We have encountered a range of problems; there are still some outstanding ones before we can encourage generic users to process end-to-end in the system. I hope these will be resolved very early in the next development cycle.
Wim's time (60%) went on
Neil's time (60%) went on:
Malte spent his time (95%) on:
Mark's time (25%) was spent on:
We continue to work in our four main areas of development: enabling calibration of BIMA data, support for processing on parallel platforms, OpenGL-based visualization, and user outreach. This cycle, we placed primary focus on BIMA calibration and user outreach. These efforts included contributions at NCSA from Ray Plante (local manager, 50%), Dave Mehringer (site installation manager, 50%), Harold Ravlin (50%), Anuj Sarma (50%), and Paulo Cortes. In addition, Peter Teuben of the University of Maryland also contributed part time to development and testing.
Plante began improvements to the simulator tool to allow gains to vary according to given functions. This was done in the context of the new ``light-weight'' design process which has proved quite effective. Delivered as part of this work were two new function classes representing Chebyshev and Butterworth functions which are available as glish tools.
Mehringer developed the imagerpositiontest tool for testing the validity of imager results. This tool creates a truth image which is then transformed into a uv dataset by the simulator tool and then imaged. The positions of the sources in the resulting image are then compared with those in the model to determine if the imaging tasks have produced valid results. The tools imager and pimager can be tested in this way.
Mehringer finished the implementation of basic BIMA calibration through two new tools: bimams and bimacalibrater. bimacalibrater is a user-level tool that applies the standard calibrator tool appropriately for BIMA data. In particular, it does phase calibration on each sideband separately via windows containing the sideband averages. It then copies the solutions to the spectral line windows. bimams is a layer on top of the ms tool which helps bimacalibrater pull out the data and information it needs to carry out the calibration. Mehringer has incorporated this functionality into the bima test script.
To support specialized calibration, Plante made a number of improvements to the BIMA filler. A major change was proper support for multi-polarization data where polarizations are not observed simultaneously. System temperatures are loaded and used to calculate weights that can be properly used in calibration and imaging. A few useability improvements were made, including the ability to detect whether the data is raw, calibrated or otherwise processed to set the default selections appropriately.
Plante continued work on the gainpolyfitter tool, building on the implementation started by Ravlin. In particular, he generalized the internal infrastructure to allow the tool to be configured for use by other telescopes; through this infrastructure, he was able to add support for multiple sideband windows.
BIMA calibration was demonstrated to the BIMA Board in September 2001.
Sarma continued general timing tests on the NCSA Origin 2000 and cluster platforms using the widefield imaging algortithm. With Cortes, he began gaining expertise with the PABLO profiling package.
Overall, effort on this area was low due to loss of person-power and expertise over the last year. We expect this to improve in the next cycle.
As part of an effort to support large-pixel displays, Ravlin completed an OpenGL DisplayCanvas class.
Plante and Sarma continued their series of short tutorials at the local Illinois BIMA meetings.
* Continued serving as the AIPS++ site installation manager. maintained builds on local Solaris and Linux platforms and NCSA Linux and SGI IRIX platforms.
* Developed bimacalibrater tool for calibration of BIMA data. The idea behind this tool is to hold several datasets of different roles (target source, phase calibrator, flux calibrator, etc.) and to have its functions be smart enough to calibrate data properly with minimal input from the user.
* Developed imagerpositiontest tool for testing validity of imager results. This tool creates a truth image which is then tranformed into a uv dataset by the simulator tool and then imaged. The positions of the sources in the resulting image are then compared with those in the model to determine if the imaging tasks have prodcued valid results. The tools imager and pimager can be tested in this way.
During this development cycle, McMullin has assumed several coordination roles in taking over the role of Deputy Project Manager. His primary responsibilities are to oversee and contribute towards the single dish development of AIPS++, particularly the Green Bank Telescope commissioning support; in addition, he is reponsible for the newly founded operations division which handles the consortium build administration, release preparation and distribution, and user support/outreach. Specifically, Joe worked on the following tasks during this cycle:
Jim Braatz' primary responsibilities are to manage and support the Green Bank installation of AIPS++, support GBT operations, develop software for analysis of GBT spectroscopic and continuum observations, and assist with GBT commissioning. Specifically, Jim worked on the following tasks during this cycle:
Bob Garwood's primary responsibility is to contribute towards the single dish work in AIPS++. His contributions remains focussed the GBT filler and the single dish data access tool (sditerator). In addition to these duties he is responsible for the maintenance and enhancement of the FITS classes and the data conversion tools (to and from SDFITS). He is also the chief code cop.
Over the past development cycle he has done the following:
Tim provided technical assistance with scientific project by Shepherd, Maddalena and McMullin (2002) to combine GBT and VLA data in a joint image. This involved some changes in the supported package capabilities in this area.
Tim and Amos Yahil (SUNY) continued to work on the incorporation of Pixon image deconvolution into AIPS++. The implementation calls IDL from inside AIPS++ routines. Both speed and performance are excellent. At the moment, only single dish data and image plane convolution can be thus treated. Tim continues to work on synthesis data reduction using Pixons.
I have been involved in the following for the past quarter:
In dragon tool now the masking capabilities are increased. We have an automatic masking or interactive one at every time a self-calibration is performed.
A good fraction of my time was devoted to usage of imager (and to a lesser extent simulator) and fixing its bugs. Also a fair amount of profiling has been done to locate where imager time is being used and a couple of unexpected blocks were found.
Some time was devoted to the alma-test and getting ready to process data from the Plateau de Bure telescope. IRAM's model for atmospheric water vapour correction has been incorporated in AIPS++.
* Initial implementation of MSAsRaster.
* Various display infrastructure revisions, including: - more complete exception trapping - plugging a memory leak of cached drawings - alignment correction of drawn images (WorldCanvas) and axes (WorldAxesDD) - edge pixel drawing in Interp2D - slider GUI value control from within the library. * pending revisions (under development, not yet checked in): - allowing mouse handlers like Zoomer to receive events off draw area - eliminating phantom images from those tools, etc. - output capabilities for Attribute values - extensions to DParameters (more to do) - design discussions on WC coordinate system and DL->glish event issues
For the v1.6 development cycle, George Moellenbrock contributed as follows:
In the area of synthesis (and related) development:
In the area user relations:
During this development cycle most of my time was spent understanding event throughput of the Glish transport layer. As the complexity of the AIPS++ graphical user interface (GUI) has increased, the transport layer has failed to keep up. This is particularly true when the GUI is initially created simply because a huge number of events are required to create complex GUIs in Glish/Tk.
I explored many options while trying to develop a solution to this problem. These included:
In addition, about a dozen Glish related defects were fixed. These ranged from crashes to output problems.
