Run-time Visualization of Program Data. Allan Tuchman, David Jablonowski, and George Cybenko. Center for Supercomputing Research and Development

Transcription

1 Run-time Visualization of Program Data Allan Tuchman, David Jablonowski, and George Cybenko Center for Supercomputing Research and Development University of Illinois at Urbana-Champaign Urbana, Illinois Abstract An important improvement to visualization systems will provide a graphics \window into an application" displaying program data at run-time through an easyto-use graphical interface. With little or no instrumentation of the application the user will be able to dynamically select data for graphical display as the program executes on a remote computer system. The data to be displayed and the type of display to be used are chosen interactively while the application is executing. Any data display can be enabled or disabled at any time; it is not necessary to specify the data or graphics technique before compilation as with conventional graphics tools. We propose an architecture for such a remote visualization system, and describe Vista, our implementation. Designed primarily for scientic visualization, Vista also oers an environment for more eective debugging and program development. 1 Introduction The graphical display of information is important to every aspect of computing. Even applications which are not necessarily centered around visual display benet greatly from computer generated graphics. Graphics are used in algorithm development, program development, and display of intermediate and nal computational results. For many years a typical application run on a host computer called graphics subroutines to show data or results. Those subroutines may have been internal to the application or from a graphics library. The subroutines may have controlled a graphics device directly or perhaps output a le for later viewing. This model does not promote the usability of graphics. The application developer must specify in the program before compilation which data values will be displayed, when these values will be displayed, and to some extent, how and where they will be displayed. This specication often requires major modication to the application program and gives the application user little control over what data can be displayed. The notion of any distributed graphics processing or the network environment must be explicit in the application or the graphics library in use. This all becomes a part of the application. For each run, internal or external parameters may control the path of execution, and therefore the specic graphics routines that are executed, but this is the extent of the control. In this paper we discuss the scope of dierent types of visualization from the standpoint of quality, interactivity, and usability. We describe functionality for a distributed display visualization system with dynamic data and display selection that lls a gap in existing systems and is immediately useful to a large class of users. We discuss the rationale for the design of a system that meets these needs, show how such a system is used, and describe the architecture of Vista, our implementation of this system. 2 The scope of visualization Computer graphics is often dened in terms of its intended use. A common characterization of computer graphics applied to scientic visualization is with respect to the intended viewer. The terms personal graphics, peer graphics, and publication graphics are frequently used to describe images that are, in general, of progressively higher quality and are more costly to generate. A publication graphic does not necessarily convey more information than a personal graphic but attempts a clear, polished, and more eye-catching display for a wider and perhaps non-expert audience. Another taxonomy breaks down the eld according to the amount of human analysis needed to extract information from the available data. We may dene the terms snapshot, structured interaction, and exploration in a hierarchy of increasing human involvement in extracting meaning from the data 1. For a snapshot, the application program developer knows ahead of time exactly what data to show and may even have a good idea of the type of information that will be conveyed by this data. Frequently a single image represents the nal result of a computation or portion thereof. For a structured interaction we propose that the application developer had some idea which data items would be useful, but allows the application user some interactive capability in chosing the data to see, how to display it, or control of attributes such as viewing parameters or color which may best show the data. In an exploration there are generally no preconceived 1 We regret the overloading of the term interaction in the context of computer graphics. We cannot nd a more appropriate word for this categorization.

2 notions of what features may be present in the data. Often, large data sets that are collected from experimental apparatus or generated from complex simulations contain so much information about the studied phenomena that days or weeks can be spent browsing a single set of data and exploring it with diverse visualization techniques. There are subtle dierences between a system which shows algorithms, one which shows data, and one which shows data structures. In a broad generalization, depiction of data structures is primarily for debugging, visualization of the data itself is for problem analysis, and algorithm visualization is for both insight and development. The dierence between these is sometimes, but not always, just the point of view of the user. Perhaps a visualization system should oer methods to show all three items. Over the past twenty years computer graphics techniques have been developed to produce the rendered images of our models. These techniques aid us in scientic visualization, but do not intrinsically contain the data ltering, manipulation, and modeling that allow users to grasp the essence of the data. Visualization toolkits now pave the way for complex data analysis and visualization techniques for data exploration. In this paper we describe a remaining piece of the visualization process, that of viewing program data as the application is executing. We term this simulationtime animation, and stress its importance in all aspects of the computation cycle: algorithm development, program development and implementation, debugging, and nally, display of intermediate and - nal computational results. The term reects both the immediate feedback (via personal graphics) with the potential for steering the course of the application as well as the dynamic display update (and structured interaction) and single-image snapshots. This diers considerably from a post-processed animation (of peer or publication graphics) produced some time after the application is complete. We also allow some data exploration during program execution. Our model for a simulation-time animation system is compatible with existing graphics programs, visualization systems, and toolkits allowing us to leverage o a large existing body of graphics software. 3 Previous work There are a few well-known systems promoted for visualization. Each shares some of the characteristics of our work, but most address a slightly dierent problem. The most well known systems for scientic visualization are AVS [UTK + 89], developed by Stardent Computer, and ape [Dye90] from Ohio State University. Both of these systems provide a visual programming interface which allows the user to specify a sequence or network of processes to manipulate data. The individual processes can execute on a local or a remote computer. The starting point for most users of these systems is one or more data les. It is possible though, with some small modication to the program, to have the application program write directly to the start of the visualization network. This provides an excellent tool to manipulate predetermined data from an application. However, neither system provides direct access to arbitrary program data. The Balsa-II [Bro88] system for algorithm animation provides the same simulation-time animation capabilities that we strive for, yet requires considerable instrumentation of the application source program. It is not easy to dynamically show new data and the system is not inherently distributed. Aladdin [HHR89] has similar use in algorithm animation, and uses a graphical interface to minimize the amount of graphics programming required to visualize the algorithm. Johnston and others at Lawrence Berkeley Laboratory have developed a system for distributed scientic movie making using a Sun workstation and a Cray supercomputer [JHH + 88]. By modifying the source program to include calls to their Scry library, an application can have data rendered on the supercomputer or the workstation, displayed on the workstation, then recorded on a low-cost animation system. Their work is most signicant in distributed image display and in the low-cost animation solution. Scry does not address dynamic data access. Our own work in this area began as we tried to abstract the necessary control and data access requirements for a distributed simulation-time animation system (STAS) [NT89]. This system was unwieldy and required considerable additions and modications to the program source. In later work we separated data access from data display in a remote visualization environment for looking at matrix data in linear algebra applications [TB90]. One way to provide distributed graphics is with a distributed window system such as the X Window System or NeWS. Both allow remote display of graphics, but graphics algorithms still execute in the application (client) process. Forthcoming work in PEX (Phigs Extensions to X) will shift more of the low-level graphics tasks to the remote workstation making this a more attractive solution. Using PEX, the graphics algorithms will still execute in the client process, but graphics transformations and rendering functions will move to the server and can potentially be processed by hardware. The window systems still do not address the application access to graphics or issues of dynamic data access. 4 Design Several features are useful in a simulation-time animation system, or even one which shows only run-time snapshots of data. The system should have easy-to-access graphics, Support Host Visualization Server Graphics Workstation Figure 1: Abstract Model of the Vista System

3 require minimal modication of the application program, Supercomputer Workstation transparently provide a distributed environment with remote visualization, allow dynamic association of the display method and data, encourage dynamic selection of what to show, and when, make use of existing graphics software, Sequence 1a. Insert breakpoints and compile application 2. execute application 1b. Start Vista visualization server 3. Select and Visualize data as desired Figure 2: Steps for using Vista use the simulation-time animation model, the only model which allows computational steering. The start-up time or learning eort is always a problem in getting people to use a system. The cost, generally poor graphics capabilities, and geographic constraints of supercomputers dictate a design which allows a graphics workstation to manage graphics functions and user interface. Simulation-time graphics are the best way to get insights into the method of solution for a problem. Watching a solution converge while the application is executing provides information on rate of convergence as well as anomalies that may show up only in a time sequence of images (animation). As new insights are realized, the ability to display new data dynamically or to display already visible data in a new form is very important. Individually these goals have been achieved by others, but not together. Vista's logical design, shown in Figure 1, has two parts, a visualization server which runs on the workstation and an application support module which runs on the application host. The two parts communicate through any inter-machine communications mechanism, for example TCP/IP over ethernet. Together, they will allow us to satisfy our requirements listed above. The visualization server must provide a user interface to access the system functionality, associate data with graphical display methods, and manage the display of graphics from these methods. The application support module must be able to access application data at execution time and provide a mechanism for visualization break points. We also refer to these as vispoints for short. Data access is eected by maintaining a symbol table with information obtained in any of several ways: a source preprocessor which builds the symbol table, with automatic or user-inserted procedure calls from the application to enter this information, or by reading a compiler-generated symbol table. The vis-points are used to identify those places in the program where data access is permitted. Although vista can interrupt the program at any arbitrary point during program execution to access and extract data, this is not encouraged. It is possible that the data structures of interest are being modied and that in their state of transition may even be temporarily corrupt. The vis-point mechanism then, is the user's way of giving the application support module permission to access data. 5 Use Before providing more details of the system architecture, we describe a typical use of Vista in order provide an overview of the distributed and accessible nature of the system. The use of Vista is outlined in Figure 2 and further described below. Figure 3 shows a workstation screen during a Vista session. We will refer to parts of this gure in our following description. A session normally starts with the user logged in to a workstation. There are one or more terminalemulator sessions (Xterm or shell windows) open on the workstation, which we call local windows, and an additional window open to another computer via a remote login (or remote shell). The remote host will execute the application. The shell windows are iconi- ed for clarity and not shown in Figure 3. In a local window, the user types the command vista to start the visualization server and display the visualization manager window, shown in the lower left of Figure 3 (step 1b of gure 2). The user now focuses on the remote window and edits the application to insert visualization break points if they have not been previously added. This is the only manual instrumentation (modication) required for most programs. The application is compiled with a compiler option to create a symbol table (the -g option of most Unix compilers) and linked to the Vista library (step 1a). When the user executes the application (step 2) it establishes a remote connection to the visualization server and a status message is displayed to this eect. With both processes now running, the user may add program variables to the local list (step 3), shown in the center column of the visualization manager window. To display any variable in this list, the user points at it with the mouse cursor, clicks the mouse button and does the same to one of the display icons shown in the rightmost column of the visualization manager window. The dial and X-Y plots shown in Figure 3 were created in this way. s of more complex data, such as the mesh in the gure, include multiple variables selected in a slightly dierent way. Each time the application encounters a vis-point, all displays on the screen are updated to reect current program values. At the user's option the application may automatically proceed after each update or await further instruction from the user. Any graphic display can be added or removed at any time. When the application completes, the visualization server is notied. If the visualization server is terminated ear-

4 Figure 3: Workstation screen during a Vista session lier, the application will continue uninterrupted until its completion. 6 The Vista architecture Certain aspects of the architecture were determined by the distributed nature of our design. The simple design of two modules shown in Figure 1 might be satisfactory, but would limit our exibility in distributing functions, hinder overlapped processing of the two machines, and possibly allow the visualization system to compete with the application for host system resources. (For example, a single process on the host would impose some intermachine communication overhead on the application process. This can have a serious impact on a multiprocessor machine.) Although the application support will normally process requests for data at well-dened vis-points, for some requests we may want to interrupt the application and access information immediately. This latter situation led us to insert an additional support module on the application host. There were less compelling reasons to provide a similar module on the visualization host, but long term plans for connecting many hosts running a distributed application showed that such a module would be useful as a multiplexor if for no other reason. In fact, the symmetric design shown in Figure 4 has worked out very well and includes important synchronization logic in the auxiliary processes labeled Data Manager. The underlying Vista model shown in Figure 4 identies each major component of the system. As each module is presented, its primary functions and interface to other processes is described. Implementation is explained in more detail in [TJC91]. Each of the four large boxes in Figure 4 represents an independent Vista module and is implemented as a separate process. 6.1 Visualization Manager The user interface is a part of the visualization server process that we call the Visualization Manager, or VM. To the user the VM appears to be the bulk of Vista. The VM is already running on one computer, usually a graphics workstation, when the application program begins execution on (the same or) another computer, generally a more powerful machine. Once the application starts, the VM maintains a list of available program symbols and a list of available graphics techniques (widgets or other tools, for example). At any time the user can choose one or more names, associate them with a graphical method, and have a picture show up. The image will be dynamically updated

5 Object Source Executive defaults Vista Visualization Manager Data Manager Host Workstation Interface to the rest of Vista and the application control data Data Manager Visualization Manager defaults resources Main Vista Graphical User Interface data selection Data filtering and transformation Multiplex data to display methods Tool Tool Tool remote session login interface via internal routine or IPC Network / Communication Interface Figure 4: Architecture of the Vista System Method Method Method as the program variables change (subject to vis-points discussed below). The three primary responsibilities of the VM are shown as emboldened boxes in Figure 5. The interface includes the communication routines and data transmission. The graphical user interface allows the user to perform data selection, display selection, and provides control of the Vista system. This is the display shown as the lower left window in Figure 3. Finally, the VM serves to direct incoming data from the application to the graphics display method or process. Optional transformations on the data may be performed; for example, for type coercion or range adjustment. A Method is a module that takes transformed data and displays it graphically on the user's screen. A display method may be an internal module of the VM, for example, a widget in a window system toolkit. More generally, a display method may be a separate process (the display method hanging below the dotted box in Figure 5). An interprocess communication (IPC) mechanism is used to exchange data and control information between the display method and the VM. The use of external display methods is a most important capability as it allows almost any graphics function to be added to Vista without recompilation or changes to the Vista source program. In fact, this external method may be placing data into the beginning of a visualization pipeline for an existing visualization system such as AVS or ape. Figure 5: Components of the Visualization Manager Vista Executive data Data Access Routines request/ response C Interpreter symbols Symbol Table Scanner AE Symbol table Data Interface to the rest of Vista request/ response symbols Figure 6: Components of the Executive

6 6.2 Executive The other part of Vista that the user may be aware of is the application support module associated with the application program. The program is loaded with and linked to an Executive, or AE. The AE is mostly independent of the application program, but by sharing the task address space has access to all program data. The main components of the application process when linked with the AE are shown as emboldened boxes in Figure 6. The interface is not unlike that of the VM. The AE maintains a symbol table in a data structure comprised of a variable name, its address, and its type. This information may be supplied by the application via procedure calls or automatically determined by reading the symbol table from the object le. When presented with a request from the VM, the AE searches its tables, possibly accesses data, and returns an answer. For examples, the is name message asks the AE if a name is a valid program identier. The return message is either type and size information for the variable or a negative response. At predetermined vis-points, the program transfers control to the AE, which services any outstanding requests and returns to the application. The C interpreter in the AE is not necessary for routine access of simple data types, including arrays with non-unity stride. The interpreter will allow us to access and traverse more complex data types in the future. This interpreter is partially implemented and has aided us in debugging Vista. 6.3 Data Managers Neither the AE nor the VM communicate directly with another computer. Each has an associated task, a Data Manager, or DM, running on the same multiprogramming system. The DM connected to the VM is called the VDM, the DM adjoining the AE is the ADM. The primary function of the Data Managers is to pass data between computers. This includes maintenance of communication channels and overall synchronization of the system. The ADM and VDM are symmetric in several layered tasks, discussed below. They dier in other functions, though. For example, the VDM may accept connections from several dierent hosts in one session; the ADM may need to send an interrupt to the application if it needs information immediately, before the next program vis-point. One of the ADM's most important tasks is to maintain two lists, one of work items (such as data access) that must be performed at all vis-points, and another prioritized list of new messages that have arrived since the previous vis-point. 6.4 Communication An early decision was to make the entire system asynchronous. This allows the user to formulate several requests without waiting for each to be satised. In fact, a user may make several requests before the application sees any of them at the next vis-point, providing a good processing overlap. Similarly, it allows a simple request to be satised before a more timeconsuming one. The interactivity can remain as high as possible. At times we must synchronize or wait for a specic event before proceeding, but this is handled in our software. We also decided to use a message passing scheme for all inter-module communications. The use of messages provides more error checking in data transfer. An important use of this method is to order messages, associate responses with specic queries, and keep track of outstanding messages in need of a response. At rst it may appear that the problem of transparent data transfer between heterogeneous machines has been solved by the Remote Procedure Call (RPC) protocol. This is certainly the case for transferring relatively small amounts of data between machines as procedure parameters. Subroutine parameters and types are known in advance; however, the Executive can access any data item in the program at any time. Due to this requirement and the large amount of data we need to access, we were not willing to pay the penalty of adhering to RPC. We have found (so far) that converting even binary oating point data is not too dicult. We may have to reassess our decision if we later need to exchange more complicated user-dened data structures across machines. The lowest level of all Vista modules is the networking or communication interface. This handles the inter-process and inter-machine communication. Above this is the transport layer which packages messages and data. The Data Managers provide the data layer which provide transparent exchange of data across heterogeneous computers. 7 Future work Vista development is a continuing eort. In order to develop a system which is truly practical, we have released Vista to our own department. We have a list of immediate requirements that will aect additional acceptance and porting of the system to other sites. We are trying to isolate the non-portable components of Vista. The application executive is our most machine-dependent module. It could take quite a bit of eort to port this program to a host which does not support the Unix system. The symbol table scanner is quite sensitive to the host environment. We still have some parts of our original design specication left to implement. For example, we must interface Vista with some robust visualization system. A playback le will be implemented to see how well it will work as a session recorder. This le will also allow a user to use the same Vista interface for data browsing (exploration) as for his or her simulationtime animation. Our design allows Vista to be used in a parallel processing or distributed process environment. Multiple AE/ADM's can connect to a single VM/VDM. The AE's may be from dierent machines or from many clusters of the same machine (for example, the Cedar system developed at the Center for Supercomputing Research and Development). For such a conguration, each process, whether on the same or dierent computers, will link with an AE and have its own ADM. Only a single VM/VDM pair is still used. (In Figure 4, the upper portion is cloned for each process.) After completing this development we will turn our attention back toward the application program. We have a dicult problem with the scope of identiers.

7 Currently we assume that data is accessible in the current scope or static. We must also consider dynamically (heap) allocated storage and data access in parallel applications. Some of these problems and others can be solved with an automatic source preprocessor; one which can automatically insert calls to mark the entry or exit of a scope for example. We must consider data represented by data structures more complex than scalars and arrays. In scientic computing, large data sets are common. There are ways to minimize the amount of data we need to access or transmit between processes. This naturally leads to a study of load balancing in visualization software, splitting work between the host and workstation (and considering network bandwidth). 8 Conclusion We have presented Vista, an architecture for remote data visualization, along with its initial implementation. We have met our goals by providing a mostly point-and-click (object-action) graphical user interface, along with minimal program instrumentation to access any program data items on demand and displaying them using dynamically-chosen graphics methods during execution of the application. Vista works with applications written in either Fortran or C. Finally, the system is modular to facilitate development and provides some tailored modules for dierent environments, machines, or applications. We have a few components of our initial design left to implement and several challenging problems left to solve. One of the weakest areas of our current implementation is the graphics display methods themselves. Since we assume that good rendering software is available, commercially or otherwise, we put little eort into this large development eort. Our small selection of graphics display methods has been assembled in an ad hoc fashion from many sources. As such, they vary greatly in levels of robustness. This implementation of Vista is relatively complete in itself. From this point we can work in several divergent directions including parallel remote graphical debugging, access to and selection of more complex data structures, and visualization of distributed applications. Our intent was to create a portable remote visualization environment without ties to any particular operating system, language, or graphics support library. The current implementation of Vista is built on existing standards, requiring sockets as implemented in Berkeley Unix version 4.2 or later. With an appropriate message passing mechanism, much of Vista could be ported to any operating system and network environment. The visualization component of our implementation uses the X Windowing System for the graphical user interface and the graphics displays. Acknowledgements The Vista implementation included the work of several people besides the authors. Sanjay Sharma implemented the network layer using sockets as described and supported by Berkeley Unix 4.2. Brian Bliss developed most of the Executive including the ambitious C language interpreter. His interpreter also scans the object le symbol tables. Allen Malony participated in many of the earlier discussions on the system design, and the authors thank him for his comments. This work was partially supported by the Air Force Oce of Scientic Research Grant under Grant No. AFOSR and U.S. Department of Energy under Grant No. DOE DE-FG02-85ER References [Bro88] Marc H. Brown. Exploring algorithm using Balsa-II. Computer, 21(5):14{36, May [Dye90] D. Scott Dyer. A dataow toolkit for visualization. IEEE Computer Graphics and s, 10(4):60{69, July [HHR89] Esa Helttula, Aulikki Hyrskykari, and Kari-Jouko Raiha. Graphical specication of algorithm animations with Aladdin. In Proceedings of the Twenty-Second Annual Hawaii International Conference on System Science, pages 892{901, Kailua-Kona, Hawaii, January IEEE. [JHH + 88] W. E. Johnston, D. E. Hall, J. Huang, M. Rible, and D. Robertson. Distributed scientic video movie making. In Proceedings of Supercomputing '88, pages 156{ 161, Orlando, Florida, November [NT89] [TB90] [TJC91] Henry Neeman and Allan Tuchman. Simulation time animation system. Technical Report 859, Center for Supercomputing Research and Development, University of Illinois at Urbana-Champaign, February Allan M. Tuchman and Michael W. Berry. Matrix visualization in the design of numerical algorithms. ORSA Journal on Computing, 2(1):84{92, Allan Tuchman, David Jablonowski, and George Cybenko. Vista: A system for remote data visualization. Technical Report 1067, Center for Supercomputing Research and Development, University of Illinois at Urbana-Champaign, June [UTK + 89] Craig Upson, T Faulhaber, Jr., David Kamins, David Laidlaw, David Schlegel, Jerey Vroom, Robert Gurwitz, and Andries van Dam. The application visualization system: A computational environment for scientic visualization. IEEE Computer Graphics and s, 9(4):30{42, July 1989.