See what I mean? Using Graphics Toolkits to ... - Semantic Scholar

See what I mean? Using Graphics Toolkits to Visualise Numerical Data Jeremy Walton and Michael Dewar  September 17, 1996

Abstract

The use of graphics toolkits to visualise and understand numerical data is explored with reference to (a) a common data format for 3D geometry and (b) the improvement of visualisation algorithms through the incorporation of numerical library software. Using a common 3D format allows scenes and objects to be shared between applications and|if desired|published on the World-Wide Web (WWW) for viewing by co-workers elsewhere. Two examples of this are given. In one, we outline how the adoption of a standard toolkit to provide the visualisation component of a computer algebra package has cut down on development time and has provided it with the ability to share 3D data with other applications. In the other, we show how a graphics toolkit can be used within a visualisation web server, where its output can be transmitted across the WWW by means of the 3D format. The use of library software can save the application developer time and eort in implementing fundamental algorithms, and allows them to concentrate on other aspects of the visualisation process. We describe some preliminary work on visualisation benchmarking, and show how some library routines are superior to simpler, but less sophisticated, algorithms in the context of particle tracing.

1 Introduction The important role which visualisation plays in aiding the understanding of numerical data has been recognised for a long time [1]. Much progress The Numerical Algorithms Group Ltd, Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom 

1

has been made in academic research and industrial development towards the goal of producing modern data display software which is powerful, and yet easy to invoke, modify and extend. In recent years, traditional methods of application development, which rely on the construction of programs that generate images via calls to a graphics library, have been supplanted with the introduction of higher-level graphics toolkits. The use of such toolkits has a number of advantages, including more rapid application development, the incorporation of a common look-and-feel and the ability to share results between applications. This paper describes some recent work with some graphics toolkits in the eld of mathematical visualisation. More speci cally, we look at three topics: the use of a graphics toolkit to add a visualisation component to a computer algebra package, the way in which graphics toolkits have been incorporated into the design of a visualisation web server, which allows users to produce 3D displays of their data across the World Wide Web (WWW), and the incorporation of numerical library software into a visualisation toolkit in order to improve the accuracy of the algorithms used in some visualisation applications. Our paper is arranged as follows. The following section introduces the graphics toolkits under discussion. One is an object-oriented graphics library called Open Inventor, and the other is a data ow toolkit called IRIS Explorer. We describe their features brie y, and discuss their connection with the Virtual Reality Modelling Language (VRML) which has come to prominence recently as a lingua franca for 3D geometry interchange on the WWW. In x 3, we give an introduction to AXIOM TM , which is a symbolic computation package, and outline the way in which, by switching its visualisation component from internally developed software to the Open Inventor graphics toolkit, AXIOM has become more integrated with other applications such as IRIS ExplorerTM . The visualisation web server is described in x 4. This is built using IRIS Explorer as the visualisation component, and VRML as the medium which is used to transfer the results of the visualisation across the WWW. Finally, Section 5 contains an account of some algorithms used in the visualisation technique of particle tracing, and presents results for some comparisons between dierent visualisation systems. We show how the incorporation of routines from a numerical library can be used to avoid the problems associated with the application of algorithms that are inappropriate or inaccurate. We summarise some of the conclusions of this paper in a nal section (x 6). 2

2 Graphics Toolkits for Visualisation Data visualisation is the gaining of insight by making a picture out of numbers, be they from mathematics, engineering, geology, physics, chemistry, nance or architecture. In the past, visualisation applications have often been constructed using traditional programming methods incorporating calls to a graphics library such as|for example|the OpenGL [2]. However, the drive towards applications that are easier to construct, maintain and modify has led to the introduction of libraries such as Open Inventor [3], which provides a set of object-oriented abstractions above OpenGL, and, at a still higher level of abstraction, data ow toolkits such as IRIS Explorer [4], which give users the ability to construct and edit visualisation applications using an intuitive visual programming metaphor. The hierarchical relationship between these packages (IRIS Explorer uses Open Inventor to create pieces of geometry|lines, surfaces, voxels, etc| and Open Inventor uses OpenGL to render this geometry in a graphics window) can often be exploited by application developers. For example, new geometry manipulation routines can be built in IRIS Explorer using components from Open Inventor, and new rendering methods can be created in Open Inventor by making calls to OpenGL. In the following subsections, Open Inventor (x 2.1) and IRIS Explorer (x 2.2) are described in some detail.

2.1 Open Inventor|a 3D toolkit

Open Inventor is an object-oriented toolkit that allows users to create 3D graphics applications. It provides a comprehensive software model for developing interactions with the elements in the 3D scene, and also de nes an intuitive le format for 3D scenes. Open Inventor uses OpenGL for rendering scenes. An Open Inventor application creates and manipulates 3D scenes in a database known as a scene graph of objects called nodes. Various classes of nodes implement dierent geometry elements (primitive shapes, surfaces, text, etc), properties (colour, lighting, texturing, transformation, etc) as well as other behaviours. Other nodes help to organise the structure of the scene graph|for example, nodes may be grouped together under a separator node so that they do not aect other nodes outside the group. The ordering of the nodes in the scene graph and their relationship to one another de nes the 3D scene. Figure 1 shows the scene graph for a simple scene consisting of a red cylinder and a (translated) green cube. 3

red

cylinder translate

green

cube

Figure 1: An Inventor scene graph, representing a scene containing a red cylinder and a green cube. The nodes create the geometry elements (the cylinder and the cube) and set the properties (the colours, the translation). When an action such as rendering is applied by Inventor to the scene graph, the nodes are traversed from top to bottom and left to right. The other type of node in the graph is the separator node, which is used to isolate the eect of nodes in the graph; nodes beneath a separator do not aect anything above or to the right in a graph. Having created the scene graph, actions can then be applied to it; these include rendering, computing a bounding box or writing to a le. The le format used by Open Inventor is rather intuitive, and relates directly to the structure of the scene graph. For example, here are the contents of the le generated by applying a write action to the scene graph shown in Figure 1: #Inventor V2.1 ascii Separator { Separator { Material { diffuseColor 1 0 0 } Cylinder {} }

4

Separator { Transform { translation 0 5 0 } Material { diffuseColor 0 1 0 } Cube { width 3 } } }

The simplicity of this format, coupled with the fact that, once the scene has been created within an Open Inventor application, it may be easily written to a le, has led to its adoption as a de facto standard for 3D geometry les. This is of some signi cance, since the eld of 3D geometry creation and storage is still in its infancy, and so it has often been the case that a model or scene which was available in one 3D le format could only be converted to another with some programming work. Contrast this, for example, with the translation of 2D raster (or bitmapped) image les written in formats such as TIFF, which is fairly straightforward. One of the reasons for this is that the eld of image storage and display is more mature and there has grown up a large quantity of public domain and commercial software to read, display and convert les written in most formats. Another is that such formats are usually fairly simple, since their fundamental building block|a pixel|is comparatively untransmutable. By contrast, 3D geometry le formats are much more complex (as are, incidentally, 2D vector graphics formats such as CGM and HPGL) and harder to translate. Examples of this type of format|many of which have grown up around a commercial CAD or modelling package|include Autodesk's DXF, the OBJ format of Wavefront (now Alias/Wavefront), and the IGES format. The emergence of a de facto 3D standard is important, and a number of translators between Open Inventor and other formats (among which are those mentioned above) have already appeared and it is straightforward to exploit this when passing 3D data between one Open Inventor-based application (such as IRIS Explorer) and another. In some cases, this can be performed using a familiar cut and paste mechanism, exactly analogous to the transfer of more conventional data types such as text. Recently, the ubiquitousness of the Open Inventor le format was further enhanced when it was adopted as the basis of VRML [5], the language used 5

to de ne the interchange of 3D geometry on the WWW. This is the analogue, in a 3D world, of HTML, which is used to de ne text-based documents on the Web. The use of an already extant language has the advantage that existing Open Inventor content and applications can be easily converted to VRML, and so shared with other workers on the Web|we return to this point in the following sections. Since the de nition of version 1.0 of the language, a number of VRML applications have already appeared. An example of a VRML browser is WebSpace [6], which has been developed by Silicon Graphics, and ported to a variety of other platforms [7] by Template Graphics Software. It is freely available on the Web. Other browsers are also available, including Microsoft's VRML Add-In [8], for their Internet Explorer. The widespread acceptance of VRML makes it a natural choice for storing and sharing 3D geometry as output from a visualisation package. In the case of an Open Inventor application (such as IRIS Explorer|see below), converting its output to VRML is most easily done using the Inventor translator ivToVRML, which is part of the WebSpace distribution.

2.2 IRIS Explorer|a data ow toolkit

IRIS Explorer is a visualisation data ow toolkit, which|uniquely among products of this type|uses Open Inventor for creating 3D geometry. Other well known examples of data ow toolkits include AVS [9], Data Explorer [10] and Khoros [11]. All of these have broadly the same interface; when working with one, users interactively create their application in the form of a network of modules. Here, each module is a software routine that operates on its input data to produce some output. Modules may be procedures to, for example

 read the data into the network (from a le, or another application

which is running simultaneously),  modify or lter the data (for example, clamping of values, normalisation, edge detection of an image, etc),  transform the data into geometric objects which can be displayed (such as slices, isosurfaces, contours, vectors, etc), or  output the nal image to a display device or le. 6

A particular feature of the toolkit is that it is extensible; users have the facility to to create their own, supplementary, modules which can be added to the default set. The network|built by connecting module inputs and outputs|de nes the way in which data ows through the application. Editing of the network is performed via a point-and-click programming interface, where modules are selected from a palette, dragged onto a work area and connected together. The behaviour of each module is usually controlled by some set of parameters (for example, the name of an input le, the value for which an isosurface is to be calculated, the form of a colourmap) and the user can interact with these while the application is running via a standard set of widgets. Some of these elements are illustrated in Figure 2, which shows a screen shot taken from an IRIS Explorer session.

Figure 2: A screen shot from IRIS Explorer. The palette of modules is on the top left, while the work area is in the middle at the top. A network of modules|called a map in IRIS Explorer|is in the work area. The widgets which control the modules actually appear on the representation of the modules themselves when they are in the work area; a larger (see for example the control panel of the slicer module at bottom left) and smaller representation is available. The image appears in the display window, created by Render, the nal module in the map. This map is displaying results from a CFD calculation of circulating ow as velocity vectors in a slice taken through the box. 7

The ease with which an application can be quickly built, executed and modi ed on the y via the visual programming interface has led to the wide acceptance [12] of this type of toolkit for the rapid prototyping and development of visualisation (and other) applications. Attention has recently been focused [13] on the reliability and accuracy of visualisations produced using this type of toolkit, which raises questions about the algorithms used by each tool in the kit (i.e., each module). Below, in x 5, we shall describe some preliminary work [14] aimed at benchmarking some of the algorithms for particle tracing, which is a popular method for visualising vector elds. The success of this work depends on being able to compare the results produced by dierent visualisation systems. Here, the fact that IRIS Explorer is based on Open Inventor means that it is easy to save its results in this le format, and|as mentioned above|translators to this format already exist for a number of other systems. In a similar way, it is straightforward to read Inventor les into IRIS Explorer, thus establishing an interface with other Open Inventor-based applications. A description of one of them|a computer algebra package|is the subject of the following section.

3 A Computer Algebra Package AXIOM [15] is a computer algebra system developed at IBM's T J Watson Research Center in New York and now marketed by NAG Ltd of Oxford. Computer algebra is primarily concerned with manipulating symbolic representations of mathematical objects using sophisticated algorithms to determine exact results. In common with most such systems, AXIOM is usually used interactively and incorporates its own visualisation capabilities. AXIOM's unique feature is that it is based around a compiled language which embodies a type system designed to model the natural relationships which exist between mathematical objects. This both ensures the mathematical correctness of the system, and allows new mathematics to be added in a consistent and relatively easy way. The system is fully extensible, and users may add their own mathematics if they wish. The type system has two levels: concrete representations of objects are called domains, and domains are grouped into categories which describe their algebraic properties. So for example the domain Integer, which represents arbitrary precision integers, belongs to a number of categories including Ring and OrderedSet. Since it is a ring we know that we can add and multiply integers according to cer8

tain axioms, and since it is an ordered set we know that there is a complete ordering de ned on it (i.e., given any two integers we can always tell if one is bigger than the other, or if they are equal). This is important because domains can take parameters; for example the domain Polynomial(R:Ring) is parameterised by any Ring R. The parameter R is what algebraists call the coecient ring of the polynomials, in other words the set of objects from which the coecients of the polynomial are drawn. It is essential that R is a ring since one needs to be able to add and multiply the coecients of two polynomials to add and multiply the polynomials themselves. What this means in practice in AXIOM is that users can instantiate the domain Polynomial(Integer) but not the type Polynomial(String), because the latter does not make sense. The process of instantiation simply makes that domain and its operations available to the user. Since the parameter to Polynomial can be any Ring, users can add their own rings to the system and build polynomials over them, without touching the existing polynomial code. Other attributes of R can be taken into account too, so for example the fact that Integer is an ordered set allows Polynomial(Integer) to de ne an ordering on itself. Although this may sound complicated, in practice most of these details are hidden from the casual user. The AXIOM interpreter analyses what a user types in, and tries to decide which domains to instantiate. Since the language that interactive computer algebra systems use is very close to real mathematics, they are often used as symbolic calculators for solving simple problems. As users' expectations have grown, the designers of these systems have added simple numerical, statistical and graphical facilities to their core symbolic functionality. AXIOM is no exception, having its own hypertext documentation system, its own numerical facilities and its own graphics package. We shall look at the graphics package in a little more detail. Figure 3 shows a screenshot from an earlier version of AXIOM, which illustrates some of the features of the interface to both the symbolic and display components of the package. The interface allows the user to display surfaces as 3D objects and then manipulate them in a variety of ways| rotating, scaling and translating|and to change some of the parameters of the display: wireframe, at or smooth shaded, for example. However, it should be pointed out that, in this version, all of the graphics were handcoded using the X Windows library. Whilst this interface provided most of the necessary functionality for interaction, this method of development made it somewhat dicult to extend. What is more, the surfaces only exist 9

Figure 3: A screen shot from AXIOM 2.0. The hypertext interface is shown in the window at bottom right, which contains the script for the calculation of a surface in 3D space: in this case, a Bancho Klein bottle. The surface is displayed in the large 3D graphics window at top left, while the window on the right contains the controls for the 3D viewpoint and for some of the properties of the surface displayed. as polygons to be displayed on a 2D screen, and not as true 3D objects that can be manipulated and shared with other packages. Finally, it can be seen that development of the graphics component of AXIOM is orthogonal to the main development path for the package, simply because the eld of expertise for the AXIOM developers is computer algebra. Maintenance of (or adding new features to) the visualisation side of the package will always have a lower priority, and can be viewed as a distraction from the development of new algebraic functionality. Recently the group at NAG developing AXIOM have been re-engineering it with a number of goals in mind:  to make the system more portable, particularly to non-Unix platforms;  to make the system comply with recognised standards where appropriate;  to integrate the system more fully with NAG's product range by using components from other NAG products where feasible. 10

This process began with the second release of AXIOM, which used the NAG Fortran Library to provide a great deal of numerical functionality. A new release of AXIOM in early 1996 for Windows platforms will include new documentation facilities based around LaTEX and HTML, and a new graphics package, based around Open Inventor. The choice of Open Inventor was made for a number of reasons:  it has all the necessary functionality, is fast and ecient, but is easy to use;  its object-oriented structure is highly compatible with AXIOM's view of the mathematical world;  it allows interoperability with other parts of NAG's product range, in particular IRIS Explorer;  it is portable to most modern machines;  the Inventor/VRML le format is set to become the standard internet representation for 3D objects, complementing AXIOM's adoption of HTML. When AXIOM users want to draw a surface they simply call one of several draw commands. A simple example would be: draw(x*sin(y),x=-%pi..%pi,y=-%pi..%pi)

to draw the surface z = x sin(y ) on the region x; y 2 [?;  ]. It is also possible to draw parametric surfaces, space curves and tube plots, to change the coordinate system being used, to specify how the image is to be coloured, etc. We were able to keep this high-level interface, and just integrate Open Inventor at a lower level. In AXIOM a three-dimensional object is represented by the domain ThreeSpace(R:Ring), which can contain points (tuples of R) connected in various ways, curves and polygons. A ThreeSpace can be turned into a ThreeDimensionalViewport which as a side-eect may render an image in a separate window. Users have the choice of interacting with the image via the rendering application, or by applying functions (such as rotate, translate, zoom etc.) to the ThreeDimensionalViewport from the AXIOM command line. To incorporate Open Inventor we rst introduced a number of new domains to represent dierent kinds of Inventor nodes (such as OpenInventorQuadMesh and OpenInventorLightingModel) and a domain 11

to represent a scene graph. We then replaced the process of interrogating a

ThreeSpace to create a ThreeDimensionalViewport with one which transformed the ThreeSpace into a collection of Inventor node domains which we

can turn into a scene graph and render using any other Inventor application such as IRIS Explorer. This process is completely automatic and is transparent to the user. Finally, we developed our own rendering application using the Open Inventor toolkit, which communicates with AXIOM using shared memory and (under Windows) OLE technology.

Figure 4: Displaying the surface of Figure 3 in IRIS Explorer. The surface is displayed by the Render module, which owns the large window at bottom right. The Inventor components|via which the user can edit aspects of the scene in Render|are shown to the left of the Render window. The window on the left is from the ViewGeom module. As an example of the integration with other applications, consider Figure 4, which shows the surface of Figure 3 displayed in IRIS Explorer. The surface is passed between AXIOM and IRIS Explorer as an Inventor scene graph, and displayed by the Render module. This module is also displaying a 3D icon from the Pointer module; this can be used to select points on the surface, to attach labels, to measure distances within the scene and so on. The other icon in the Render window indicates a directional light source whose properties|orientation, colour and intensity|can be directly edited via a set of Inventor components. Some of the components are shown in the 12

gure; these can also be used to edit other aspects of the 3D scene such as the properties|colour, transparency, shininess, etc|of the surface material. Finally, the scene graph has also been passed to the ViewGeom module, which displays a 3D representation of the scene graph itself (compare the image in the ViewGeom window with Figure 1) which can be further analysed to study its structure.

Figure 5: Two geometric objects produced in AXIOM and displayed in IRIS Explorer. Figure 5 shows two geometric objects which have been created in AXIOM and transferred to IRIS Explorer for display. Once the geometry has been passed to the Render module, the scene may be composed using the Inventor components to make appropriate choices for materials, lights, translations, etc. Other geometry may also be incorporated into the scene: for example, in the Figure, a suitably illuminating title has been added. Clearly, this functionality is central to IRIS Explorer as a visualisation toolkit, although it is beyond the scope of AXIOM as a symbolic manipulation package. By giving AXIOM the ability to export geometry in a standard format, we have enhanced the range of output options that are available to users of the package. We have created AXIOM domains to represent most Inventor nodes so that it is possible to create virtually any kind of scene graph. While this is not a facility the normal user will want, developers of sophisticated applica13

tions may nd it extremely useful. The modular structure of both AXIOM and Inventor made adding this extra functionality very cheap. The result of this exercise is that we now have a much more ecient, powerful and capable rendering system within AXIOM. The relative ease with which we were able to incorporate these features is a testament both to AXIOM's modular, object-centered design, and to the design of the Open Inventor toolkit itself.

4 A Visualisation Web Server Jason Wood and his colleagues at the University of Leeds have been working on a WWW server for performing visualisation [16, 17]. Here, the user accesses a page on the WWW and lls in an HTML form de ning the location of the dataset of interest and the visualisation techniques that are to be applied to the data. Also speci ed at this point are any parameters which need to be selected for the technique (for example, the value at which an isosurface is to be calculated). A script is created containing this information, and this is passed to the visualisation server, where it is used to assemble (or select) the map that is to be run by IRIS Explorer. The map is executed and the resulting geometry is passed back to the server as an Inventor le, which is converted to VRML before being transferred via the Web back to the user's client, where it is delivered to a browser. Figure 6 [16] illustrates the process. Interesting applications of a visualisation web server could include the display of real-time data such as stock market results or weather data. The server has been demonstrated at Leeds as an education application, to illustrate the way in which various visualisation techniques can be used. The advantage of this is that the student is free to concentrate on the results of applying the technique, rather than on the details of how it has been invoked in the visualisation application.

5 Benchmarking Visualisation Systems The current proliferation of visualisation software (some of which has been discussed above in x 2), with its promise of the painless transformation of complicated datasets into images or geometries, can leave unanswered questions of reliability and accuracy in the output that is produced. Misleading results can arise when the algorithm used within the visualisation tool is 14

1. Script containing location of dataset and details of visualisation technique

Visualisation web server

5. VRML

Data space

2. Get data files

4. Inventor

3. IRIS Explorer map

Figure 6: Schematic diagram of a visualisation web server. The user's client machine is on the left of the vertical line, while the server is on the right. The WWW page containing the form to be lled in by the user is illustrated at top left, while the browser (in this case WebSpace) which receives the VRML from the server is at lower left. The IRIS Explorer map invoked by the web server is shown at bottom right on the server machine. The steps in the process are numbered on the diagram. inappropriate, or inaccurate, or unusable. Questions about the reliability of a visualisation become even more relevant as the evolution of processor power makes the steering of computational processes via the real-time visualisation of their results more widespread; decisions about the future course of the calculation will be taken based on the display, so it is important to ensure that its information content is as high as possible. Looking at (if not answering) the questions of reliability and accuracy in visualisation focuses attention on a number of factors including [14]:  details of the techniques that are applied to the data to produce the visualisation,  the ability to make comparisons between dierent visualisation applications or systems, 15

 the establishment of some set of metrics or benchmarks for visualisa-

tion. In this section, we present the results of a limited comparison between two visualisation systems in one specialised area: that of particle tracing for vector elds. A central notion in this work is the ability to reliably compare the results from two dierent systems, and it is here that the emergence of VRML as a standard for 3D geometry interchange (see x 2.1, above) comes to our aid. Using VRML for our results also gives us the ability to share them with other workers in this eld; we return to this point below. First, however, we interpose a brief introduction to the algorithms used in particle tracing, before describing the modules under comparison.

5.1 Particle tracing algorithms

The input to a particle tracing module is a (possibly time-dependent) vector eld, which gives some vector quantity (velocity, say) as a function of position. Then, the path of a particle released into this eld is given by the solution of the velocity equation ()

dx t =dt

= v(x; t) ;

where x(t) is the particle's position at time t, and v(x; t) is its velocity at that position and time. Once the particle's initial location (at time t0 ) is given, this equation can be integrated for position at a sequence of times t , where the dierence between successive times is known as the time step,
t. Two types of algorithm for the integration of this equation can be distinguished: xed step and adaptive step methods. In discussing them, it is useful to focus attention on the error associated with a given step in the integration, which can be de ned as the absolute dierence between the calculated (x) and true (x) positions after that step: i



= jx(t ) ? x(t )j : i

i

Fixed step methods have an error whose size is of the order of the time step raised to some power, i.e.
t = t +1 ? t ;  = O(
t ): i

i

q

Thus, for example, in the so-called Euler method [18], which is the simplest xed step method, the error is of the same magnitude as the square of the 16

time step (q = 2). Higher-order xed step methods, such as an nth-order Runge{Kutta method [18] have an associated error whose magnitude is the time step raised to the power of n + 1. Hence, using a higher-order method allows the solver to take larger steps for the same accuracy (at the expense of the additional calculations involved in the method). In an adaptive step method, as the name implies, the algorithm controls the size of the step
t as the integration proceeds in time. Usually, this is in order to achieve some predetermined accuracy|i.e., some speci c value (called the tolerance) for the error|with minimal computational eort. Note that the tolerance could, in turn, depend on other parameters such as the position and time. This leads to a more ecient solution: bigger steps can be taken through regions where v is changing slowly, while smaller steps are required when there are large variations in v. It can be seen that this is more eective than a xed step method, which uses the same
t regardless of its environment. Thus, if the step is set to a suitable (large) size for the places where v is slowly changing, then details will be missed when v changes suddenly, but if it is decreased to give accurate results in the rapidly varying regions, computational time will be wasted when the particle moves into a region where v is more or less constant. The important thing in an adaptive step method, of course, is the method used to estimate , the error at each step. A simple technique is so-called step-doubling [18], where each step is taken twice: once as a full step, and once as two half steps. The step size is reduced if the absolute distance between the end points of the two steps is less than the tolerance, and increased otherwise. In spite of the extra computation involved, this method can lead to more ecient solutions than a xed step method. However, some workers have found it to be less ecient, and have implemented other types of adaptive methods, such as those based on the curvature of the particle path [19]. An adaptive method with an ecient, reliable estimator for the error has been developed by Brankin et al [20]. This production-grade ordinary dierential equation solver has been incorporated into the NAG numerical libraries (for example, in the C library, it appears as nag ode ivp rk [21]), and has been used in some of the modules in Release 3.0 of IRIS Explorer. In the following subsection, we describe these modules, and some other particle tracers prior to benchmarking them. i

17

5.2 Particle tracing modules

We have in mind a simple visualisation benchmarking experiment, where the same dataset is given to a number of dierent modules within (possibly dierent) visualisation systems, and their outputs compared. In the case of modules which perform particle tracing, where the output takes the form of a line in 3D space, a qualitative comparison is easy to do, and devising a suitable measure for the separation between two traces is reasonably straightforward. Clearly however, this could become more complicated for other visualisation techniques (such as isosurfaces) which produce more complicated geometry that would be harder to compare. A number of modules which perform particle tracing are currently available. These include:

  

(AVS 5.02) ParticleAdvect (IRIS Explorer 2.2) NAGAdvectSimple (IRIS Explorer 3.0) particle advector

These all take as input a v(x; t) whose value is given at a discrete set of points in 3D space, together with an initial location (or set of initial locations) for the particles. None of them accept a time-dependent vector eld, so the analysis is performed under the assumption of a steady state. Note that the discrete nature of the dataset necessitates some form of interpolation of the vector eld between the points. The details of the interpolation algorithm used in the dierent modules will aect the output. We do not concern ourselves further with this, but concentrate instead on the algorithms used to integrate the velocity. According to the documentation of each module, particle advector uses the Euler or Runge{Kutta (whose order is not speci ed) methods, while ParticleAdvect uses Euler or Runge{Kutta (2nd or 4th order), and NAGAdvectSimple uses the nag ode ivp rk routine from the NAG C numerical library. (Another module in IRIS Explorer 3.0, NAGAdvectAnimate, produces identical results to NAGAdvectSimple, but oers dierent output options.)

5.3 A circular eld

To illustrate the notion of benchmarking, we select two modules, pass the same vector eld and initial particle location to each, and compare their 18

results. The rst dataset is a simple circularly symmetric eld in the xy plane: v = ? sin  ; v = cos  ; v = 0 ;  = arctan(y=x) : Since this eld is analytic, we can use the exact result for the particle path| i.e., a circle|to assess the accuracy of the results from each module. Figure 7 shows the paths calculated for this eld from ParticleAdvect using the Euler method and NAGAdvectSimple. The rather dramatic dierence between the results from the two modules can be seen, with NAGAdvectSimple producing a path that is (close to) circular, and ParticleAdvect calculating a spiral path. x

y

z

Figure 7:

Paths calculated for a circularly symmetric eld with ParticleAdvect using the Euler method (dotted line) with a timestep of 0.1 units and NAGAdvectSimple (solid line). The arrows are drawn at each data point, and show the orientation of the vector eld at that point. Besides illustrating the well known fact that the errors involved at each step of the Euler method cause it to break down for circularly symmetric elds, this gure also highlights the importance of testing the accuracy of the algorithm used on the data. In this example, it would be easy to imagine a user obtaining just the spiral path from ParticleAdvect (or from AVS's particle advector, which oers the same algorithm) and, in the absence of any other information, drawing the wrong conclusions about the structure of 19

the vector eld. Moreover, the fundamental nature of the xed-step methods presents another problem to the user: choosing the size of the time step, which needs to be speci ed at the start of the calculation. Since the error associated with each step goes as some power of the time step, one would expect the spiral above to become tighter as the step is reduced. This is what is in fact observed, which should raise some questions in the mind of the user about the reliability of the results. Indeed, in the search for the \correct" answer, the user may try reducing
t by hand until no change in the path is (visually) apparent|a crude form of adaptive step sizing, albeit one where the same step size is used throughout the system. The user interface to NAGAdvectSimple is dierent, with no user input being required for the size of the time step, which is set internally. To be more speci c, the required value of the tolerance is rst determined using a recipe based on the average magnitude of the vector over the eld and the global minimum of the components of the vector throughout the eld. Next, a trial step size is estimated for the rst step that should produce an error that is within the tolerance. Then integration proceeds and the size of the rst and subsequent steps are adjusted internally to maintain this relationship.

5.4 Double glazing data

Having made the comparison for a simple test case, we can now move onto some more realistic data. The second dataset comes from a calculation of air ow in the space between two parallel sheets of glass: a simulation of the gap in double glazing. The results are calculated from the solution of the Navier{Stokes equation using a multigrid code; the section of the data that we use below exists on a regular grid of dimensions 18  18  10. In this section, we compare particle advector and NAGAdvectSimple. Since we have already shown the Euler method to be unreliable in certain types of eld, we select instead the Runge{Kutta algorithm from particle advector. Figure 8 shows the traces from particle advector using the Runge{ Kutta algorithm with a timestep of 10 units and from NAGAdvectSimple for an initial particle location in the centre of the simulation cell. Both traces show the same qualitative behaviour, but there appear to be quantitative dierences between them. In particular, note the dierent paths taken at the corners of the box, where the path curves. The adaptive method gives a path which bends more smoothly, while the xed step method misses some 20

Figure 8: Paths calculated for the double glazing data with particle advector using the Runge{Kutta method (solid line) with a timestep of 10 units and NAGAdvectSimple (dotted line). The particles' initial location is in the centre of the cell. of the detail in that region. Similar results are obtained for other starting positions [14]. Since the size of the time step is a parameter of the xed step Runge{ Kutta method, it may be illuminating to enquire how this aects the trace. We have calculated a number of traces with the Runge{Kutta method of particle advector using dierent step sizes. Figure 9 plots the separation between the xed step and adaptive step traces (calculated using NAGAdvectSimple) as a function of distance along the trace. The distances are reduced using the cube root of the box volume. From the gure, we can see a tendency for the xed step trace to diverge from the adaptive step trace and that, at least for time steps greater than unity, this deviation increases with the size of the time step. This lends weight to the notion that the adaptive step method is producing a more accurate representation of the particle trace and that, as the time step is reduced, the xed step method approaches this trace. However, more comparisons using other initial locations and other data sets would be required before drawing any further conclusions from this limited experiment [14]. 21

∆t = 10.0

∆t = 5.0

∆t = 1.0 ∆t = 0.1

Figure 9: Plots of the separation between the xed-step Runge{Kutta trace (from particle advector) and the adaptive step trace (from NAGAdvectSimple) as a function of distance along the trace, calculated for dierent time step sizes, using an initial particle location near the edge of the box.

6 Conclusions In this paper, we have examined a number of examples of the use of graphics toolkits in the visualisation of numerical data. Using Open Inventor in the creation of visualisation applications allows for shorter development times, because of the way in which the management of the 3D scene and frequently used interaction and editing tasks are encapsulated in the toolkit. For example, the use of Inventor components as material editors for rendered objects, and the common interaction model provided by Inventor. We have seen an illustration of this in the account given of the development of the latest version of AXIOM. 22

The important bene t of the use of Inventor which we have concentrated on in this paper, however, is its 3D le format. The use of this|and its widely-adopted cousin, VRML|allows applications to share 3D data with one another, and (in the case of VRML) to share such data with other users on the Web. We have described the way in which 3D scenes can be generated within AXIOM and viewed within other Inventor applications such as IRIS Explorer. Other examples of the use of VRML as a 3D publishing language have included the visualisation web server, where scenes created using IRIS Explorer are transferred across the Web by means of VRML, and the work on visualisation benchmarking. The major thrust of this activity, of course, is to investigate the way in which the modules that form a central part of data ow graphics toolkits can produce dierent results for the same input data, even when they are supposed to be performing the same function. In the case of our particle tracing example, we have shown how the use of an adaptive step method is to be preferred for reasons of eciency and overall error control, and because the results are aected by the value of the step that must be selected in a xed step method. More broadly, we have highlighted the importance of a good understanding (or at least awareness) of the details of the algorithm inside the module in nding out (a) how it works and (b) how reliable it is. It should perhaps be noted that the use of a good numerical library (such as the one from NAG) in the construction of a module can save the user time and eort in implementing fundamental algorithms. As well as providing a high degree of con dence in the knowledge that the implementation has been used in a wide range of other applications, it also provides the module with a ready-made reference for documentation purposes. This is signi cant, since it good documentation of a module is the key to its ease of use, reliability and understanding of the algorithm [14]. Finally, we return to the use and bene ts of VRML within the benchmarking study. As can be seen from Figure 8, the geometry output from these systems can be complex and dicult to understand, especially via a 2D image or gure. Presenting the results from this work on the Web via VRML has the advantage of allowing other workers to examine the results from any viewpoint, to zoom in on details of interest and to extract pieces for further investigation. It has other advantages as well since, if the user also has access to the dataset which gave rise to the geometry, they have the opportunity to extend this work by performing similar analyses for other modules, or other toolkits. VRML can therefore be seen as enabling tech23

nology in promulgating the results of this study. The ability to share in, and add to, the work of others in this area will be an essential part of the work on visualisation benchmarking, which will ultimately lead to more reliable tools for developers and end users.

7 Acknowledgements Thanks to Jason Wood, Ken Brodlie and Helen Wright for useful discussions regarding their work, to Steve Larkin for his generous assistance with AVS and to Richard Brankin for help with the ODE solver. The NAGAdvect modules were written by Astrid van Maanen, based on a modi cation by Hiro Chiba of ParticleAdvect, which was originally developed at the NCSA, University of Illinois at Urbana-Champaign. Double glazing data provided courtesy of Tim David. All trademarks and registered trademarks in this paper are the rights of their respective owners.

References [1] R.A. Earnshaw and D. Watson, eds., Animation and Scienti c Visualization|Tools and Applications, Academic Press (1993). [2] J. Nieder, T. Davis and M. Woo, OpenGL Programming Guide. The Ocial Guide to Learning OpenGL, Release 1, Addison Wesley (1993). [3] J. Wernecke, The Inventor Mentor. Programming Object-Oriented Graphics with Open Inventor, Release 2, Addison Wesley (1994). [4] The Numerical Algorithms Group, IRIS Explorer User's Guide, (1995). [5] http://www.wired.com/vrml. [6] http://www.sgi.com/WebFORCE/WebSpace [7] http://www.sd.tgs.com/ template/WebSpace [8] http://www.microsoft.com/windows/ie/vrml.htm

24

[9] C. Upson, T. Faulhaber Jr., D. Kamins, D. Laidlaw, D. Schlegel, J. Vroom, R. Gurwitz and A. van Dam, The Application Visualisation System: A Computational Environment for Scienti c Visualisation, IEEE Computer Graphics and Applications, 9, (1989), 30. [10] B. Lucas, G.D. Abram, N.S. Collins, D.A. Epstein, D.L. Gresh and K.P. McAuliffe, An Architecture for a Scienti c Visualisation System, Proceedings of Visualisation '92, IEEE Computer Society Press (1992), 107. [11] J. Rasure, and M. Young, An Open Environment for Image Processing Software Development, Proceedings of 1992 SPIEIS&T Symposium on Electronic Imaging, (1992), 1659. [12] J.Walton, Now You See It|Interactive Visualisation of Large Datasets, Applications of Supercomputers in Engineering III, Computational Mechanics Publications/Elsevier Applied Science (1993), 139. [13] H. Rushmeier, M. Botts, S. Uselton, J. Walton, H. Watkins and D. Watson, Metrics and Benchmarks for Visualization, Proceedings of Visualisation '95, IEEE Computer Society Press (1995), 422. [14] J. Walton, Visualisation Benchmarking: A Practical Application of 3D Publishing, Proceedings of 14th Annual Eurographics UK Conference (1996), in press. [15] R.D. Jenks and R.S. Sutor, AXIOM: The Scienti c Computation System, Springer-Verlag and NAG Ltd (1992). [16] J. Wood, IRIS Explorer, VRML and the WWW, poster presentation at the IRIS Explorer User Group meeting, SIGGRAPH 95, (1995). [17] J. Wood, K.W. Brodlie and H. Wright, Visualisation and the World Wide Web, personal communucation (1995). [18] W.H. Press, B.P. Flannery, S.A. Teukolsky and W.T. Vettering, Numerical Recipes, Cambridge University Press (1986), 547. [19] D.N. Kenwright and D.A. Lane, Optimisation of Time-dependent Particle Tracing using Tetrahedral Decomposition, Proceedings of Visualisation '95, IEEE Computer Society Press (1995), 321. 25

[20] R.W. Brankin, I. Gladwell and L.F. Shampine, RKSUITE: a suite of Runge{Kutta codes for the initial value problem for ODEs. SoftReport 91-S1, Department of Mathematics, Southern Methodist University, Dallas, TX 75275, U.S.A. (1991). [21] The Numerical Algorithms Group, C Library Mark 3 Manual, (1995).

26