Project News Summary
AIPS++ is a project of the
Project News Summary
The appearance of AIPS++ is currently undergoing major changes. During beta testing last year, most people found the combination of the Glish system and the synthesis application, imager, too difficult to use. Poor documentation for end-users did nothing to help. In response to these problems, we decided to increase the priority of adding graphical user interfaces, changing the packaging of the synthesis application, and writing end-user documentation. All three initiatives are now coming to fruition.
We have written a standard graphical user interface for objects in AIPS++. Each object can have a GUI that is generated from a simple set of Glish commands. Hence the GUIs are consistent between different types of objects, and also easy to generate, requiring only that the programmer write a "meta-information" file. We are now alpha-testing this GUI framework and will describe it further in a future issue.
Meanwhile, we have also changed the packaging of the synthesis code, splitting it into a number of objects, the principal ones being sky for imaging and cal for calibration. They are now being tested, together with their associated GUIs. The imaging application, sky , has much more functionality than the application, imager, that it replaces.
Finally, since the look and feel of AIPS++ is becoming more clearly defined, we have now embarked upon an effort to write cookbook level documentation to supplement the extensive reference manual documentation. The development of this cookbook is being carried out by a group of astronomers at the AOC, so we hope that the language of object, methods, etc., will be explained in terms that the average astronomer will understand, feel comfortable with, and benefit from.
We expect these developments to be made available to our beta testers in the next (third) beta release, tentatively scheduled for April. If you are interested in becoming a beta tester, please contact me (email@example.com).
|Project News Summary|
AIPS++ Activities at the ATNF|
Neil Killeen - ATNF, Epping
The ATNF contributes to the AIPS++ project in several areas including the systems for code distribution and system generation, the measures system, aperture synthesis software, the Display Library, and image analysis.
Code Distribution and System Generations
The Measures System
The measures system provides facilities to convert between units, and/or reference frames. For example, conversion of an optical LSR velocity to a topocentric frequency, or conversion of a time in UTC to LAST. The measures system also performs calculations involving quantities and frames. For example, it can calculate the rise and set times of planets and other sources for any time and location.
The measures system is accessible to both the Glish user and the C++ programmer. In Glish measures can be accessed from either the command line with bindings to the C++ library, or through the measures GUI interface. The latter offers full conversion and calculation toolkit capability, as well as some higher level applications.
The measures system makes extensive use of International Earth Rotation Services (IERS) tables and offers precision that is sufficient for non-astrometric VLBI. Ultimately it will offer precision to handle orbiting VLBI. This is the first time that one package has successfully pulled together all the threads needed for virtually all astronomical calculations.
The Sythesis Package
The Display Library
Like most modules in AIPS++, the DL will serve both the C++ programmer and the Glish user. Thus it will be bound to Glish allowing users to make their own applications using the features of the DL. The DL is designed to maximize high-level programmer efficiency by providing high-level and flexible classes that can be used to quickly create a new application.
The DL continues to be developed. The major goals for this year are: bind the DL to Glish so it can be used by Glish commands and GUIs, develop widgets allowing the user to control the applications, continue to develop needed infrastructure, develop some end-user applications (currently we have only a few trial/demonstration applications), and begin integrating the DL with the rest of AIPS++ (e.g. define and transmit a region from an image to the clean method of the sky module).
A few of the image analysis tasks that can now be done are: FITS conversion statistical analysis of images, sophisticated moment analysis of images, and calculation of mathematical expressions involving images (e.g. z=x+sin(y)where x, y, and z are images). The presence of the image calculator removes the need to write some applications.
Project News Summary|
The Parallelization Project|
Doug Roberts - NCSA, Urbana
A group effort to optimize AIPS++ for parallel execution on multiple-processor machines is now underway. The group consists of Dan Briggs and Doug Roberts at NCSA-Urbana and Wes Young at NRAO-Socorro, with Brian Glendenning at NRAO-Socorro overseeing the effort. In addition, two members of the Performance Engineering Group at NCSA are being consulted on timing and parallelization issues.
The goal of the project is to increase performance on the highest class of machines available. Currently the target hardware is the Silicon Graphics (SGI) CRAY Origin 2000 at NCSA. The Origin 2000 at NCSA has 512 MIPS R10000 processors, each of which is capable of peak performance at 390 MFLOPS, and has a total of 128 GB of physical memory (RAM).
The first phase of the project should be completed and tested by April. In this phase a limited number of components in AIPS++ will be parallelized in order to decide how to do a larger scale of optimization. Each member of the group is taking a different approach to the problem. Wes Young is parallelizing the deconvolution of spectral line channels using message passing. Message passing is a technique in which data and instructions are passed to a remote processor, which then does a computation and returns the result in the form of another message.
Dan Briggs is working on parallelizing the gridding aspects of imaging using native SGI compiler directives. A component of this compiler detects parallel constructs and creates executable code that manages parallel execution at run time. A technique similar to native compiler directives is a standard set of directives, implemented by multiple vendors, called OpenMP. Currently, the OpenMP standard for C++ has not been established, so it can only be used for AIPS++ code in FORTRAN. Eventually, when the OpenMP standard for C++ is finalized, we will re-implement native compiler directives in OpenMP. Thus, optimization that is implemented for the Origin 2000 can be carried over to other vendors that use OpenMP in their compilers.
Doug Roberts is implementing an interface to FFT libraries that are optimized for parallel and serial performance on the Origin 2000. The interface begins with the one-dimensional FFT routines and will extend to multidimensional FFTs.
These first components for parallelization will be tested and timed in March and April. We are aiming for speed improvements of a factor of ten over the serial code for some applications. The "parallel group" will then meet in Socorro to discuss the results and prepare a long-term plan for parallelizing AIPS++. By the end of 1998, we hope to realize significant speedups over serial code across a range of applications.
|Project News Summary||
What's New in AIPS++?|
Tim Cornwell & Brian Glendenning - NRAO, AOC
This article highlights recent developments in AIPS++ that may be of interest to users and will continue to be a regular feature in the AIPS++ Newsletter.
The synthesis imaging object, sky , now has a helpful sibling, cal , that is responsible for calibration of visibility data using the formalism of the Measurement Equation. Cal is under continuing development. Current capabilities are equivalent to those in the old imager application and allow self-calibration of atmospheric phases, electronic gains, polarization leakages, and bandpasses.
The image object , now has an image calculator associated with it. The calculator allows general mathematical operations on collections of images, including arithmetic and boolean operations.
Objects in AIPS++ now may be easily associated with a standard Graphical User Interface (GUI). The GUI is described in a "meta-information" Glish script for each object. The GUI then displays methods of the object, allows type-in of method arguments, and execution of the methods. Objects that now have these standard GUIs include sky, cal, and image.
The single dish "program," dish, continues to evolve in many ways. It has recently acquired the ability to automatically perform user-selectable multi-operation sequences on sets of spectra.
The measures calculator/GUI has changed in many ways. Most notably, "pop-up" help is now available through the use of the third mouse button. Pop-up help will be implemented for other programs in the next month or two.
Long time users of AIPS++ may notice that a very simple contour drawing application, gcontour, has been removed from the system. No functionality has been lost since pgplotter can do contours in the same way and a number of additional ways.
One and two dimensional Gaussians are available to the Glish programmer after including 'gaussian.g'. As with most Glish functions, many Gaussian evaluations may be performed at once via whole-array arithmetic, hence they are reasonably efficient.
|Project News Summary|
The Story of Glish - Part 1|
Darrell Schiebel - NRAO, CV
The Glish scripting language has evolved from a simple set of scripts and programs used to sequence high energy physics experiments to the flexible interpreted language which today forms the basis for control, communication, and command line interface within the AIPS++ system.
While at CERN in 1986, Chris Saltmarsh developed a set of routines for sequencing experiments for Super Proton Synchrotron operations. As part of this development, the first version of SDS (Self-describing Data Standard) was created. SDS is a library of functions providing architecture-independent data transport. This library would later form the basis for Glish's initial transport layer. In 1987 Chris went from CERN to the Super Conducting Supercollider (SSC).
In early 1988, Vern Paxson and Chris, both part of the Central Design Group of the SSC, developed a set of programs to collect data as part of Tevatron experiment E778 at Lawrence Berkeley Laboratory (LBL). In each case, programs and scripts created for a particular experiment proved too inflexible, and it was from these experiences that Glish was created. Too much time was spent developing the routines and scripts needed to run different experiments, and even when these routines were developed they lacked the flexibility needed to be adapted for use on other experiments. Vern Paxson, with Chris' help, developed Glish (version 2.1) in late 1988. During the time between this first Glish release and the termination of the SSC project, three other versions of Glish were released.
The AIPS++ project adopted Glish shortly after the demise of the SSC in early 1994, and contributed several language additions for the last release (version 2.5) from LBL. The language that evolved at LBL was loosely based on the S language, which was designed for data analysis with a heavy emphasis on statistics. Glish combines vector oriented mathematics, standard control constructs, asynchronous event-oriented language elements, and an architecture-independent transport layer. In short, Glish provides all of the elements necessary for control of systems distributed across a network. In Glish, these systems can be easily developed and modified.
After 1994, there was a long gap in public releases of Glish while the AIPS++ project developed and extended the Glish language, improving both its stability and flexibility. Much of the work at the NRAO has been directed toward making Glish suited for larger programming projects. The first public NRAO release of Glish (version 2.6) occurred in November of 1997. More information can be found from the Glish home page.
|Project News Summary|
Tim Cornwell - NRAO, AOC
There is much that can be done with calibration and imaging of aperture synthesis data. So much, in fact, that design of applications to support such work is difficult, and can lead to unwieldy programs that are difficult to use and understand. This happened with the old imager object that was part of the first two beta releases. Although imager had many capabilities, some of which were entirely novel, few people were able to use it to good effect. Bearing this in mind, we decided last year to re-implement it in a new format as sky , using version 2 of the AIPS++ object system, and aiming towards a GUI to help new users cope with the complexity. Sky has recently been released into the development system, and our brave testers are gaining experience with it.
Compared to imager, the functionality in sky is split into smaller units: the methods tend to do one thing such as clean an image, or restore it, or fit the point spread function, or evaluate the sensitivity. This has two benefits: the operations are easier to understand; and more complicated operations can be built from these smaller units. For example, you can use the available methods in a Glish script to plot the surface brightness sensitivity of a data set. However, although such script-based enhancements are possible, our first priority is to ensure that sky is attractive to use for straightforward synthesis imaging.
As a general principle, we have endeavored to build upon advances in other parts of the system. As an example, sky uses the new plotter, pgplotter , to display plots of visibility amplitudes, weights, and u-v coverage. Another example is the pervasive use of the measures system for arguments - thus allowing directions and velocities to be specified in any reference frame allowed by the measures system. This latter capability is integrated throughout sky and has some startling benefits: images may be constructed in a wide range of coordinate systems: ra-dec, galactic, super-galactic, ha-dec, az-el, tied to a planet, and so on.
Sky is built on the Hamaker-Bregman-Sault measurement equation for a generic interferometer. We believe that this equation can describe the vast majority of existing interferometers (in fact, we don't know of any radio-interferometer that is not covered). This formalism has many advantages, but perhaps its important benefit is that many advanced calibration and imaging algorithms become just special cases. For example, clean-based mosaicing is possible using sky, and extensions to handle other things (e.g. VLA beam squint) are straightforward.
Our plans over the next few months are first to continue to improve the usability of sky (e.g. user interface, documentation, performance), and second, to add support for both established reduction approaches, such as wide-field imaging with the VLA, and entirely new approaches such as non-isoplanatic imaging. More details on the capabilities of sky can be found in the AIPS++ User Reference Manual.
|Project News Summary|
Brian Glendenning - NRAO, AOC
A goal of AIPS++ is to allow users to be able to perform their own ad-hoc calculations using the scripting language Glish in combination with the data-access and computational facilities of AIPS++.
In this series we are going to demonstrate these concepts by implementing a facility to "convolve" an image by a convolution kernel, which can either be supplied directly as a "matrix", or which can be specified via parameters of gaussian1d and gaussian2d objects .
In general terms we are going to proceed as follows:
It is instructive first to see how to convolve one array with another array, since that is the heart of what you need to do. First create an array using
which makes a Glish array named a. The first argument gives the "value" of the pixels of the Glish array, and the last arguments give the length of the axes. So, the "shape" of a is [200,100], and a is filled with zeros. The array function is described in the Glish Manual.
Of course a zero-filled array is not very interesting, so let's put a couple of "sources" into it.
This puts a faint 5x5 rectangle near the lower left corner of the array, and a brighter 3x3 rectangle in the upper right corner of the array.
It is often useful to be able to view two arrays graphically. One possibility is to use aipsview as follows
Here dd is a synonym for display , which is an object you can use to manipulate aipsview at the Glish command line. It is documented in the User's Manual. The defaultdisplay (dd) object is created for you whenever display.g is included.
Alternatively, you could use a PGPLOT object (pgplotter) to display the object. The trade off between aipsview (display) and PGPLOT (pgplotter) is that while aipsview is easier to use, the pgplotter gives you more fine-scale control of the plot. Both are described in the User Reference Manual. To display a, use commands like
which results in a display of a as a grayscale picture. Of course, besides using a grayscale display, you could choose contour-plots, false-color display, or any other pgplotter possibility for display of 2-D arrays.
Now you need a convolving kernel that you can use to smooth the array. If you just want to do a 7x7 boxcar smooth, you could set up a kernel with
Of course a Glish-wizard might write the last line as follows:
From Glish, convolutions are done with an fftserver object since convolutions are FFT based. So, you need to make an fftserver object and use its convolve method:
The residuals may be readily calculated and displayed using Glish array arithmetic.
This is the heart of our algorithm! In our next installment we shall attach the computations to image planes. Perhaps you can already see how to do this with the getchunk and putchunk methods of image objects.