AVS and CM/AVS

AVS was originally developed by Ardent, but is currently maintained and distributed by a separate company, AVS Inc. The main advantage of AVS is its modular design: a user can build an interactive application with little effort by putting together a network of predefined modules. Each module performs a simple task, such as displaying a raster image, rendering a 3-D geometry, reading or modifying a parameter, etc. Building a network is easy: AVS comes with an interactive tool that allows the user to grab modules out of a library and connect them on the screen by drawing lines. Each AVS module knows what kind of input data, output data, and parameters it can accept and produce, so there can be no ambiguity or design errors in building a network. Figure shows an example of a network used in our visualization tool. The lines connecting the modules represent data-links between modules; data-links of different types (parameters, fields, colormaps) are indicated by different colors.

Over the years AVS has grown into an extensive toolkit that provides modules for most data visualization problems. As a result, the user is spared the work of coding graphics modules himself, and can concentrate on writing modules that are specific to his problem. Programming in AVS is straightforward with the module autowriter: the user interactively defines input, output, and parameters, the autowriter produces a skeleton program, and the user then writes the core of the module. The basic data structure in AVS is called a field, and most parameters associated with graphics applications (axes information, coordinate data, etc.) are part of the field definition. In Fortran, field parameters are accessed through subroutine and function calls. In C, a field is a predefined C structure that can be directly accessed and modified. AVS offers a wide range of interactive X-widgets for inputting and modifying parameters, which allows the programmer to create sophisticated user interfaces with little effort.

Depending on how modules are linked, AVS applications will execute and communicate in two different ways. If modules are linked into separate executables, each module runs as a separate UNIX process, communicating with other modules through UNIX sockets. If all modules are linked together, the application runs as one executable, calling individual modules as subroutines, which pass data and parameters through pointers in memory. These two execution modes can have considerable differences in performance and memory usage, especially on the CM-5 (see below).

CM/AVS consists of a set of AVS modules that operate on data residing in CM-5 memory. The modules can be manipulated within AVS in the usual fashion, and they can be connected to standard AVS modules. During execution, a network that contains both AVS and CM/AVS modules will generate processes that run both on the AVS-server (an HP 735 at SEP) and on the CM-5; communication between these processes takes place through UNIX sockets. The goal in designing a CM/AVS application is to execute the data and computationally intensive parts of the application on the CM-5, and to display the results on the workstation. This is an important advantage because the size of datasets on the CM-5 can easily be in the order of several hundred megabytes, whereas the size of a typical graphics image is generally less than one megabyte. Programming in CM/AVS is similar to programming in AVS, with the main difference that programs are written in Connection Machine Fortran (CMF), and that fields are CMF arrays.

There are several limitations to AVS that the programmer needs to take into account. First, AVS is designed such that a change in a module parameter only affects modules ``downstream'' in the network. Although this can significantly speed up the application (fields in ''upstream'' modules do not have to be recomputed), it can also seriously reduce memory available to the user, because each module must make a copy of the data. To lessen this problem the latest release of AVS allows the user to overwrite input fields, but only if input and output field have the same dimensionality. A second limitation arises from the fact that the CM-5 operating system does not currently implement parallel UNIX sockets; if CM/AVS modules communicate through sockets all data transfer takes place through the CM-5 partition manager. Obviously, this limitation would defeat the purpose of writing CM/AVS applications. The current work-around for this problem is to link all modules into one executable as described above. In the next release of CM/AVS the parallel sockets will exploit the high-bandwidth CM-5 data network to exchange data efficiently between modules.