Taralogic Smart User Interface:
Product Specification

A Powerful Communication Tool for the End User and Expert Programmer

Taralogic, Inc., 179 Main St., Westford, MA 01886, (508) 392-0560

© Taralogic, 1993. All rights reserved. No part of this document may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrievel) without expressed written conscent, in writing, of Taralogic, Inc.

section 1: 


Welcome to the Taralogic Smart User Interface (SUI). The Taralogic SUI, a stand alone visual interface that runs on top of the Taralogic Parrellel Virtual Machine (PVM) system, provides a powerful, developement / communication tool that monitors the activities of a PVM job, and allows the user to control it in a highly natural and intuitive manner. The philosophy behind the SUI is to use proven techniques of information visualization from the field of graphic design to eloquently clarify and intuitively present the complex information of a PVM program to the end user.

Major consideration and emphasis on the design of a graphical user interface (GUI) to a parrellel virtual machine is placed upon the ability to adapt and cater the information presented to the viewer in a manner which visually and functionally reflects, represents, and communicates the actual data and processes being used in the system. We at Taralogic envision a new type of GUI; one which uses several visual techniques to inform the user of the status of a parrellel job and allows them to quickly navigate, browse, and investigate information about it. For this reason, Taralogic has designed their Smart User Interface in such a way that even the novice of users can have the same power at their fingertips as does the expert programmer.

Figure 1. The Taralogic Smart User Interface.

section 2: 

Levels of Information

Unlike traditional GUIs, Taralogic's SUI is a dynamic "front-end" that communicates the technical structure of the PVM to the user quickly and effectively. The interface is not merely a set of two dimentional windows placed on the desktop of a computer as is the case with most; but rather, it is an interactive three-dimentional model of computer nodes networked together to preform a job in parallel. Instead of switching back and forth between different windows to obtain information, users "zoom" in and around the three dimentional model towards distinct levels of information which provides them with different types of granular data; from a "zoomed out" view of an entire network, through to a close-up view of a single node.

Figure 2. Levels of Information.

Figure 2 illustrates these various levels of information. The advantages of being able to browse the data of a PVM job from several standpoints are countless. The supervising engineer, who does not have the time for a full detailed description, but needs a quick and dirty overview, can obtain such by looking at a "zoomed out" level, such as that in the upper left hand panel. On the other hand, the programmer may need to track how an individual process is progressing. For this, a close up view would provide more relevant and appropriate data. In any case, an appropriate visual representation can be chosen to highlight the information as it pertains to the content and context of the job. While the user can zoom in or out to any vantage point, the SUI initially provides them with four different levels of information: Global, Overview, Cluster, and Detail, each of which are described below.

Level 1. Global
Figure 3 illustrates the first of the four distinct levels of information; a zoomed out, "global" view which reflect the imagery used in more traditional looking network GUIs. In this view, only "arcs" (connections among machines) and "nodes" (the actualy machines used in a PVM job) are presented, to allow the user to look at the overall "state of the world." Importance is placed upon global activity, such as message passing and network configuration. Fine detail about job specific information is omitted to place emphasis on the hierarchical structure and connectivity.

Figure 3. The Global Level of Information.

Level 2: Overview
In the second "Overview" level, the user is still able to view the global scene, but is also presented with finer details about the network. For instance, the user is now able to see how many processes are running on a given node by the number of "hash-marks" on its screen and can easily tell what type of machine is running the job by the digital icon used to depict it.

Figure 4. The Overview Level of Information.

Level 3: Clusters
In the third level, the emphasis switches from global activity towards localized information. Node icons are much more recognizable and the use of animation, color cycling, and more dynamic techniques come into play. Nodes are placed in proximity to other nodes running components of the same specific job, and communication between the nodes are illustrated via animation of hash-marks along thrie arc lines. The user is now able to identify and track communicative problems such as message passing, bottle-necking, and overloading simply by watching animated movements in the interface.

Figure 5. The Clusters Level of Information.

Level 4: Zoomed-In: An Extreme Close Up View
The final view illustrates a much more detailed level of information, describing a specific process. In figure 6, we see a close up view of a node. At the right of the screen a dialog box is presented, displaying such specific information as the job's name, explicit amount of computational power being used, and a summary of the job task. This dialog can be edited by the user, which in turn allows for high level, direct manipulation of the job process itself.

Figure 6. The Extreme Close-Up Level of Information.

section 3: 

Using a 3D World as an Interface

Not only does the Taralogic SUI differ from existing GUIs in appearance, but also in design and implementation. The SUI was build such that both the programmer and the user would benefit. From a technical level, the SUI is designed from an object-oriented standpoint. Each one of the components, the machine nodes, hash-marks, and arc lines are all distinct "objects" that can be told how to move, interact, and visualize themselves. From the user's viewpoint, the interface and the PVM program are one in the same. There are no buttons, hidden screens, or menus; just the three dimensional "world" representing the parrellel virtual machine as a whole.

Nodes, Arcs, and Hash-Marks: Building Blocks of this 3D World
Machines that comprise the PVM and the communication between them, as seen earlier, are represented as node icons and arc lines respectively. These two components are not merely thought of as "paint on the screen," but rather, they are specific objects that can be given different attributes and qualities, and can dynamically change these over time to reflect the current state of the machines and communications they represent. That node, in turn, knows how to change its color and update its visual appearance to display these changes to the user. For example, a node can be told to color itself a certian color to denote the amount of computational power being used. A node colored red (i.e. a "hot" color) illustrates to the viewer that that machine is running a costly process, whereas a blue (i.e. a "cool" color) node represents one that uses relatively little computational power.

A node can be given one (or more) of the following attributic qualities to emphasize certian types of information:

To denote the amount of computational power being used.

The icon's physical size can be enlarged or reduced to reflect the size of the process it is running.

Information tags" stating the process name can be overlayed onto the icon.

How transparent / opaque an icon becomes is used to emphasize the "lifetime" of the job.

Digital imagery is used to state the type of machine.

In the same fashion, arc lines and hash-marks, which are also objects, can be given other attritbutes. For the arc lines:

Line Thickness
Denotes the amount of communication traffic traveling along that connection.

How long the connection has been opened.

Illustrates related types of communication.

And for hash-marks:

Color / Shape
Denotes message type.

Denotes message size.

section 4: 

Internal Structure of the SUI

There are two conponents to the Taralogic SUI, a "communication layer" and a "visualization module." The communication layer (CL) serves as a barrier between the SUI and PVM, enabling the two to exist as seperate modules. The visualization module (VM) is the "graphics engine" which visualizes the communication between the two.

Communication Layer
When users start up the SUI, the CL, conforming to traditional PVM standards, "enrolls" in the PVM and monitors all activity of the underlying system. Enrollment tells the PVM that the SUI is present and waiting for information, and that it should pass back any data about the job to the SUI so that it can create the appropriate visual output response.

Rather than pass back all of the minute details of the PVM job, the CL filters out the information sent and passes high level descriptions about the state of the job to the SUI. It obtains and translates the actual information being used by the PVM, into "visual packets" that are then used by the VM to create the appropriate visual output. This enables the communication between PVM and the SUI to exist with relatively few calls made, speeding up the output.

Figure 7. Scematic Diagram of the Taralogic SUI and PVM.

Besides containing all standard functionality as existing versions, Taralogic's PVM also includes a specialized set of instructions for use with the SUI. These instructions, listed below, are the basic framework which governs the dialog between the PVM and the CL:

int SUI_enroll(int *sui_id);

int SUI_terminate(int *sui_id);

int SUI_get_message(int message_type, void *message);

int SUI_send_message(int message_type, void *message);

int SUI_was_message_sent(NODE *host, NODE *target, int type);

int SUI_was_message_recieved(NODE *host, NODE *target, int type);

int SUI_get_num_jobs(NODE *machine, int *num_jobs);

int SUI_poll(int message_type, void *message);

The SUI_enroll function is comparitive to the enroll function used by PVM. It is called once at the start of a job and maintains a communication "pipe" to the PVM so that further messages may be sent and recieved. Its counterpart is the SUI_terminate command. This function respectively closes the pipe that the SUI_enroll command opened and exits the SUI without disrupting the actual PVM job.

The next two message, SUI_get_message and SUI_send_message also work in a similar fashion to PVM's get and snd functions. The regular get and snd functions allow the user to get and send messages to the PVM. Similarly, the SUI_get_message and the SUI_send_message are used by the CL to recieve and pass back messages from the PVM to the SUI.

The final four calls are used for quick polling of information. The SUI_was_message_sent and the SUI_was_message_recieved are for figuring out if a message actually made it from one node to another. The SUI_get_num_jobs finds out how many processes are running on a given machine. The final function call, SUI_poll, is used to gather batches of information on a specific topic.

Visualization Module
Once data is recieved, the CL translates it into visual descriptions that are then sent to the VM so that it may create the appropriate visual output. For each type of message that can be recieved, there is a specific visual response that can be produced. For example, if the CL recieved information that a message was sent from one machine to another, the VM would produce the response of animating a hash-mark along the arc line that connected the two nodes. The hash-mark's color and size would further emphasize the type and size of message sent, allowing the user to track the communication between the two nodes.

By the time the information is recieved by the VM, it has already been translated into an appropriate representation by the CL. Since the design of the SUI is object-oriented, given the information passed to it by the CL, the VM merely tells each object how it should look, or what it should do, and that object changes itself. Using the example just stated, what would actually happen internally is that the VM would tell the node sending the message to create a hash-mark rectangle and slowly move it along the arc line. In turn, that node draws a rectangle of the appropriate size and color on the screen and animates its movement from one node to the other.

How They Work Together: The SUI and the PVM
To further illustrate how the components of the SUI and the PVM interact together, let us look at the following example. For this example, we will say that the task is to visually illustrate a message being passed from one node in the PVM to another.

The CL first asks the PVM if a message was sent and stores this information in the variable "answer."

answer = SUI_was_message_sent(DEC_1, SGI_1, SMALL_PACKET);

The above call asks the PVM if a node called "DEC_1" sent out a "SMALL_PACKET" message (i.e. a message whose size was 8 bytes) to the "SGI_1" node. If the answer is "yes", the SUI first illustrates that the message was sent be creating the appropriate visual output; which is to animate a hash-mark moving along the arc connecting the "DEC_1" icon to the "SGI_1" icon. To do so, the following call to the VM is made:


This tells that VM to visualize a small message being passed from the node called "DEC_1" to the node "SGI_1." Upon recieving this information, the VM visually creates a small hash-mark rectangle on the screen and slowly moves it along the arc line connecting the two icons. This mark moves along the arc until it gets halfway across the line. Once the mark reaches the halfway point, the CL sends the following message to the PVM asking if the message was ever recieved by the "target" machine (i.e. the "SGI_1").

answer = SUI_was_message_recieved(DEC_1, SGI_1, SMALL_PACKET);

If the answer is again "yes," the CL tells the VM to finish off the visual output by making the following call that will move the hash-mark fully across the arc line.


section 5: 

Configuration Specifications

The Taralogic Smart User Interface, version 1.0, operates on Unix based machines running the X window system and Ultrix 4.3 system software. These include the Digital DECstation 5000 machines, both the Hewlett-Packard 700/Snake and 800/Bobcat series and the Sun4. The release version of the SUI (2.0), will operate on any machine running the OpenGL graphics software, including Silicon Graphic workstations, Hewlett Packard machines, Suns, and the Digital Alpha.

Future hardware/software configurations (in version 3.0 and greater) will also include WindowsNT based machines and PCs running OpenGL.