deploying web-based visual exploration tools on the grid

The easy access to low-cost, high-performance, network-aware computers

has impacted the way scientists conduct their research.While productivity has improved, scientists are bur-dened by the increasing size of the data they generate.Visualization is an effective and economical means toexplore the data and the insights obtained through sci-entific study. However, due to the size of the generat-ed data, the scientists, their data, and the visualizationsoftware are often located on different machines at geo-

graphically distributed locations.Grid-based computing solves

some of these problems by facilitat-ing access to these differentresources. But management in agrid-based environment isn’t cen-tralized. To use grid resources effec-tively, researchers need a centralaccess point to manage theresources, provide a visual means toexplore the data, and record theseexplorations for further investiga-tion and dissemination. This articledescribes such a system that’s beingdeveloped jointly by the Universityof California, Davis, and theLawrence Berkeley National Labo-ratory (LBNL).

The centralized system acts as a portal into grid-enabled visualization systems. Scientists using the por-tal can focus on the important task of extracting insightsfrom their data through visualization instead of havingto worry about process management. Because scientistsat LBNL and their collaborators require access to theportal from around the world, the portal’s interface isentirely Web-based. Authenticated users only need astandards-compliant Web browser to explore their datafrom anywhere in the world.

The portal provides a Web-based interface not just forexploring but also for encapsulating visualization data.Encapsulating the process lets users reproduce the visu-alization results for validation or extend those results

by continuing data exploration. In this article, we dis-cuss the integration of our grid-enabled visualizationserver, the visualization Web application that performsthe visualization session management, and the Web-based interface.

Grid-based portalsA portal is a single point of presence (typically host-

ed on the Web) that provides centralized access towidely distributed collections of information or ser-vices. The portal organizes this information to hide itscomplexity and location from the user. Portal technol-ogy also provides location-independent access to stateinformation. When you log in to the URL of the por-tal’s interface, you can access the same view of yourpersonalized environment and data. Yahoo and Hot-mail are typical consumer-oriented examples of thiskind of capability. Grid portals extend the portal par-adigm to organize and manage widely distributed com-puting resources, software components, and servicesthat support collaboration among the people that forma virtual organization.

Many virtual collaboration and distributed applicationdevelopers have turned to grid portals as the primary wayto hide the complexity of distributed applications undera single interface. (See the sidebar “Related Web- andGrid-Based Visualization Work” for information aboutrelated research.) Consequently, several portal develop-ment toolkits have emerged, including the San DiegoSupercomputing Center (SDSC) GridPort (http://gridport.npaci.edu/), the Grid Portal Development Kit(http://www.itg.lbl.gov/grid/projects/GPDK/), andGridSphere (http://www.ascportal.org/).1

Portal interfaces need not be Web-based, but Web por-tals have been widely adopted by the grid community,in part because of the ability to leverage the wide vari-ety of robust development tools, components, and plat-forms that have already been developed for e-commerceservers. Also, given the ubiquitous availability of the Weband the comparatively uniform cross-platform pro-gramming model it offers for the client interface, theWeb makes an attractive platform for a widely deployed

Graphics Applications for Grid Computing

Our Web-based portal lets

users explore, encapsulate,

and disseminate visualization

results over the grid. This

portal integrates an interface

client, a visualization Web

application, and a centralized

application server.

T.J. Jankun-Kelly, Oliver Kreylos, Kwan-Liu Ma,Bernd Hamann, and Kenneth I. JoyUniversity of California, Davis

John Shalf and E. Wes BethelLawrence Berkeley National Laboratory

Deploying Web-Based VisualExploration Toolson the Grid

40 March/April 2003 Published by the IEEE Computer Society 0272-1716/03/$17.00 © 2003 IEEE

client interface to grid services. Furthermore, the Webrequires essentially no custom software installation forthe scientists who use the service.

We regard the spreadsheet approach as an excellent

match for the Web’s interaction modality. Spreadsheetscan capitalize on the HTML table display paradigm aswell as the use of hyperlinks to drill down into informa-tion content. We can easily integrate such an interface

IEEE Computer Graphics and Applications 41

Research on controlling visualizations using thegrid typically falls into two areas: Web-basedvisualization systems and distributed visualizationin grid-like environments. Although there has beenlimited interaction between these fields, mostprevious research has focused on only one or theother. Ang and colleagues1 described one of thefirst Web-based visualization systems. Ang’s systemdisplays visualization results within a Web pageusing an embedded application (an applet). Theresults are controlled using a launched applicationon the client side. This launched applicationcommunicates with the visualization server torequest rendering. The visualization server thencommunicates with the applet to display the result.

Wood and colleagues2 generalized Ang’sapproach into four different compositions of Web-based visualization. In the first scenario, the systemsends only images to the client with no userinteraction with the visualization. The secondscenario lets a user manipulate the result, but a usercan’t change the visualization parameters. The nextscenario supports full control of the visualization,including the type of visualization performed, butrequires significant resources on the client side. Thelast scenario, and the one implemented by bothWood and Ang, supports Web-based interaction forcontrolling the parameters and the visualizationtype performed without requiring a significantclient installation. The majority of subsequent Web-based visualizations follow this last approach, usingan applet to allow interaction with the visualization.Our Web interface combines aspects of the first andlast approach.

W. Lefer3 and C. Bajaj and S. Cutchin4

implemented a Web-based interface to distributedor grid-based visualization systems. Lefer’svisualization system dynamically and transparentlyshares the processing load on a local area network.Another interesting property of Lefer’s approach isthat interaction with the visualization systemhappens entirely through HTML-based forms. Weuse an all-HTML approach as well, but augment itwith JavaScript. This approach eliminates the needfor HTML forms by letting the JavaScript eventsinvoke actions on the visualization server. Bajaj’swork also coordinates the users, distributedresources, and the use of those resources. Our Webinterface doesn’t manage the grid resources; thevisualization portal as a whole handles this task.

Researchers have also investigated visualizationusing grid resources that don’t involve Web-basedinterfaces. GridMapper5 addresses the problem ofdetermining the performance of grid

computations by collating and visualizingdistributed information. This information isdynamically gathered from the sites performingthe computation on the grid. TeraVision6 lets usersseamlessly present and interact with graphics, suchas visualizations over the AccessGrid. Finally,Cactus7 is a grid-based, computational astrophysicsframework that incorporates various visualizationmethods: a Web-based slice viewer of thesimulation volumes created at each node, a remoteisosurfacer (with the isosurface calculated locally ateach compute source and rendered elsewhere),and Visapult, an image-based volume renderer.

Each of these approaches (except the Webinterface for Cactus) requires a thick-clientinstallation to perform the visualization. In otherwords, for remote users, their platform and systemcapabilities must be determined before theappropriate grid visualization client can beinstalled and launched. Our approach eliminatesthe need for a thick client by requiring only astandard Web browser.

References1. C.S. Ang, D.C. Martin, and M.D. Doyle, “Integrated

Control of Distributed Volume Visualization Throughthe World Wide Web,” Proc. IEEE Conf. Visualization1994, IEEE CS Press, Oct. 1994, pp 13-20.

2. J. Wood, K. Brodlie, and H. Wright, “Visualization overthe World Wide Web and Its Application to Environ-mental Data,” Proc. IEEE Conf. Visualization 1996, IEEECS Press, 1996, pp. 81-86.

3. W. Lefer, “A Distributed Architecture for a Web-BasedVisualization Service,” Proc. Ninth Eurographics Work-shop on Visualization in Scientific Computing, Springer-Verlag, 1998.

4. C. Bajaj and S. Cutchin, “Web-Based CollaborativeVisualization of Distributed and Parallel Simulation,”Proc. 1999 IEEE Parallel Visualization and Graphics Sym-posium, IEEE CS Press, 1999, pp. 47-54.

5. W. Allcock et al., “GridMapper: A Tool for Visualizingthe Behavior of Large-Scale Distributed Systems,” Proc.High Performance Distributed Computing. IEEE CS Press,2002, pp. 179-87.

6. J. Leigh et al., “TeraVision: A Platform and Software-Inde-pendent Solution for Real-Time Display Distribution inAdvanced Collaborative Environments,” Proc. Access Grid Retreat; http://www-fp.mcs.anl.gov/fl/accessgrid/agretreat2002/Proc./leightera.pdf.

7. G. Allen et al., “Solving Einstein’s Equations on Super-computers,” Computer, vol. 32, no. 12, Dec. 1999, pp.52-58.

Related Web- and Grid-Based Visualization Work

with other ongoing portal development efforts through-out the grid community.

Web-based visualizationThe system we’re developing for Web-based visual

data exploration over the grid consists of three majorcomponents:

� a Web-based user interface to grid-enabled visual-ization services,

� a visualization Web application that tracks the explo-ration of visualization results, and

� the portal application server that manages and coor-dinates the authentication for and use of gridresources.

The application server (the VisPortal) uses establishedgrid technologies to handle user and resource man-agement. Once the system authenticates the user, theWeb application initializes a new visualization explo-ration session.

The Web application (also called a servlet) is a programon the Web server that communicates with the client viaHTTP. The servlet maintains the visualization sessionstate. After the application initializes the visualizationsession, the Web-based visualization interface loads inthe client’s Web browser. As the visualization session pro-

gresses, the Web application stores the visualizationresults and the relationships between those results. Final-ly, when the user finishes visualizing the data, the appli-cation closes the session. The user can then initializeanother session or reexamine previous explorations.

Sheet-like interfaceOur Web interface (the WebSheet) implements an

entirely Web-based version of the visualization explo-ration sheet-like interface discussed elsewhere.2 Theoriginal spreadsheet-like interface (the VisSheet) wasdesigned to assist visualization exploration by provid-ing context for where users are, where they have been,and where they might go. The VisSheet handles thesetasks by providing a movable, scalable window into thevisualization parameter space. The application displaysonly two visualization parameters at a time: one alongthe rows and another along the columns. For the nondis-played parameters, the application maintains a set ofdefault values that can be updated at runtime. The appli-cation renders parameter values as glyphs. Cells repre-senting a combination of the row, column, and defaultparameter values display the visualization results. Bychanging the default values for nondisplayed parame-ters, users can move the window in the visualizationspace. Thus, the data exploration process becomes theprocess of manipulating the spreadsheet windowthrough visualization space.

Our sheet-like Web interface shares many character-istics with the VisSheet. The interface refines the initialVisSheet design to let a user easily modify default anddisplayed parameters through the default parameter barand drop-down row and column parameter lists (Figure1). The default bar assists in identifying parameter val-ues and their corresponding results. The parameters arealways the parameters belonging to a cell’s row and col-umn, combined with the default values for the otherparameters in the default bar.

Interaction with the tabular display remains essential-ly unchanged. Users can add, edit, or remove parametervalues; render or view a cell’s image; and apply parame-ter and value operators to generate new rows, columns,or cells. The implementations of VisSheet and WebSheet,however, differ significantly. Design considerations forour Web interface required several modifications to theoriginal VisSheet. Due to the wide range of platforms sci-entists can use to access the Web interface, we wanted tocreate a platform-independent solution. However, thesoftware environment of each user is unlikely to be thesame, and the difficulty in remotely installing or theunavailability of plug-ins for certain environments meantthat we couldn’t use Macromedia’s Flash or Sun’s Java.

For example, the incompatibilities of Java on differ-ent platforms or between different versions make it dif-ficult to use in a robust client setting. The onlyassumption we made was that a user possesses astandards-compliant Web browser with ECMAScript/JavaScript and cookie support. We designed the systemso that no permanent state would be stored on the clientmachine. By keeping the state in a centralized, Web-accessible location, users can reexamine visualizationsessions from different locations without losing any


42 March/April 2003

1 The AMRWebSheet interface, an example of our Webinterface to grid-based visualizations. The interfaceconsists of three major areas: the default parameter barthat displays and allows the modification of the defaultparameter values; the displayed row and column para-meter drop-down lists; and the tabular result display.The first two components can change the location ofthe tabular window in visualization parameter space,while the last component can request new results.

information. Because of these constraints, our interfaceis Web-based and not a single-user, network-unawareJava application like the VisSheet.

Several consequences, however, result from our Webinterface design. Interactivity partially suffers in com-parison to the VisSheet. The VisSheet uses the JavaFoundation Classes (JFC) for its user interface. JFC sup-ports a rich set of user-interface elements and cus-tomizability. In contrast, the interface elements offeredby HTML are limited. HTML supports only checkboxes,radio buttons, push buttons, lists, menus, and text fields.JavaScript can help overcome many of these limitationsby letting different portions of the HTML page react tomouse events. Even so, HTML can’t render glyph icons,for example, that represent the parameter values in adrop-down list for the default parameter bar.

Furthermore, JFC provides more functionality than

raw JavaScript. Our Web interface can’t query any sig-nificant information about a client’s machine. Methodsexist to extract the client’s browser information or todownload a single file from the client machine, but suchtransfers aren’t optimized for the large data sizes com-mon in visualization applications.

Web-based encapsulationThe Web-based visualization interface structures the

visualization-exploration process, which the applicationserver captures. By capturing the process, we can ensurethat the visualization results generated, and the rela-tionships between those results, aren’t lost when the visu-alization session ends. To record the visualizationprocess, we use a formal model of the visualizationexploration process (see the “Visualization ExplorationModel” sidebar). As the application renders each


Visualization Exploration Process ModelThe visualization process for information and scientific

visualization is an iterative sequence of user-appliedtransformations from data to view.1-3 The fundamentaloperation that occurs during the visualization process is theformation of parameter value sets to derive visualizationresults. These parameter value sets (p-sets) possess aparameter value for each parameter in a visualizationtransform—the function that performs the mapping of datato visual primitives. When applied to a visualizationtransform, a p-set corresponds to a rendered result. Otherresearch describes a model of the visualization processbased on a parameter derivation calculus.4 The calculusdefines how p-sets and the results rendered from them arederived from previous p-sets.

User interaction with the visualization system creates newp-sets in one of three ways:

� Parameter application. Parameter values from a p-set areapplied by the user to another p-set to generate a new p-set. For example, a new color map replaces an old colormap in a previously generated p-set to render a new resultfrom the new p-set.

� Parameter range sweep. Users can interactively manipulatea single parameter value over a range between an initialand final p-set. For example, users can generate a range ofview positions by dragging a mouse pointer in the renderwindow.

� Function parameter generation. A function/operator gener-ates a set of parameter values to be used in a p-set. Forexample, applying a set union operator to two previouslyused opacity maps creates a new opacity map.

In the AMRWebSheet, we use only two types ofparameter derivations: parameter application and functionparameter generation. When the system renders a cell, itcollects the parameters for that cell in a p-set; this processcorresponds to a parameter application of the newparameter values to the p-set from the last generated result.Function parameter generation occurs when a user appliesan operator in the AMRWebSheet to generate newparameter values.

The parameter derivation calculus is the basis forrecording a visualization exploration session. Formally, avisualization session consists of a set of visualization sessionresults. A visualization session result contains a p-set, thevisualization result derived from the p-set, a time stamp toplace the result in temporal context, and a parameterderivation calculus instance detailing how the result wasderived. Each session result represents the generation of asingle visualization result.

However, as more than one result can be generated in asingle user action, such as when applying a parameteroperator, multiple session results can share the same timestamp. For each visualization result (an image), theAMRWebSheet stores its corresponding visualization sessionresult (information about that image). This approach differsfrom previous Web-based collaborative visualization work5

where only parameters for particular visualizations and theirposition in a tree of parameter snapshots are stored forfuture collaboration. In our system, the application storesthe complete exploration and derivation information(encapsulated in session results) as an XML document onthe portal for later access and reexploration.

References1. S.K. Card, J. D. Mackinlay, and B. Shneiderman, Readings in Infor-

mation Visualization: Using Vision to Think, Morgan Kaufmann Pub-lishers, 1999.

2. C. Upson et al., “The Application Visualization System: A Com-putational Environment for Scientific Visualization,” IEEE Com-puter Graphics and Applications, vol. 9, no. 4, July 1989, pp. 30-42.

3. R.B. Haber and D.A. McNabb, “Visualization Idioms: A Concep-tual Model for Scientific Visualization Systems,” Visualization inScientific Computing, G. Nielson and B. Shriver, eds., IEEE CS Press,1990, pp. 74-93.

4. T.J. Jankun-Kelly, K.-L. Ma, and M. Gertz, “A Model for the Visu-alization Exploration Process,” Proc. IEEE Conf. Visualization 2002,IEEE CS Press, 2002, pp. 323-330.

5. K. Brodlie, S. Lovegrove, and J. Wood, “Harnessing the Web forScientific Visualization,” Computer Graphics, vol. 34, no. 1, Feb.2000, pp. 10-12.

requested image, the server stores the correspondingvisualization session result. Thus, at the end of a session,all the rendered images—including the parameter valuesets (p-sets) used for creating those images—the timethe image was generated, and that image’s relation toprevious images, are available for later use.

The visualization Web application is the entry point toour Web interface. When loaded from the portal, theservlet provides a user with two options: starting a newvisualization session or viewing previous sessions. Whenthe user chooses to start a new session, another servlet,the user-interface servlet, handles interactions with thevisualization interface. As the user requests images oradds, edits, or removes parameter values, the underly-ing JavaScript sends HTTP requests to this servlet. Theservlet then processes the requests, contacting the ren-dering server if needed, and updates the visualizationsession and the client. The interface servlet representsthe interface’s state. If a user chooses to examine previ-ous sessions, the application loads the session servlet.

Initially, the application presents a list of all the pre-vious explorations, sorted by date, to the user. A usercan reload a previous session in the Web interface byclicking on its corresponding link. Users can add newresults to this session. When the session terminates, theapplication will store these results along with the oldsession information. This capability is crucial to the Vis-Portal because scientists must be able to distribute theirwork over time as well as over space.

The session servlet also supports the ability to viewprevious sessions. By selecting the “view as HTML”option, the user initiates the generation of an HTMLpage that summarizes the corresponding visualizationsession. Each result, the parameters corresponding tothat result, and the parent and child results are all partof the HTML page. The HTML page serves as anoverview of a previous visualization session and as doc-umentation of that session. First, the Web page fully doc-uments the visualization process as it completelydescribes the information captured by the visualizationprocess model. Second, users can add or edit annota-tions of results. The application stores these annotationson the server for others to access. Scientists can usethese annotations to flag certain results as interesting.

The session servlet also lets users view an overviewgraph. While the HTML session document describes thevisualization in detail, it’s difficult to obtain a sense ofthe visualization at a glance. By selecting the “viewoverview graph” option from the session list, the servletgenerates a graph depicting the results and various rela-tionships between the results. The user chooses a “visu-alization metric” that determines how the applicationdisplays the graph.

All the graphs use a new radial focus-context visual-ization technique, in which the radial distance from thecenter node to another node represents the distance ofthat node’s p-set from the center result’s p-set accord-ing to the chosen metric. As the distance increases, thesize of the node and its radial separation decreases tolet the system display all results simultaneously. Exam-ple metrics include those that measure how a result wasderived from another result (a directed edge only existsif the first result derives the second) and those that mea-sure the temporal distance of the result (a directed edgeonly exists if the first result was rendered immediatelybefore the second result). Different metrics and theHTML session view provide the means to understandwhat occurred during a visualization session.

Application domainThe Web interface and visualization Web application

can help with several kinds of scientific visualizationproblems. Scientists at LBNL are particularly interestedin visualizing Adaptive Mesh Refinement (AMR) data.Many of the most challenging problems in numericalmodeling involve meshes with huge ratios of scale. Forexample, when modeling the fuel-injection system ofan automobile, you must model the fluid dynamics ofthe injector’s orifice as well as the dynamics of fuel–airmixing in a cylinder chamber. A typical finite-differenceor finite-element simulation covers the entire domainwith a uniform mesh of cells, the smallest of which mustbe less than half the size of the smallest structure beingmodeled.1 Given the huge ratio of scale in these struc-tures, it would be impossible to span this range of spa-tial scales without using impractically large meshes.

AMR techniques for finite-difference codes use refine-ment criteria that create higher-resolution meshes onlyin areas in which they’re needed. For example, large-scale structures of superclusters in cosmology are rela-tively compact; it would be a waste to modeluninteresting events in the voids using the same meshresolution as that used for the events that occur in thedense regions. With current methods, the refined mesh-es must be an even multiple of the size of the parentmeshes on which they’re placed. Furthermore, regionscan be refined in a recursive process that can descendthrough many levels of resolution.1

For second- or higher-order methods, the cell sizemust be even smaller. The cosmology simulations doneby Norman, Bryan, and Abel3 that modeled the forma-tion of the first stars in the universe require 27 levels ofrefinement, covering an eight-billion-to-one ratio ofscale using a fraction of the memory required for a uni-form mesh. Starting with a 1283 base mesh for the AMRsimulation, an equivalent simulation on a uniform meshwould require at least a 1036 element uniform mesh.AMR makes these extreme problems tractable fortoday’s supercomputers. These problems also pose sig-nificant challenges for visualization researchers.

AMR data structures don’t fit into any of the tradi-tional data structures used in modern visualization tech-niques and systems.4 Sampling AMR data onto uniformmeshes results in the same data-handling problems thatmotivated the development of AMR in the first place.


44 March/April 2003

The Web interface and visualization Web

application can help with several kinds of

scientific visualization problems.

Naive conversion of AMR data to finite-element datastructures composed of hexahedral cells requires us touse memory-inefficient data structures with compara-tively inefficient visualization algorithms. Furthermore,dangling nodes at the coarse–fine mesh boundaries cancause cracks. Direct application of finite-difference tech-niques to an AMR hierarchy leads to visual artifacts atthe coarse-fine boundaries as well as to significant data-management issues. A typical desktop system can’tprocess these deep hierarchies interactively. Conse-quently, few visualization algorithms can be directlyapplied to hierarchical meshes, and essentially no off-the-shelf commercial software is available for visualiz-ing AMR data. It’s important to develop the tools andtechniques necessary to navigate data sets with hugeratios of scale in a simple and widely accessible manner.

Given the growing interest in AMR simulation andthe need for scalable systems supporting remote datavisualization, we developed a parallel multiprocessorvolume renderer for AMR data. (For more informationabout this, see the “AMR Volume Rendering” sidebar onthe next page.) Because the majority of LBNL visualiza-tion users are off-site and have comparatively smallerresources at their disposal, we created a client–serverarchitecture so the entire system can be accessible overthe grid using a traditional client interface. The AMR-WebSheet project—an implementation of the Web-Sheet—aims to extend access to this parallel-renderingback end using an entirely Web-based interface suitablefor emerging Web-based collaborations.

ArchitectureFigure 2 summarizes the VisPortal/AMRWebSheet

architecture. We implemented the AMRWebSheet inter-face and Web application in a flexible visualizationexploration and encapsulation framework. The frame-work, implemented in Python, consists of a series ofobjects that manage visualization sessions and the inter-face’s interactions with the sessions. Visualization ses-sion, transform, parameter, result, and derivation

objects exist within the framework to capture the infor-mation described in the visualization explorationprocess model.

A view object represents the interactions betweenvisualization interfaces and the visualization sessionsin a platform-independent manner. Other interfaceobjects representing general visualization explorationspreadsheet views and state also exist within the frame-work. The system uses these classes as the basis for dif-ferent implementations of the VisSheet. Oneimplementation recreates the original VisSheet as a Javaapplication using Jython (the Java version of Python)to communicate between the framework and the Javaclasses. The servlet uses the framework to implementthe AMRWebSheet.

We implemented the Web application servlets thatmanage visualization sessions in Python using the Web-ware application environment (http://webware.sourceforge.net/). We use Apache running under Linuxto serve Web pages. A group of servlets creates, process-es, and stores sessions. When a client connects, theapplication creates a new session identified by a tem-porary cookie in addition to servlet-persistent objects.Whenever a user interacts with the generated HTMLinterface, the application communicates the AMRWeb-Sheet HTTP requests to the interface servlet. Thisrequest in turn modifies the visualization session state.When the client needs to update, the server performs arefresh to display the new information. When a sessionterminates or expires due to inactivity, the applicationencodes the session results as an XML document on theapplication server for later retrieval.

The application server handles all communicationbetween the AMR volume renderer and the AMRWeb-Sheet. When the AMRWebSheet requests a result, a visu-alization transformation class instance on the Webapplication requests the corresponding result from thevolume-rendering server. When the volume rendererreturns the corresponding result, the Web applicationstores a copy with the visualization session results. The


The grid

Authenticate,transfer data

Logon, transfer data,start visualization

Request result Request result

Return result

Transferdata

Launchvisualizationsession

Launch, update

Web browser

VisPortal

VisualizationWeb applicationAMRWebSheet AMR renderer

Portalapplication server

2 The VisPortal/AMRWebSheet architecture. Elements within the blue box represent Web pages with which theuser interacts; green boxes represent Web servers; and the other nodes represent grid-accessible resources.Dashed lines represent HTTP/HTTPS connections for HTML and images (for the client) and connection requests(for the server), while solid lines represent TCP connections. A line’s label indicates the action performed over thatlink. For bidirectional connections, the top label corresponds to actions initiated from the left entity, while thebottom label corresponds to actions initiated from the right entity. The AMR renderer can reside anywhere on thegrid. The VisPortal initializes the connection between the renderer and the visualization Web application when auser first requests a visualization.


46 March/April 2003

AMR Volume RenderingThe current rendering back end for AMR data is

a hardware-assisted 3D texture-based parallelvolume renderer.1 AMR hierarchies are typicallyhighly irregular and can’t be rendered directly

using graphics hardware’s texture-mappingcapabilities (Figure A). Instead, a given AMRhierarchy must be homogenized, which meansthat it has to be transformed into a set ofnonoverlapping rectangular grids with acyclicvisibility order for any viewing direction. Thisprocess generally involves removing parts oflower-resolution grids overlayed by higher-resolution grids, and then splitting the resultingnonconvex grid regions into rectangular gridpatches.

Our method uses a tree-based approach, in a k-d tree covering the entire domain of an AMR dataset. AMR grids are inserted one at a time, startingwith lowest-resolution grids. Figure B shows a 2DAMR hierarchy and its homogenizing k-d tree.Once an AMR hierarchy is homogenized, it can berendered from arbitrary viewpoints by sorting allgrid patches on-the-fly in back-to-front visibilityorder. All grid patches are rendered independentlyinto the same color buffer using alpha blending,performing implicit compositing of partial-rendering results.

For parallel rendering on n nodes, the sorted listof grid patches is chopped into n sequences ofapproximately equal rendering cost. We estimaterendering cost during k-d tree traversal. Thesequences are then assigned to rendering nodes.This step is performed on all nodes in parallel anddoesn’t require communication between nodes.Each node renders its sequence of patches into itsown color buffer. When rendering is done, nodesexchange color buffers to composite a completerendering. Because the rendering bottleneck is grid-patch rendering, and compositing is performed inhardware, a simple binary tree compositingstrategy suffices. It could be replaced with a binary-swap compositing strategy should the need arise,but the rendering algorithm is independent fromthe choice of compositing strategy.

The portal version of the parallel renderercurrently runs on an SGI Onyx3400 with two IR4graphics pipes. A software parallel renderer canalso be used on cluster or distributed-memoryarchitectures. At the University of California, Davis,the renderer runs on two Linux clusters (with 4and 16 nodes, respectively) using NVidia GeForce3graphics cards for rendering and 100 BaseTEthernet for internode communication. You canread more information about this setupelsewhere.1

Reference1. O. Kreylos et al., Remote Interactive Direct Volume Ren-

dering of AMR Data, tech. report LBNL49954, LawrenceBerkeley National Laboratory, 2002.

A Volume rendering of the argon bubble with superimposed AMR gridhierarchy.

B Homogenizing a 2D AMR hierarchy. The hierarchy has auniform refinement ratio of two. Bold lines denote grid bound-aries. All hierarchy levels consist of two grids. Finer grids cancross boundaries between coarser grids. (1) Original AMRhierarchy with overlapping grids. (2) Homogenized hierarchywith nonoverlapping rectangular grid patches.

(1)

(2)

application then displays the result by forcing a refreshon the client’s Web browser.

The VisPortal handles access to the visualization inter-face. It provides a single point of access to launch and con-trol all the components of this distributed tool. We basedthe VisPortal’s architecture on the Grid Portal Develop-ment Kit that uses the Globus Project’s Java CommodityGrid (CoG) toolkit (http://www.globus.org/cog/java/)in conjunction with Tomcat, an Open Source Java Serv-er Pages application server (http://jakarta.apache.org/tomcat/). Users authenticate to the portal using theMyProxyServer (http://www.ncsa.uiuc.edu/Divisions/ACES/MyProxy/) to supply their X.509-delegated cre-dentials. The Grid Security Infrastructure (GSI) X.509credentials make it possible for the portal applicationserver to transfer files, launch jobs, and otherwise accessany Globus grid services on remote hosts using only a sin-gle login.

From the user’s standpoint, the portal hides a complexapplication-launching mechanism for a multicomponentdistributed application. For a thick-client application,the portal launches a parallel-computing component andbrokers a direct socket connection between this com-puting component and a high-performance back-enddata source. It then launches the thick client through theWeb browser using appropriate multipurpose Internetmail extensions-type definitions. The thick client in turnconnects back to the remotely located parallel-visualization component, thereby completing the dis-tributed visualization application. The system hides thisentire elaborate launching procedure from the user. Theuser simply selects remotely located data and presses abutton to start the visualization application.

The AMRWebSheet supports an even simpler launch-ing mechanism where the back end connects directly tothe Python visualization Web application. The servermakes requests of the back end and then formats theoutput images appropriately for the HTML interface. Ifthe back end is located on a Silicon Graphics machine,it can employ hardware-assisted off-screen renderingusing Infinite Reality Engine pipes. If the back-end hostis a cluster or distributed-memory computing architec-ture, it can employ the parallel software rendering backend. Again, the portal client interface hides the com-plexity from the user.

The AMRWebSheet’s performance depends on theperformance of the

� AMR volume renderer,� visualization application server, and� user’s Web browser.

Variations in network trafficbetween the renderer, applicationserver, and client can also affect per-formance. Table 1 provides perfor-mance measures for the elementsunder our control: the volume ren-derer and the application server. Forthis test, we used an AMR data setconsisting of 501 time steps and 640x 256 x 256 cells at the finest level.

We measured performance in seconds for three differ-ent hierarchy levels (0 being the coarsest and 2 beingthe finest) using an 800 x 600 pixel image as our out-put. We collected two sets of performance data: one forthe initial loading of the data set (which requires thehardware textures on the SGI Onyx3400 renderer to beinitialized) and one for preloaded data (and pregener-ated textures).

As the table shows, the rendering time depends onthe maximum level rendered, while the applicationserver processing time is nearly constant. We expectedthis result because the application server only process-es completed images, which don’t depend significantlyon the rendered hierarchy level. Processing on the appli-cation server only occurs once when a result is initiallyrendered. Subsequent requests for the same image (suchas when the HTML page is refreshed to add new images)are either cached by the Web browser (which doesn’trequire retransmission) or cached by the applicationserver (which requires retransmission over the network,but no further rendering).

Usage scenarioTo demonstrate the VisPortal/AMRWebSheet con-

cepts, we’ll describe a typical scenario. In this scenario, ascientist at LBNL named Alice decides to visualize resultsfrom a shock-refraction and mixing computational fluiddynamics (CFD) simulation. The data set shows the timeevolution of an argon bubble after being disturbed by ashock wave. The bubble moves steadily from one side ofthe volume used for the simulation to the other, whiledeforming. The user is interested in a particular time stepin the later stages of the simulation. The data set is locat-ed on the LBNL intranet and is accessible over the grid.

Alice first enters the VisPortal URL into her Web brows-er. After logging onto the system, she uses the portal’saccess to the grid to transfer the argon bubble data setfrom its original location to the AMR volume rendererserver. Because Alice’s virtual organization lets her accessthe AMR renderer via the grid, the system authenticatesthe transfer. The system hides the complexities of thetransfer (such as using GridFTP) from Alice. She thenrequests a new visualization session from the portal.Again, the system verifies Alice’s credentials, this timeconfirming that she can access the visualization ser-vice—all the authentication occurs behind the scenes.

Once the verification is complete, the portal transfersthe authentication to the visualization Web application.Upon initialization, the Web application determineswhether Alice wants to start a new visualization or view


Table 1. Performance measurements of the AMR volume renderer and theAMRWebSheet application server.

Initial Data Loaded Preloaded Data Renderer Application Server Renderer Application Server

Levels (seconds) (seconds) (seconds) (seconds)

0 0.29 0.35 0.30 0.31 1 0.32 0.36 0.30 0.32 2 1.4 0.37 0.53 0.30

or expand an older session. In this scenario, she starts anew visualization session. After specifying an initial dataset, the AMRWebSheet loads in Alice’s browser. She thenexplores the data via the Web page interface until she issatisfied with the results (Figure 1). At this point, Aliceterminates the visualization session and exits the por-tal. When she exits, the system automatically recordsthe visualization session.

At some later date, Alice’s colleague, named Bob, wish-es to verify the results generated during the visualization.Bob is also part of Alice’s virtual organization. Like Alice,Bob logs on to the VisPortal. Unlike Alice, Bob wants toview a previous visualization session instead of a new one.The visualization Web application presents Bob with alist of sessions from which he can choose. Bob first choos-es to examine an overview graph of the visualization ses-sion (Figure 3). After familiarizing himself with thevisualization results, Bob loads the HTML session docu-ment (Figure 4). Bob then annotates a few results of inter-est and exits the system. As with the original session, thevisualization Web application stores Bob’s annotationsautomatically when he exits. Later, Alice can reload thesession, view Bob’s comments, and perhaps add somecomments of her own. The portal lets these scientistsfocus on using their data rather than managing it.

Future workThe work described here represents one aspect of the

VisPortal project. We’re actively developing three coreareas: the underlying portal application server, the visu-al-exploration tools, and the session-management capa-bilities. For the application server, our current workfocuses on improving its low-level implementation andthe connection between the Grid Portal DevelopmentKit and the various CoGs. This work includes addingsupport for a Python CoG for easier integration of thevisualization exploration and encapsulation frameworkwith the grid. Finally, we’re also working on integratinga database management system (DBMS) with the appli-cation server. Once complete, authentication, sessionmanagement, and resource allocation will use theDBMS to record portal-wide usage behavior.

The AMRWebSheet is only one of several visualiza-tion interfaces planned for the VisPortal. Visapult, avisualization system that uses both client and serverresources to perform interactive visualization (see thearticle about Cactus and Visapult elsewhere in thisissue) has already been integrated with an earlier ver-sion of the portal. Researchers are also investigatingalternate Web-based VisSheet implementations. Forexample, a VisSheet-like interface for visualizationsusing Kitware’s Visualization Toolkit would vastlyincrease the potential number of visualization applica-tions used by scientists interacting with the portal.

Additionally, we’re interested in using more gridresources for the visualization. The interface shouldallow access to visualization resources, numeric and sta-tistical analysis codes, and other related services. Thegrid would then transparently manage the resource dis-covery, process allocation, and data transport betweenthese services. The interface could be adapted to sup-port computational steering of grid-based simulations.


48 March/April 2003

3 Parameter session graph for the session shown inFigure 1. The edges indicate that only one parametervalue differs between the two resulting images. Sessiongraphs provide an overview of different informationabout the visualization session.

4 HTML session page for the session shown in Figure 1. The page provides asummary of the visualization session and supports the annotation of results.

You could then visualize results as they’re generated inone Web browser window and modify simulation para-meters in another window.

The Web application server currently encapsulatesthe visualization session from the AMRWebSheet.Although the system stores previous sessions, we couldexploit more information stored within them. For exam-ple, when the system renders the same result in two dif-ferent visualization sessions, the server stores this resultand its corresponding p-set multiple times. By integrat-ing the session information management with theplanned application server DBMS, we could eliminatethis redundant storage. In addition, storing visualiza-tion session information in a DBMS would let differentportal applications use the session. Potentially, the por-tal designers could analyze this session information,combined with other portal usage information storedby the DBMS, to better understand how scientists usethe system. This understanding could then lead to futureimprovements of the portal and its applications for grid-based visual data exploration. �

AcknowledgmentsThis work was supported by the National Science

Foundation, the Lawrence Berkeley and Lawrence Liv-ermore National Laboratories, and the Director, Officeof Science, of the US Department of Energy under con-tract DEAC0376SF00098. We used the argon bubbledata set courtesy of the Center for Computational Sci-ences and Engineering, Lawrence Berkeley NationalLaboratory. We thank the members of the University ofCalifornia, Davis, Visualization and Graphics ResearchGroup and the Lawrence Berkeley National LaboratoryVisualization Group for their input and assistance. Weespecially thank Tom Hsu and Praveenkumar Shetty fortheir work on the portal, Jason Novotny for creating theGrid Portal Development Kit and for considerable tech-nical support, and Xia Liu for her work on the DBMS fordistributed applications.

References1. M. Russel et al., “The Astrophysics Simulation Collabora-

tory: A Science Portal Enabling Community SoftwareDevelopment,” J. Cluster Computing, vol. 5, no. 3,Jan./Mar. 2002, pp. 297-304.

2. T.J. Jankun-Kelly and K-.L. Ma, “Visualization Explorationand Encapsulation via a Spreadsheet-like Interface,” IEEETran. Visualization and Computer Graphics, vol. 7, no. 3,July–Sept. 2001, pp. 275-287.

3. T. Abel, G.L. Bryan, and M. L. Norman, “The Formation ofthe First Star in the Universe,” Science, vol. 295, no. 5552,Jan. 2002, pp. 93-98.

4. M.L. Norman et al., “Diving Deep: Data Management andVisualization Strategies for Adaptive Mesh RefinementSimulations,” Computing in Science and Engineering, vol.1, no. 4, July/Aug. 1999, pp. 22-32.

T.J. Jankun-Kelly is a PhD can-didate in computer science at theUniversity of California, Davis,where he is a member of the Visual-ization and Computer GraphicsResearch Group of the Center forImage Processing and Integrated

Computing. His research interests include scientific andinformation visualization, Web programming, and theo-ry. He received a BS in physics and computer science fromHarvey Mudd College and an MS in computer science fromthe University of California, Davis. He is a member ofACM, ACM/Siggraph, the IEEE, and the IEEE ComputerSociety.

Oliver Kreylos is a PhD candidatein computer science at the Universi-ty of California, Davis. His researchinterests include multiresolutionmethods for scientific visualizationand interaction techniques for vir-tual-reality environments. He

received a Diploma in computer science from the Univer-sitat Karlsruhe.

Kwan-Liu Ma is an associate pro-fessor of computer science at the Uni-versity of California, Davis. Hisresearch interests include improvingthe overall experience and perfor-mance of data visualization throughmore effective interactive techniques,

user interface designs, expressive rendering, and high-performance computing. He received a PhD in computerscience from the University of Utah. He is a member of IEEE,the IEEE Computer Society, and ACM.

Bernd Hamann is codirector ofthe Center for Image Processing andIntegrated Computing and a profes-sor of computer science at the Uni-versity of California, Davis. He is anadjunct professor of computer sci-ence at Mississippi State University, a

faculty computer scientist at the Lawrence BerkeleyNational Laboratory, and a participating guest researcherat the Lawrence Livermore National Laboratory. Hisresearch interests include visualization, geometric model-ing and computer-aided geometric design, computergraphics, and virtual reality. He received a PhD in com-puter science from Arizona State University. He is a mem-ber of ACM, IEEE, the Society for Industrial and AppliedMathematics, and the IEEE Technical Committee on Visu-alization and Graphics.


Kenneth I. Joy is a professor ofcomputer science at the University ofCalifornia, Davis; a faculty researcherin the Center for Image Processing andIntegrated Computing; and a facultymember in the Institute for AdvancedScientific Computing Research at

Lawrence Livermore National Laboratory. His researchinterests include visualization, geometric modeling, andcomputer graphics. He received a PhD in computer sciencefrom the University of Colorado, Boulder. He is a member ofACM, the IEEE Computer Society, and the Society for Indus-trial and Applied Mathematics.

John Shalf is a researcher in theVisualization Group at LawrenceBerkeley National Laboratory. Hisresearch interests include projects thatcover visualization of AMR data, dis-tributed-remote visualization, grid-portal technology, high-performance

networking, and computer architecture. He is a member ofthe Technical Advisory Board for the European Union Grid-

Lab project, which seeks to create application-oriented APIsand frameworks for grid computing.

E. Wes Bethel is a staff scientist atLawrence Berkeley National Labora-tory, where he is a member of the Sci-entific Visualization group. Hisresearch interests include computergraphics and visualization softwarearchitecture, remote and distributed

visualization algorithms, latency-tolerant and parallel-graphics techniques. He received an MS in computer sci-ence from the University of Tulsa. He is a member of ACM,ACM/Siggraph, and the IEEE.

Readers may contact T.J. Jankun-Kelly at the Visual-ization and Graphics Research Group, Center for ImageProcessing and Integrated Computing, Dept. of ComputerScience, Univ. of California, Davis, CA 95616-8562, [email protected].

For further information on this or any other computingtopic, please visit our Digital Library at http://computer.org/publications/dlib.


50 March/April 2003

IEEE Pervasive Computing delivers the latest peer-revieweddevelopments in pervasive, mobile, and ubiquitous computing and acts as a catalyst for realizing the vision of pervasive (orubiquitous) computing, described by Mark Weiser nearly adecade ago. In 2003, look for articles on

• Security & Privacy

• The Human Experience

• Building Systems That Deal with

Uncertainty

• Interfacing with the Physical World

SUBSCRIBE NOW!

http://computer.org/pervasive

M. SatyanarayananCarnegie Mellon Univ. and Intel Research Pittsburgh

Associate EICs

IEEE Pervasive Computing

Editor in Chief

Roy Want, Intel Research; Tim Kindberg, HP Labs; Deborah Estrin, UCLA; Gregory Abowd, GeorgiaTech.;

Nigel Davies, Lancaster University and Arizona University

deploying web-based visual exploration tools on the grid

Documents