Integration of Graphical User Interface and Data ...1.1.2 WCDMA Simulation Model A ray tracing propagation model predicts the impulse response of a wireless channel. However, propagation

Integration of Graphical User Interface and Data

Visualization Tools in a Problem Solving

Environment for Wireless System Design

by

Dhananjay Mishra

Thesis submitted to the faculty of the

Virginia Polytechnic Institute and State University

in partial fulfillment of the requirements for the degree of

MASTER OF SCIENCE

in

Computer Science

c©Dhananjay Mishra and VPI & SU 2004

APPROVED:

Dr. Clifford A. Shaffer, Chairman

Dr. Naren Ramakrishnan Dr. Layne T. Watson

April, 2004

Blacksburg, Virginia

Integration of Graphical User Interface and Data

Visualization Tools in a Problem Solving Environment for

Wireless System Design

by

Dhananjay Mishra

Committee Chairman: Dr. Clifford A. Shaffer

Computer Science

(ABSTRACT)

This thesis describes user interface and visualization components in the problem solving

environment “Site-Specific System Simulator for Wireless System Design” (S4W) developed

by CS and ECE faculty and students at Virginia Tech. S4W integrates visualization and

computational tools with a high level user interface. The objective of this PSE is to improve

the ability of wireless design engineers to design an indoor wireless system through the aid of

various simulation and visualization components. S4W provides engineers with the facility

of thinking in terms of the overall task of designing the system for optimal performance.

They need not to worry about computation, data-management and connectivity issues.

The choice of method for interaction between service logic within a PSE and its user

is always a challenging issue. The selection of user interaction channel is mostly dictated

by the characteristics of the problem domain. For S4W, we chose to build a graphical

user interface as human interaction interface, which was connected to other components

via a high speed Local Area Network (LAN). The other key form of user interaction in

a PSE is the visual representations of the abstract data results of simulations, perceived

as user interface for data. The Complex nature of data sets in the domain of wireless

simulations calls for a customized set of visualization tools. To address the specific needs

of visualizations for S4W, ad hoc visualization tools were developed and integrated into the

graphical user interface. A comparison of the integrated PSE and an earlier collection of

unintegrated tools and scripts is presented.

ACKNOWLEDGEMENTS

This work would not have been possible without the support of many people. First

and foremost is my advisor and committee chair, Dr. Clifford Shaffer, who gave me the

opportunity to pursue graduate study. Dr. Shaffer has stood by me throughout my long

process of obtaining my Master’s degree, providing support when my morale was failing,

and guided me throughout with honest and frank appraisals. He has been a wonderful

advisor. I thank him for his support and direction throughout my Master’s program.

I must also thank Dr. Naren Ramakrishnan and Dr. Layne Watson (co-advisors) for

their expert guidance and moral support during my project, and for providing me with

resources and financial support. I have enjoyed working with my committee members.

I would like to acknowledge the enormous contributions of Alex Verstak, Jian He and

Kyung Bae for their valuable time spent on making me understand the already-developed

parts of the PSE and their regular feedback in our weekly meetings.

Most importantly, I would like to thank my parents whose faith in my ability to achieve

great heights never failed, so I continue to believe in myself until this day.

iii

TABLE OF CONTENTS

1 INTRODUCTION AND OVERVIEW 1

1.1 Overview of S4W Simulation Models . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Ray Tracing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2 WCDMA Simulation Model . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.3 Numerical Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 RELATED WORK 8

2.1 Graphical User Interface in a PSE . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Visualizations in a PSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Tcl/Tk for Scientific Visualizations . . . . . . . . . . . . . . . . . . . . . . . 12

3 THE S4W GRAPHICAL USER INTERFACE 13

3.1 User Interface for WCDMA Simulator . . . . . . . . . . . . . . . . . . . . . 14

3.2 User Interface for Ray Tracer . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 Environment Preprocessing . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.2 Ray Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 User Interface for Optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.1 Preview of the Environment . . . . . . . . . . . . . . . . . . . . . . 24

3.3.2 Starting a New experiment . . . . . . . . . . . . . . . . . . . . . . . 24

4 VISUALIZATIONS FOR S4W 29

iv

4.1 Visualizations for the WCDMA Simulator . . . . . . . . . . . . . . . . . . . 29

4.2 Visualizations for the Ray Tracer . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 Visualizations for the Optimizer . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.1 Visualization of Final Power Coverage . . . . . . . . . . . . . . . . . 41

4.3.2 Visualization of Objective Function Values . . . . . . . . . . . . . . 41

5 COMPARISONS AND CONCLUSIONS 45

5.1 Comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1 Value Addition with GUI . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1.2 Better Insight into Results with Visualization Tools . . . . . . . . . 48

5.2 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 LESSONS LEARNT FROM THE EXPERIENCE OF S4W 50

6.1 Experimentation with a relational database system . . . . . . . . . . . . . . 50

6.2 Experimentation with scripting in creating graphical user interface, visual-

ization tools and integration of the system . . . . . . . . . . . . . . . . . . . 51

6.3 Surrogate functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.4 Scenario and experiment management . . . . . . . . . . . . . . . . . . . . . 52

6.5 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

v

LIST OF FIGURES

1.1 Outline of S4W PSE design. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 First View of Graphical User Interface . . . . . . . . . . . . . . . . . . . . . 14

3.2 Experiment listing and details on demand screen for WCDMA . . . . . . . 15

3.3 New Experiment form for WCDMA . . . . . . . . . . . . . . . . . . . . . . 17

3.4 DXF to XML converter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5 Octree space partitioning and triangulation . . . . . . . . . . . . . . . . . . 20

3.6 GUI to start a new ray tracing experiment . . . . . . . . . . . . . . . . . . 22

3.7 Device placement on environment map . . . . . . . . . . . . . . . . . . . . 23

3.8 GUI for setting up an optimizer experiment . . . . . . . . . . . . . . . . . . 26

3.9 Feedback during the optimizer run . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Experiment listing and input-output selection screen for WCDMA . . . . . 31

4.2 Graphical visualization for WCDMA results . . . . . . . . . . . . . . . . . . 32

4.3 Tabular visualization for WCDMA results . . . . . . . . . . . . . . . . . . 32

4.4 Experiment listing for selection of experiments in case of multiple experiment

visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5 Graphical visualization for multiple WCDMA experiments . . . . . . . . . . 34

4.6 Tabular visualization for multiple WCDMA experiments . . . . . . . . . . . 35

4.7 Device placement for ray tracer . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.8 PDP visualization for ray tracer . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.9 Prediction and measurement visualization for ray tracer . . . . . . . . . . . 39

4.10 Prediction and measurement visualization for ray tracer . . . . . . . . . . . 41

4.11 Visualization of power coverage . . . . . . . . . . . . . . . . . . . . . . . . . 42

vi

4.12 Zoomed-in view of visualization of power coverage . . . . . . . . . . . . . . 43

4.13 Objective function value visualization . . . . . . . . . . . . . . . . . . . . . 44

5.1 A visualization of transmitter placement from an older version of S4W. . . . 48

vii

LIST OF TABLES

3.1 Installation management database functions. . . . . . . . . . . . . . . . . . 13

3.2 Input fields for the WCDMA simulator. . . . . . . . . . . . . . . . . . . . . 18

3.3 Input fields description for DXF to XML converter. . . . . . . . . . . . . . . 21

3.4 Input fields description for triangulation and octree space partitioning. . . . 21

3.5 Input fields description for the ray tracer. . . . . . . . . . . . . . . . . . . . 22

3.6 Input fields description for the optimizer. . . . . . . . . . . . . . . . . . . . 25

4.1 Database functions for processing simulation data . . . . . . . . . . . . . . . 30

5.1 Comparison of performances of console based user interface and the GUI for

S4W. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 Comparison of performances based on time consumption for console based

user interface and the GUI for S4W. . . . . . . . . . . . . . . . . . . . . . . 47

viii

Chapter 1

INTRODUCTION AND OVERVIEW

Problem solving environments (PSEs) are integrated computing environments, which

provide all the necessary tools to the user for solving a scientific problem. The science and

engineering communities have many problems where modeling and simulation form the core

of the research work. A PSE is an integrated environment including simulation libraries,

software resources, data management and visual abstractions of the problem domain. The

integrated system can provide a complete and convenient set of high level tools, furnishing

user with the ability to define and modify a problem, choose solution strategies, manage

software and hardware resources, visualize and analyze results and record and coordinate

problem-solving tasks [28]. A finding from Gallopoulos et.al., [10] suggests, “The time

required for many design, analysis, and production tasks will be shortened by one or two

order of magnitude. Further, the results produced will in many cases be better and more

reliable. The challenge is to encapsulate our problem-solving know how into easily used,

flexible systems.”

PSEs in computational science are self-contained systems with all the responsibilities

of language processing, operating systems, underlying software architecture, connectivity

issues and providing a final interface of the integrated system to user. The only part of a

PSE visible to the user is the graphical user interface, so that the user does not need to

worry about underlying intricacies, but has all the required functionalities at hand.

Site-Specific System Simulator for Wireless System Design (S4W) is a PSE developed at

Virginia Tech. The key functionality of this PSE is to predict the performance of wireless

systems in specific environments. S4W uses deterministic electromagnetic propagation and

stochastic wireless system models as underlying simulation components. S4W was designed

1

CHAPTER 1. INTRODUCTION AND OVERVIEW

to support the inclusion of simulation models, validation of models by comparison with field

measurements, integration of optimization loops around the models, and management of the

results produced by experiments [33]. In the initial stage simulation models were written

and validated independently, and later an optimizer was integrated with the models along

with a database. However, the complexity of the system dictates the need for an integrated

user interface for the full system, where users can focus on design and analysis issues of the

problem, rather than be disturbed by integration issues. Also, ad hoc visualizations suit

the analysis needs of this problem domain.

We start with a small description of S4W simulation models in the first section. In the

following two sections we give a brief introduction to the user interface and visualization

implementations for S4W. The last section presents the organization of the thesis.

1.1 Overview of S4W Simulation Models

There are three simulations components in S4W- a 3D ray tracing propagation model,

a Monte Carlo WCDMA wireless system model simulator, and the DIRECT numerical

optimizer. The material is organized into three subsections and each subsection describes

a component.

1.1.1 Ray Tracing Model

Ray tracing is a popular high-fidelity deterministic model of wireless signal propagation.

This model estimates average signal powers and channel impulse responses at receiver loca-

tions of interest. The popularity of ray tracing is due to its wide applicability and relatively

high prediction accuracy [33]. The ray tracer takes a floor plan of indoor environments

in Autocad’s DXF data format and locations of transmitters and receivers as input and

produces impulse response at receiver locations. One impulse response is recorded per pair

of transmitter location and receiver location antennas. An impulse response consists of a

number of rays, where each ray is characterized by an arrival time, a power, a phase, arrival

2


angles, and departure angles. This impulse response is also called a power delay profile

(PDP).

1.1.2 WCDMA Simulation Model

A ray tracing propagation model predicts the impulse response of a wireless channel.

However, propagation models do not directly predict the performance of any particular

wireless system that operates in this channel. S4W provides a Monte Carlo simulation

of WCDMA (wideband code division multiple access) wireless systems. The WCDMA

simulation predicts the BER (bit error rate) of a WCDMA system that operates in a channel

with a given impulse response.

The WCDMA simulation predicts the BER of a wireless system that operates in a

given channel. In the simulation, random information bits are generated and sent through

a wireless channel. The generated information is processed with a series of digital signal

processing techniques to reduce the number of potential errors. The wireless channel is

modeled as a linear Rayleigh fading filter with a given impulse response. Before being sent

to the receiver, the channel output is combined with the Gaussian noise from the electronic

system. The received distorted signal is processed with a series of digital signal processing

techniques by the receiver module. Finally, the estimated information bits are compared

with the original information bits for the BER [32].

1.1.3 Numerical Optimization

VTDIRECT is a global numerical optimizer based on the DIRECT algorithm of Jones

et al. [17]. The optimization study under consideration aims at finding the transmitter

locations that yield an optimal power coverage.

Numerical optimization is an iterative process. An optimizer begins with an initial guess

of the optimization variable values. At each iteration, an objective function is evaluated

and the next set of variable values is constructed according to the optimization algorithm.

This process stops when one of the optimization stopping criteria is satisfied.

3


1.2 Graphical User Interface

An experiment manager for data acquisition and generation (EMDAG) [33] for S4W was

implemented on top of PostgreSQL (a relational database management system). EMDAG

was implemented as middleware for the system integrating a ray tracing propagation model,

a wideband code division multiple access (WCDMA) wireless system model, and a numerical

optimizer. EMDAG supports both experiment and data management and exposes APIs

to be called from the database console. For experiment management, APIs for required

functionalities like starting, stopping and deleting experiments are available (see Table 3.1).

Similarly, for data management a list of useful APIs are available (see Table 4.1). Although

all the desired functionalities are supported by EMDAG, the user still needs to know the

database schema and lengthy manuals for the use of the APIs, which made this type of user

interface burdensome for a PSE user.

Another requirement for S4W was to integrate a visualization tool with the PSE and

eventually control the whole system from one unified interface. For the given constraints

on the selection of a user interface, a graphical user interface was chosen as the unified

user interface for the integrated system. The GUI for S4W is implemented on top of

the database APIs exposed by EMDAG (see Tables 3.1, 4.1). This architecture restricts

the GUI’s interaction with compuatational components using database functions only and

changes in the model (inside APIs exposed by database) can be done without affecting the

functioning of the GUI, achieving a high degree of separation between model and view.

A sketch of interaction of the GUI with the other components via database is shown in

Figure 1.1. The GUI is implemented in Tcl/Tk. Tcl/Tk is a scripting language, widely

used these days for scientific visualization [19]. Tcl/Tk is portable across different operating

systems and has strong support for graphics, database connectivity and communication over

networks [25]. For the S4W interface, EMDAG is largely implemented using Tcl/Tk, which

made the choice of Tcl/Tk an obvious one.

4


Figure 1.1: Outline of S4W design. Components inside the dashed line form the computa-tional unit part of the PSE. Computational components talk to the GUI via the databaseand vice versa.

5


1.3 Visualization

Visualization is the key to understanding the results from large simulations in compu-

tational science and engineering. Users of a PSE typically wish to visualize the output of

their simulations, rather than simply analyzing numbers and text. Sometimes a visualiza-

tion may be generated by a generic tool, but more often an ad hoc visualization tool is

needed [30].

The WCDMA model was initially written in MATLAB, and its initial visualization was

also done using MATLAB. But generic visualization tools offers a visualization without

context [39]. And user played the role to put the context in and segregate the results

according to needs of visualization; then visualizing and saving the graph. This meant

that the user was responsible for retrieving results from the database, selecting the fields of

interest from the data, putting them into an acceptable format for MATLAB, and sending

them to MATLAB for visualization. Results produced by MATLAB also needed some

tweaking to match with the standard graphical form accepted by the wireless engineering

community. For the ray tracer, the visualization results are complex in nature and stored

in the database as strings of characters (see Section 4.2). Ray tracer results need a lot

of preprocessing to obtain a format suitable for visualization. Output from the numerical

optimizer is even more complex in nature. It produces a set of locations for each transmitter

on the floor plan and impulse responses from ray tracer runs or BER values from WCDMA

simulator runs. These complex data pose an interesting challenge for visualizations.

Traditionally, visualization has been used as a post-processing operation to visualize the

results of a simulation. But visualization systems based on a dataflow paradigm are rapidly

gaining popularity in the field of scientific computation [39]. Feedback during runtime is

useful in deciding whether an experiment is going in the right direction or not. Based

on visual feedback, user should be able to stop and re-run the experiment with different

parameters. This feature is incorporated in the design for simulation runs of S4W.

As it is said ‘the whole is greater than sum of the parts’. Visualizations were available in

6


some form for all the components, but the idea of a PSE entails (a) putting them in context,

(b) adding features pertinent to the nature of the problem domain, and (c) integrating with

the user interface. Visualization tools for all components are designed and implemented

using Tcl/Tk and integrated with a unified graphical user interface.

1.4 Organization

This thesis is organized as follows. Chapter 2 presents a literature review for PSEs,

the role of graphical user interface and visualization in PSEs, and Tcl/Tk in visualizations.

Chapter 3 presents the graphical user interface (GUI) part of S4W. This chapter gives details

of functions and features of the S4W GUI along with several screen shots of the different

uses scenarios. In Chapter 4, visualization schemes and tools are presented for all three

components: (i) The Monte Carlo WCDMA wireless system model simulator (ii) The Ray

Tracing simulator, and (iii) The DIRECT numerical optimizer.

One goal of a PSE is to make the system usable in a better way. A comparison of the

integrated system with an earlier non-integrated prototype is presented in Chapter 5. This

chapter analyzes the advantages of building the whole system and draws conclusions from

the work described in previous chapters. In Chapter 6, we outline the main contributions

of S4W to the PSE community and take stock of the lessons learnt from our experience.

7

Chapter 2

RELATED WORK

Just a vision in the 1960s, harnessing computers to interact with people on human

terms has certainly become a reality [10]. PSEs have come a long way from ELLPACK [3]

for solving two and three dimensional elliptic partial differential equations. Geographically

distributed and web-based PSEs, such as WEB-IS, are being used in geosciences for remote

data-analysis and visualization. WEB-IS promises to bring the user interface to handheld

devices connected to the Internet via a wireless connection [41]. From simpler domains such

as PDEs [3] [22] and linear algebra [5], PSEs have now migrated into diverse applications

like wood-based composite design (WBCSim [13]), microarray bioinformatics (Expresso

[1]), gas turbine dynamics simulation [7] and aircraft design (VizCraft [12]). Many domain-

specific PSEs have been developed and with the advent of every new PSE, new standards

get set. However, a fair amount of literature is available on standardizing various aspects

of PSEs. In following two sections, we review the work done in the fields of graphical user

interface and visualization for PSEs. In the final section, we take a look at the role of

scripting languages in scientific visualization with an emphasis on Tcl/Tk.

2.1 Graphical User Interface in a PSE

A graphical user interface attempts to provide easy to use interaction for application

users. Some of the earliest known PSEs like, ELLPACK [3] did not have any graphical

user interface. But the later version of ELLPACK [4], called Interactive Ellpack, added

a graphical user interface for better user interaction. Later still, the parallel version of

ELLPACK (called PELLPACK [22]) had a more sophisticated and portable user interface.

8

CHAPTER 2. RELATED WORK

These three phases of ELLPACK span a period of 13 years. It was not until interactive

version of ELLPACK came that PSE was defined as:

PSE = User interface + libraries + knowledge base + software bus.

PELLPACK defined the user interface as combining a high level language and graphical

interface that allows the user to specify the problem and visualize the solution in some

“natural” form [22]. This definition includes software systems like Matlab, Mathematica,

Maple and PELLPACK.

In the past, a number of PSEs have been developed that provide frameworks for integrat-

ing analysis codes with optimization methods in a flexible manner, besides providing GUIs

for reviewing the results of an optimization process [11]. Framework for Inter-Disciplinary

Optimization (FIDO) [35] demonstrates distributed and parallel execution using an in-

tegrated user interface. FIDO provides the ability to modify input parameters while the

application is executing. iSIGHT [31] provides a generic shell environment for supporting

multidisciplinary optimization (called MDO). LMS Optimus [14] provides a user interface

to set up a problem, select from a number of predefined methods to be used with the

problem, and analyze the results. The DAKOTA iterator toolkit [8] provides a flexible,

object-oriented, and extensible PSE with an integrated interface for a variety of optimiza-

tion methods. Goel et.al., [12] have developed and integrated a graphical user interface in

a PSE for high speed civil transport (called vizcraft). The interface allows users to provide

and modify values of design variables. WBCSim [13] has a high level graphical user inter-

face available via the world wide web, which lets users set design variable values and shows

the progress of the ongoing simulation.

Most PSEs involve large subsystems that are constructed independently. Designing

interface protocols for such components makes an interesting research issue [10]. A model-

view-controller (MVC) paradigm gives a cleaner separation between model (computational

units) and view (user interface) [18]. In our work, the model consists of database and

computational units, the controller is the database APIs exposed by an experiment manager

9


and the view is the graphical user interface. Though many PSEs are reported to have a

portable graphical user interface, no work is known to the author where a portable graphical

user interface is developed for such an architecture involving three geographically distributed

units and linked via the database (see Figure 1.1).

2.2 Visualizations in a PSE

Visualization is defined as an approach in which a computer-generated visual represen-

tation is used to improve our understanding. Since the inception of PSEs, visualizations

have been integral ingredients. In fact, some early PSEs were designed to only visualize the

data [6]. Traditionally, data analysis and visualizations were performed as post-processing

steps after a simulation has been run. As the simulations have increased in size, the task

of visualization has become increasingly difficult – often requiring significant computation,

high performance machines, high capacity storage and high bandwidth networks [16]. Mes-

sac et.al., [23], [24] have developed PhysPro, a MATLAB-based application for visualizing

the optimization process in real time using the physical programming paradigm. The Vi-

sual Computing Environment (VCE) [21] provides a coupling between various flow analysis

codes involved in its multidisciplinary analysis codes. Kingsley et.al., [20] describe Multi-

Disciplinary Computing Environment (MDICE), another PSE that provides users with a

visual representation of the simulations being performed. It provides a distributed environ-

ment where many computer programs operate concurrently and cooperatively to solve a set

of engineering problems. Goel et.al., [12] have developed and integrated a visualization tool

in a PSE for high speed civil transport (called vizcraft). Among other visualization tech-

niques, they use parallel coordinates to visualize the design metrics. Goel et.al., [13] have

reported another integration of visualization tools in a PSE for Wood-Based Composites

Simulations (known as WBCSim).

For present day PSEs, interactive visualization has become a sine qua non. Watson

et.al. [34], define interactive visualization as viewing results of simulations graphically dur-

10


ing or after the simulation run, with the user having control over the content and format

of the graphics during their production. A further extension of the concept of visualization

is computational steering [26], where computational resources are steered towards a specific

interesting process during the simulation [34]. Steering refers to modifying the simulation

itself during the course of the simulation. GRASPARC [6] integrated the computation

and visualization in the PSE, so that the scientist could view a computation as it pro-

ceeded. Moreover, a data recording facility was incorporated to help scientists backtrack

to earlier points of a computation and restart. The GRASPARC work continued in the

KINEX project, which created special-purpose environments for computational chemists,

by integrating CHEMKIN and IRIS Explorer [40]. The EPSRC DIVA project integrated

the tasks of design, analysis and visualization in a coherent environment based on IRIS

Explorer [38].

Scientific visualization is largely seen as a solitary occupation, but efforts have been

made to bring visualizations into group working environments [37]. Modern scientific

research is rarely carried out by an individual. It needs the co-operative efforts of a group

of scientists, with a range of complementary skills. These scientists – maybe at different

sites and need to collectively analyse data from simulations and experiments. Visualization

is a key component of this analysis process; each member of the research team needs to

look at the results from their special angle and with their special expertise, and share their

interpretation with the rest of the team. Indeed special expertise may need to be brought

into the team at the visualization stage – the visualization expert to recommend the best

technique, the artist to suggest the most effective style of presentation [39]. Moreover, once

the research is understood, the results need to be communicated to other workers. Woods

et.al., [36] presented co-operative working in visualization and scientific analysis (known as

COVISA) and explained how an existing visualization system can be extended to support

group working.

In a few cases, commercially available visualization tools were tried [39] for PSEs, like,

Modular Visualization Environments(MVEs). But, generic visualization tools are seldom

11


useful in PSEs, since the problem domain regulates the visualization requirements of the

PSE. In most PSEs, ad hoc visualization tools were developed, along with the modeling

code [30]. In our work, we have developed a visualization tool for each of the simulation

components to cater the specific need of the S4W.

2.3 Tcl/Tk for Scientific Visualizations

Tcl/Tk is extensively used for building graphics these days. Tk is considered a high

level toolkit for building graphical user interfaces [25]. Tcl/Tk was studied and compared

with Visual Basic, for scientific visualization in [19]. Kernighan et.al., [19] find it very

convenient for the case of PSEs, where integration is the mantra. Tcl being a scripting

language has inherent advantages over other high level languages used for writing graphical

user interfaces. Tcl has extensive string processing capabilities that makes it useful for

data-processing. Data-processing is the backbone of scientific visualizations. Thus, Tcl

makes a good candidate as the scripting language for implementing visualization tools.

Tcl/Tk has special features to support inter-process communication over networks. This

feature is extremely useful in integrating heterogeneous components of a PSE. Tk abstracts

platform-specific user interface elements, with their native look and feel, to a platform-

independent programming interface. Still, Tcl provides access to platform specific features,

such as Microsoft Windows DDE and AppleScript. In our work, we used Tcl/Tk as the

only language for implementating the graphical user interface and visualization tools.

12

Chapter 3

THE S4W GRAPHICAL USER INTERFACE

S4W provides a unified user interface for both computational and data components. It

provides users with the capability of starting a simulation, monitoring the run of a simu-

lation with appropriate feedback and viewing the results as they become available. As the

interface to data components, the GUI is designed to retrieve simulation data (both input

parameter values and output results) and display in an appropriate form. The functional-

ities of simulation startup and termination are implemented in EMDAG (see Section 1.2)

as database functions as shown in Table 3.1. The GUI is written as a Tcl/Tk script, which

connects to a database using the Tcl database connectivity library pgtcl [25] and uses the

database functions to control the simulation runs (as shown in Figure 1.1).

The interface also provides a facility to retrieve stored results from the database and

visualize them in a suitable way. We go into details about visualizations in the next chapter.

The graphical user interface for S4W consists of three parts : (i) a GUI for WCDMA, The

Monte Carlo WCDMA wireless system model simulator, (ii) a GUI for the ray tracing

simulator and, (iii) a GUI for the DIRECT numerical optimizer. All three components are

example function description

start_experiment_executor(’x’) start experiment x

stop_experiment_executor(’n’) stop simulation number n

clean_trash(’sioux’) remove trash files on computing unit sioux

Table 3.1: Installation management database functions. These functions are stored in thedatabase and can be called by a database client. A Tcl/Tk script connects the GUI to thedatabase and functions are used by the GUI.

13

CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE

Figure 3.1: Start screen for the graphical user interface of S4W

available from the drop down menu on the first screen of the GUI, as shown in Figure 3.1.

3.1 User Interface for WCDMA Simulator

The WCDMA simulator GUI was built on the experiment manager, EMDAG [33]

and uses the console-based command lines exposed by EMDAG for S4W. The WCDMA

simulation runs on a Beowulf cluster (sioux.cs.vt.edu) with the database on a machine

outside the cluster (order.cs.vt.edu) and a user interface on any another machine which

supports the Tcl/Tk interpreter.

This part of the GUI is implemented in three parts: (a) List Experiments retrieves

WCDMA simulation results stored in the data base with their experiment ID, a brief de-

scription of the experiment, the starting date of the experiment and status of the simulation.

Status can be Fresh, Running, Complete or Crashed. (b) New Experiment opens a form

14


Figure 3.2: Listing of experiments for WCDMA simulations. The right pane shows detailsof one experiment. At the bottom of the pane, there is text box showing a brief descriptionof the experiment

to be filled in for a new simulation run. (c) Visualization gives options for various visual-

izations available for stored results.

List Experiments is a view of the experiments table of the database with only WCDMA

experiments selected (see Figure 3.2). With a left-click on an Experiment id, details of that

experiment appear on the right pane of the screen, which include the input parameters of

the experiment. Just below the details text box, another text box with a brief description

of the experiment appears. The details textbox has a results button at the bottom, and

15


clicking this prompts us to choose between graphical or tabular results. With a right-click

on an Experiment id, a pop-up menu appears with four choices: Details, Clone, Delete

and Stop. Details has the same functionality as that of a left-click. Clone is used to create a

copy of the input parameters for the experiment, and start a new experiment with little or

no change. This functionality is handy, when we need to start a new experiment that is a

slight variation of some stored experiment. Selecting the Clone option creates an input form

with the fields already filled in by the input parameters retrieved from the database. At this

point, it works exactly as if the New Experiment button has been used. Delete is used to

delete an experiment from the database and hence deleting all the stored results associated

with that experiment. The Stop option gives the user choice to stop a running simulation.

This option is useful only when the experiment is running and the corresponding status of

the experiment is Running.

The New Experiment tab is used to create a new experiment. Clicking on the New Experiment

tab causes a form to appear on the screen (see Figure 3.3) with default values for required

input parameters. To start a new experiment, we fill in the required parameters and click

on the Store and Run button. This stores the parameters in the appropriate tables of the

database and invokes the database function to start the simulation on the computing unit.

As the simulation runs on a cluster of computing units, we need to specify a desired number

of nodes to use. However, availability of nodes dictate the actual allocation of nodes, which

might be less than the requested number.

We have another option of just storing the input parameter values using the button Store.

In this case parameter values are only stored in respective tables, but the function invoking

the run is not called. This option is useful if we want to store a set of input values and use

them later on for an actual run. Using the clone command from the List Experiments

view, we can use the same input set and start the actual run later on.

The Visualization tab is used for visualizing results and is discussed in detail in

Chapter 4.

16


Figure 3.3: View of the form for creating a new experiment. It takes input parametersand either stores them into database or starts the run after storing the parameters into thedatabase. The description of input parameters is shown in Table 3.2

17


Field Description

data_rate downlink data rate, bpsno_fingers number of fingers on rake receiverno_inter number of users on the same transmitterfd maximum Doppler frequency, Hzpulse_shape pulse shapecoding type of forward error correction codeshard_soft decoding decision algorithm, usually softsamples_chip make this greater than one for more accurate resultsnoise_level noise output of the receiver, in wattsno_frames number of frames per BER estimatemax_frames hard limit on number of frames for statistically significant runsconfidence how confident would you like to be in the results?rel_error how wide can the confidence interval be?min_ber what is the smallest ber value you care about?channels array of channels from different transmitter antennas

Table 3.2: Input fields description for WCDMA simulator.

3.2 User Interface for Ray Tracer

We use a ray tracer-based simulation to approximate impulse responses. Given a three

dimensional site and a transmitter location, the ray tracer can approximate impulse re-

sponses on chosen receiver locations [29]. The ray tracing simulator has been validated and

calibrated with a series of measurements in the corridor of the forth floor of Durham Hall,

Virginia Tech [2, 32]. An ultrawideband sliding correlator channel sounder [27] operating at

2.5 GHz and outfitted with omnidirectional antennas was used to record impulse response

at six separate locations. Simulated power delay profiles were post-processed and compared

to the measured ones for each of the locations.

A full ray tracing run can be divided into two parts: environment pre-processing and

parallel 3D ray tracing. Preprocessing of environments is sequential and need only be done

once. Once the environment is preprocessed, it can be reused in many runs of the ray tracer.

Preprocessing involves (a) converting floor plans from Autocad’s DXF data format to the

18


XML format understood by S4W, (b) triangulating the polygons (walls) in the floor plan,

and (c) partitioning the triangles into voxels to improve the speed of ray tracing. Ray tracing

first requires setting device locations, device parameters and propagation parameters, and

then starting the real computation.

The GUI for the ray tracer is implemented in two parts. The first part is used to visualize

the results and second part invokes a simulation and monitors the progress of simulation.

The ray tracer visualization is discussed in Chapter 4. The GUI for the two parts of the

ray tracing process is described in the following sections.

3.2.1 Environment Preprocessing

To perform ray tracing on an indoor geographical location, we begin with an Autocad

DXF file. The Pre-processing option of the start menu has three options: Load New

DXF File, DXF to XML converter and Space partitioning and triangulation. While these

three options are sequentially dependent, the interface presents them to be used indepen-

dently at different times. The output of each step is stored in the database and can be used

later on as input for the next step. Hence they are given as three separate options in the

menu.

The first option of Loading a DXF files opens the file selection box from the directory

structure of the system and lets the user choose and then upload the file to the database.

“DXF to XML converter” takes the id of a stored DXF file (done in part one) and a few

more parameters, like boolean values of move center, add floor, add ceiling and

numerical values for elevation, arc length and scale (see Figure 3.4). A description

of the input parameters is shown in Table 3.3. Based on the choices of conversion made

by the user, an XML file is created from the DXF file and stored into the database. The

Space partitioning and triangulation component takes the id of an XML environment

(stored as a result of part two) and some more parameters required for the preprocessing

of the environment. The required parameters are shown and described in Table 3.4. The

Triangulation uses OpenGL to triangulate the polygons of the floor plan. After the

19


Figure 3.4: GUI for the DXF to XML converter

Figure 3.5: GUI for triangulation and octree partitioning of the environment. An XML fileis taken as input along with a few more parameters described in Table 3.4.

20


Field Description

move center move scene origin to (0, 0, 0)add floor add floor to the pictureadd ceiling add ceiling to the pictureelevation elevate 2D lines to rectanglesarc length approximate 2D arcsscale scale scale the picture

Table 3.3: Input fields description for DXF to XML converter.

Field Description

min_dx voxel x dimensionmax_triang maximum triangles in leafmax_dup maximum degree of local duplicationcscale minimum size scale

Table 3.4: Input fields description for triangulation and octree space partitioning.

environment is triangulated, the next step in preprocessing is octree space partitioning.

This space partioning is heuristic. Users must adjust parameters min_dx, max_triang,

max_dup and, cscale to achieve a good quality partitioning. Figure 3.5 shows the GUI for

triangulation and octree space partitioning.

3.2.2 Ray Tracing

We can start ray tracing once we have a preprocessed environment. Setting device

parameters starts with selecting an XML environment (see Figure 3.6) and giving the re-

quired parameters. A description of parameter fields is given in Table 3.5. Selecting an

environment draws the environment on the screen (see Figure 3.7). The first click on the

environment sets the location of the first transmitter, and with proper feedbacks and forms,

we can place subsequent transmitters and receivers. A form to set the device parameters

for a transmitter is shown in Figure 3.7.

Once we are done with placing transmitters and receivers, we can click on the Done

21


Figure 3.6: Starting point for a ray tracing run. We choose a preprocessed environmenthere and a few more parameters as shown in the figure. A description of the parameters isshown in Table 3.5.

Field Description

Max Transmissions set maximum number of transmissionsTransmission Loss set transmission loss (dB)Max Reflections set maximum number of reflectionsReflection Loss set reflection loss (dB)Min Power set ray power threshold (dB)Path Loss Factor set path loss factor

Table 3.5: Input fields description for the ray tracer.

22


Figure 3.7: View of the environment map, where devices (transmitters and receivers) areplaced. The left corner shows the form to be filled in. This form takes parameter values forone transmitter.

button, which sends the data to the database and invokes the ray tracer.

3.3 User Interface for Optimizer

This section describes the GUI for VTDIRECT, a numerical optimizer based on the

DIRECT algorithm of Jones et al. [17]. One goal of S4W is to support transmitter place-

ment optimization. That is achieved by ensuring an acceptable level of wireless system

performance within a geographical area of interest at a minimum cost [15]. The WCDMA

simulator and the ray tracer can be used independently. In contrast, the numerical op-

timizer can be thought of as using the full system as it involves 3D ray tracing runs to

predict impulse responses at points of interest within the environment for the transmitter

locations sampled by the optimization algorithm. The ray tracer gives the power coverage

levels, which are used to define one optimization criterion. Then Monte Carlo WCDMA

simulations are used to estimate the bit error rates (BERs), a second optimization criterion.

23


However, in this work a surrogate function for the WCDMA simulator is used to estimate

the BERs, as WCDMA simulations are computationally expensive. This work uses simple

linear approximation and multivariate adaptive regression splines (MARS [9]) as surrogate

functions to fit the results of a Monte Carlo simulation of a WCDMA system.

The GUI for the optimizer consists of three parts: Preview, New, and Visualization.

In subsequent subsections, Preview and New are described and again visualizations are

described in Chapter 4 on visualization.

3.3.1 Preview of the Environment

As described in Section 3.2.1, we can have environments already stored in the database

which can be used for any new experiment. For the task of device placement in an environ-

ment, either we can store a new environment or use some already stored environment. The

preview tab gives a preview of all the stored environments and draws them on the screen.

This utility is useful, when there are many environments stored and we need to pick the

right one and plan an experiment.

3.3.2 Starting a New experiment

A run of the optimizer can be viewed as an iterative process where for each iteration it

invokes one or multiple runs of the ray tracer to compute impulse responses. These in turn

are used to evaluate objective functions. Then the next set of variable values is constructed

according to the optimization algorithm. This process stops when one of the optimization

stopping criteria is met.

Essentially, an optimization experiment consists of (a) the “slave” ray tracing experiment

used for objective function evaluation, (b) one or two objective functions, (c) two or more

optimization variables, and (d) a few more optimization parameters (described in Table 3.6).

We need to specify a “slave” ray tracing experiment or a template experiment, which

is used by the optimizer in successive iterations to create new experiment points. Defining

a “slave” experiment is exactly the same as defining a new ray tracing experiment, which

24


Field Description

Objective Function primary objective functionMax Evaluations maximum number of objective function evaluationsMax Iterations maximum number of iterations of DIRECTMin Diameter minimum box diameterObj. Conv. relative convergence thresholdProcessors number of processors requested on the cluster of computing units

Table 3.6: Input fields description for the DIRECT optimizer.

is described in Section 3.2. The same functionality is available for setting up a “slave”

experiment starting from the preprocessing step until setting up a ray tracing experiment.

It stores the various parameter values for devices, which are later used in creating the new

ray-tracing experiments for optimization iterations.

Once the “slave” experiment is set, we can set the “master” experiment. Henceforth

“master” is used to describe the optimization experiment, that loops around the “slave”

experiment. A GUI for master is shown in Figure 3.8. Objective functions can be chosen

from the drop-down list at the right-bottom corner. Other entry boxes take other parameters

needed for an optimizer run.

Initial transmitter placement in the environment can be done using a left-click after

choosing the transmitter radiobutton. Likewise, we can enclose each transmitter within

a box, which specifies the area under which the transmitter can move. When choosing

a transmitter, we create a pair of optimization variables, the x and y co-ordinates of the

transmitter. With a click on “Run”, the optimization experiment starts and we get feedback

as flashing messages in a dialogue box. The dialogue box displays the debug messages

generated by the simulation run on the computing unit. These messages are first stored

into the database and from there retrieved by the user interface and then displayed in the

dialogue box. As soon as an iteration is complete and a value for the two objective functions

is available, we get a pop-up window plotting the value against number of iterations in the

Cartesian plane. This gives immediate feedback for the ongoing simulation. However, we

25


Figure 3.8: The graphical user interface for the optimizer with two transmitters. Each ofthe transmitters is enclosed inside a box, which determines the bounds on the transmitterplacement. The entry boxes take parameter values for optimizer runs.

26


have more sophisticated visualization facilities available for optimizer runs that are discussed

in detail in Chapter 4. A screen shot of the feedback dialogue box and feedback plot are

shown in Figure 3.9. This runtime feedback is needed in these cases, where experiments

typically run for hours and the user needs to have some immediate feedback.

27


Figure 3.9: Feedback during a run of the optimizer with one transmitter. Points on thegraph show the x and y co-ordinates of the transmitter with each iteration. The dialoguebox on the right gives feedback sent by the simulation process running on the computingunit.

28

Chapter 4

VISUALIZATIONS FOR S4W

Visualization can facilitate data analysis in a significant way. Visualization is the key for

providing better insight into the problem with the ability to provide novel interpretations of

simulation data. In the present study, we also see how visualization can aid the designer to

search through the design space and formulate a new experiment taking clues from stored

simulation results.

In many early PSEs, commercially-available visualization systems were used. A detailed

study on the role of commercially-available visualization systems can be found in [39].

Early versions of S4W, with no GUI or integrated visualization tools, used Mathematica

and Matlab for visualizations [32]. But domain specific problem-solving dictates the need

for customized visualization. The visualization scheme for S4W now consists of separate

visualizations for each of the three components of the system. The database acts as the

backbone of the visualization system. Upon a request to visualize simulation data, the

front end of the system connects to the database and retrieves results in a form suitable for

visualizing. For data processing, it uses the APIs exposed by EMDAG (see Table 4.1) along

with the Tcl scripts written specially for desired functionalities. The visualization tools for

the three components of S4W are presented in the following sections.

4.1 Visualizations for the WCDMA Simulator

Each simulation for a Monte Carlo WCDMA simulator has an associated set of pa-

rameter values, with typically one parameter changing value in steps after each iteration.

Normally a WCDMA simulation is done to study the effects of change in some parameter

29

CHAPTER 4. VISUALIZATIONS FOR S4W

function description

total_power(raw_pdp) the sum of ray powers, in wattspeak_power(sampled_pdp) the maximum of bin powers, in wattsmean_excess_delay(raw_pdp) see [27]rms_delay_spread(raw_pdp) see [27]bin_width(sampled_pdp) bandwidth resolution, in nsnum_bins(sampled_pdp) the number of bins with non-zero powerwidth(sampled_pdp) one more than the index of the last binnth_power(sampled_pdp,n) power of bin n, in wattstrim_bins(sampled_pdp,threshold) remove bins with relatively small powerresample(sampled_pdp,bin_width) heuristic resampling

Table 4.1: Database functions for processing simulation data. These functions are used toprocess the simulation data to obtain a form suitable for visualization

value on the system performance in the form of objective measures of BER and FER. One

more measure of performance is added for this implementation of the WCDMA simulator:

number of frames simulated. Though non-standard for WCDMA simulations, this output

is useful as it gives the idea of performance of the system for a given range of parameters.

The WCDMA visualization provides a plot of the varying parameters against one of

the output values (BER or FER). For each of the experiments, a visualization scheme is

available where we can choose one of the input parameters, and one of the output parameters

and view the result in graphical form for each iteration as a point on a Cartesian plane.

However, a tabular form of results is also needed to see the values of other parameters

along with the results. This tabular form is view of a database table of some WCDMA

experiment. The earlier version of S4W required the user to connect to the database and

view the results (in tabular form) using SQL commands on the console. To view results in

graphical form, users required to retrieve the data from the database, store it on the disc

and then visualize it using some commercial visualization software. In some cases, a design

engineer might be interested in comparing results of more than one experiment with similar

sweeps over one parameter and changing values for some other parameter. This situation

requires more cumbersome activities involving retrieval of data from the database when

30


Figure 4.1: Listing of experiments for WCDMA simulations. In the right pane, we haveinput parameters in the left column and output parameters in the right column with radiobuttons. Here we can choose one input parameter and one output parameter for display.

visualizing it using some generic visualization tool.

To address these problems in visualizing the results of WCDMA simulations, S4W of-

fers two options: (a) viewing results of one experiment, and (b) visualizations involving

comparisons of multiple experiments.

Under the List Experiments tab for WCDMA simulation (see Figure 3.2) we get a

listing of experiments and with a left-click on the experiment id, the right part of the

screen shows the details of experiment. At the bottom, we have a (show) RESULTS button.

Clicking this button prompts the user to select a choice of visualization, either graphical or

tabular. When selecting the tabular view, there appears a view of a portion of the database

table storing the results for WCDMA experiments (see Figure 4.3). Selecting the graphical

view prompts the user to select one parameter each from input and output variables (see

Figure 4.2). With a click on the Show Results button, we see a graph of input versus

output parameters as shown in the left side of Figure 4.1. According to our needs, we can

31


Figure 4.2: Graphical visualization for one input and one output parameter. The left-handside shows the original view with a selected area to zoom in, and the right-hand side showsa zoomed-in view of the same graph.

Figure 4.3: Tabular visualization for one experiment of WCDMA. Each row shows a setof input parameter values with output parameter values (BER, FER, Frames) in the lastthree columns.

32


Figure 4.4: Listing of experiments for multiple selection (with check buttons) along with achoice of graphical or tabular visualization at the bottom of the pane.

zoom in or zoom out on the graph by selecting an area on the graph by left-clicking the

mouse, and can restore to the original size by right-clicking the mouse. A zoomed-in graph

and its original variant is shown in the Figure 4.1. This tool also has the facility to save

graphs as PostScript images with the Save button at the bottom of the window.

Under the Visualization tab for the WCMDA component, we have the facility to

compare the results of any number of experiments. We can filter the results retrieved from

the database and choose the experiments with some keyword in the ID or description. Using

this filter retrieves only the experiments with the given keyword (shown in Figure 4.4). We

can choose any number of experiments using the check buttons, to visualize the experiments

collectively. Once we are done with selecting experiments, we can choose between tabular or

graphical displays. Here also we have all the functionalities that we had for one experiment,

with the only difference that now we have simultaneous results for multiple experiments.

The graph shows the iteration points for different experiments with different colors (see

33


Figure 4.5: Graphical visualization for two experiments at the same time. Red balls showthe experiment points for w-sweep1 and black ones represent points for w-sweep2. For agrey scale copy of this picture, balls at the upper edge are red and balls at the lower edgeare black.

34


Figure 4.6: Tabular view of results of two experiments w-sweep1 and w-sweep2. Results oftwo queries for the two experiments is merged to create this table.

Figure 4.5). For the tabular results, a union of results from database queries for different

experiments is shown (see Figure 4.6).

4.2 Visualizations for the Ray Tracer

A ray tracing run computes impulse responses in the form of a power delay profile (PDP)

at specified locations (see Section 1.1.1). A power delay profile is a measure of power at

certain time intervals. The ray tracer records the ‘raw’ impulse responses churned out from

the computation. One impulse response is recorded per pair of transmitter location and

receiver location antennas. An impulse response consists of a number of rays. Recall that

each ray is characterized by an arrival time, a power, a phase, arrival angles, and departure

angles [33]. A PDP is the only output of the ray tracer and is stored as a special data

type, which is a list of seven-tuples of ray attributes. This output is not of a trivial data

type and requires many post processing steps before it could be used for any visualization.

A fragment of PDP is shown below which shows six out of approximately seventy rays for

a receiver-transmitter pair.

35


((33.2,3.65e-07,3.45,2.96,1.59,0.195,1.57),

(34.4,7.93e-08,3.15,-2.18,2.76,-0.0052,1.9),

(35,7.62e-08,3.11,2.69,1.9,0.195,1.89),

(35.6,8.22e-08,0.0456,2.74,1.56,-0.414,1.57),

(37,2.34e-07,5.8,-3.03,0.934,-0.0052,1.08),

(37.3,1.7e-08,4.21,2.91,1.93,-0.414,1.87)).

The complex nature of the output demands a sophisticated visualization tool which

should cater to the complex visualization needs of data. Before any visualization, a number

of post processing steps are needed to convert this form of data into a standard power delay

profile format. For the post processing of this data type a set of functions is available (as

show in Table 4.1). Using the functions we can extract the information in the form of a

value for peak power of each arriving ray, and visualize this form of power delay profile. In

this implementation, we create an XML file containing the time of arrival and peak power

for each of the arriving rays. This file is then fed to the visualization tool which draws it

on the graph. An XML file generated from the PDP (shown above) is shown here.

<?xml version="1.0" ?>

- <pdp rmsDelaySpread="21.0764" meanExcessDelay="14.6738"

totalPower="-55.2306" peakPower="-61.9886">

<ray time="-3" power="-76.2767" />

<ray time="-2" power="-67.6952" />

<ray time="-1" power="-63.5184" />

<ray time="0" power="-61.9886" />

<ray time="1" power="-63.6248" />

<ray time="2" power="-68.9865" />

</pdp>

- 

36


Figure 4.7: Screen shot of the environment drawn on screen. (Tx)s show the transmitterlocation and (Rx)s show the receiver location.

A run of the ray tracer starts with placing a transmitter in the environment and then

measuring impulse responses at receiver locations. A visualization tool has been imple-

mented which draws the environment map on the screen and shows the transmitter loca-

tion and receiver locations (see Figure 4.7). Receiver location can be a point or an area

that is divided into a grid (henceforth called the reception grid) and impulse responses are

measured at grid points. When a receiver location is clicked, a window pops up and shows

the power delay profile at that point (see Figure 4.8).

37


Figure 4.8: Power delay profile visualization for a receiver location.

Ray tracing runs are used extensively for the optimal transmitter placement problem.

But seldom is an independent run of the ray tracer stored in the database, except when

calibrating the ray tracer. The ray tracer has been validated and calibrated with a series

of measurements [2, 33]. For this purpose, the impulse response was measured at seven

different locations for a transmitter placed in the corridor of the fourth floor of Durham

Hall, Virginia Tech (see Figure 4.7). Both measured and predicted values of PDPs at these

locations are available. A visualization of the comparison between measured and predicted

PDPs reveals the similarity between the two and validates the implementation of the ray

tracer. Figure 4.7 shows the transmitter and receiver locations. With a click on any of the

receiver locations, a window pops up with the power delay profiles for both measurement

and prediction (see Figure 4.9). Also, with a click on transmitter location, we can see all

the PDPs (at all receiver locations) in the same window. A zooming facility is available

with selection of any desired part on the graph, as shown in Figure 4.9.

38


Figure 4.9: Simultaneous visualization of the PDPs obtained by measurement and a run byray tracer. The Figure at the top shows the original view, with area to be zoomed-in shownin the rectangle. Figure at the bottom shows the zoomed in area that was selected in thefigure at top.

39


4.3 Visualizations for the Optimizer

A run of the optimizer predicts the positions of transmitters for optimal performance

of the wireless system for a chosen region. We start the experiment by selecting an area of

interest on the environment map. We then place transmitters within the area of interest

(see Section 3.3). In an earlier version of S4W, the only feedback available to the user

was the final location(s) of the transmitter(s) and the objective function values, which were

stored in the database. While these numerical values can convey the degree of success to

the design engineer, they lack the power to convey the area of coverage related to the final

(optimal) settings.

With each iteration, objective functions change their values. A visualization of these

objective function values with each iteration can provide better insight into the optimizer

behavior. At the end of an experiment, we get a final placement of transmitters and

corresponding to this iteration of the optimizer, we get the final value of power levels inside

the area of interest. A color map showing the intensity of power coverage would give design

engineers the real feel of optimal coverage. The visualization features integrated into S4W

are presented in the following sections.

Under the visualization tab of the Optimizer GUI we can retrieve all stored optimiza-

tion experiments. Filtering experiments based on keywords is also available, i.e., we can

retrieve only a subset of all experiments whose experiment ids or description contains

some keyword. With a left-click on the experiment id, a box containing details of the

experiment and a smaller box below it with a small description of the experiment appear

on the right pane as shown in Figure 4.10. To visualize the results of the experiment, either

we click on the RESULTS button at the bottom of the Details box, or the same effect can

be achieved by selecting visualize from the pop-up menu that comes with a right-click

on experiment id. Two options are available for visualization: transmitter location and

power coverage visualization, and objective function value visualization.

40


Figure 4.10: A list of experiments for the optimizer.

4.3.1 Visualization of Final Power Coverage

Selecting the Transmitter location visualization pops up a window with the en-

vironment map drawn on it and the area of interest showing a color map of the power

coverage for optimal transmitter placement (see Figure 4.11). Users have the choice of

zooming in to any selected area on the map. A click on the map zooms in to the area of

interest by default. A zoomed-in view of the visualization map for power coverage is shown

in Figure 4.12.

4.3.2 Visualization of Objective Function Values

In each iteration of the optimizer, objective functions are evaluated for sampled points.

A plot of objective functions gives meaningful insight about the progress of the optimization

loop. Selecting Objective function visualization pops up a window with a plot of

two objective function values against the iteration number (as shown in Figure 4.13. This

visualization is useful in keeping watch on progress of two objective functions. The optimizer

41


Figure 4.11: Visualization of power coverage on the environment map. Intensity of color isproportional to the power level.

42


Figure 4.12: A zoomed-in view of area of interest of Figure 4.11. This figure shows thepower levels for the area of interest only. Figure 4.11 shows the same within the context ofthe full environment map.

43


Figure 4.13: Visualization of change in two objective function values with iterations. Firstobjective function is based on power coverage and the second one is based on ber shortfalls.

stops when the objective functions meet their termination conditions with given values of

relative convergence thresholds (Obj. Conv.). Users can zoom in or zoom out on the graph

by selecting an area on the graph by left-clicking the mouse and can restore to the original

size by right-clicking the mouse. The graph can be saved as a PostScript image.

44

Chapter 5

COMPARISONS AND CONCLUSIONS

In Chapters 3 and 4 we saw how S4W is integrated as a system with a high level

graphical user interface and ad hoc visualizations. The system is intended to provide an

easy to use interface, and encapsulate the underlying implementation and connectivity

details. To verify the claim, we compared the system as it existed before this integration

and visualization work and then the integrated system after the work. Details of the findings

for this comparison is presented in next section, followed by a conclusions and future work

section.

5.1 Comparisons

To evaluate the advantages of the newly integrated system, we took the following usage

scenario for S4W. A wireless design engineer wishes to study transmitter placement in

an indoor environment located on the fourth floor of Durham Hall, Virginia Tech. The

engineering goal is to achieve a certain performance objective, given the cost constraints.

For a narrowband system, power levels at the receiver locations are good indicators of

system performance. Thus, minimizing the average shortfall of power with respect to some

threshold value of power can be a good objective. Here, the major cost constraints are

the number of transmitters and their powers. Different placements of transmitters yield

different levels of coverage. Our goal is to find the optimal placement of transmitters. This

work was done earlier using the PSE without any integrated GUI and visualization support,

and reported in [32]. We repeated the same experiment with the new integrated system and

achieved the same results with relatively less difficulty. Also the results could be presented

45

CHAPTER 5. COMPARISONS AND CONCLUSIONS

in a better way using the newly added visualization tool.

5.1.1 Value Addition with GUI

Earlier this experiment was done largely using console-based commands and with no vi-

sual feedback. As the first step to run this experiment, the user created a template of a ray

tracing experiment, to be used by the optimizer as the starting point for its first iteration.

This involved setting various parameter values for the wireless devices (see Section 3.2).

The next step was to specify various parameter values for the numerical optimizer. Finally,

the simulation was started using a database function. This whole process involved a series

of database operations of insertions and selections. The user was required to create a list of

SQL commands to store the various parameters of experiment in the order specified by the

schema of the corresponding database tables (for details see [33]). The process required a

high level of knowledge of the database schema and also some idea of how a database works.

These requirements are the antithesis of a PSE, where the system is to be used by domain

experts (electrical engineers), not system tool experts. In the present version of S4W, the

GUI takes care of all these issues. Unlike the original integration, S4W is now portable to

many platforms. S4W has been tested on Microsoft Windows and Sun Solaris platforms.

Advantages of the current system over the old system are enumerated as follows:

(1) It has taken away the burden from the PSE user to know about the database

schemas of tables and their inter-relations.

(2) Users do not need to know about database functions, previously exposed by

the experiment manager to do some operations.

(3) PSE users do not need to worry about some error in the SQL commands and

risk an error at run time, as error checks are incorporated into the GUI.

(4) The GUI package is portable and works on any system inside the LAN; users

can install the GUI on any machine connected to the network.

46


Task Number of Mouse Clicks Number of Lines on Console

Setting a Run of Optimizer 20–35 95–120Setting a Run of Ray Tracer 18–30 70–90Setting a Run of WCDMA 6–20 40–75

Table 5.1: A comparison of performances of console based user interface and the GUI forS4W based on the performance metrics of mouse clicks (for the integrated GUI) and numberof lines typed on console (for the unintegrated system) to accomplish the same tasks.

Task Time Taken with GUI Time Taken with Console UI(in minutes) (in minutes)

Setting a Run of Optimizer 5–10 30–45Setting a Run of Ray Tracer 5–10 25–40Setting a Run of WCDMA 1–5 20–35

Table 5.2: A comparison of performances of console based user interface and the GUI forS4W based on average time consumption for starting various simulation runs.

There can be no objective measure for ease of use, as it takes different meanings for

different users. But we have tried to come up with an approximate metric to quantify the

amount of effort put in by the user. Users interact with a graphical user interface with

mouse clicks. And mouse clicks can be thought of as the basic operation in interacting

with a GUI. While on a console based user interface, the basic operation can be thought

of as pressing a key. However, these two operations can not be compared, as the degree

of connection might vary drastically from one user to other. Taking into consideration the

user domain, we chose an approximate metric as the number of lines for console based user

interfaces. For the next metric, we chose the average time spent in creating an experiment

and sending it to computational unit to run. We compared the two user interfaces with

respect to these two metrics. A comparative result is given in the Table 5.1 and Table

5.2. Although these measures are approximate and give a range of values, we get a good

insight in how the GUI helps the domain user in performing a task.

47


x, m

y, m

806040200

30

20

10

Figure 5.1: A visualization of transmitter placement from the older version of S4W. Aseparate program generated the environment map and the rest of the figure was drawnusing generic tools.

5.1.2 Better Insight into Results with Visualization Tools

To visualize the final position(s) of the transmitter(s), an ad hoc script was written

for the original experiment. This script drew the environment map, and final locations of

transmitters were marked on the map manually, as shown in Figure 5.1. Other forms of

visualizations used in [32] were generated using generic graphics tools. With the integra-

tion of visualization tools for all three components, S4W can now generate sophisticated

visualizations on its own.

With the last iteration of the optimizer, final locations of the transmitters are decided,

which determines the power levels received at the locations inside the area of interest. A

visualization for power levels, using a color map, is available with the system (shown in

Figure 4.11 and a zoomed-in view in Figure 4.12). This visualization provides a better

insight about the final result.

For visualizing objective functions, a visualization tool is available now. It plots the two

objective function values on the Cartesian Plane and gives facilities for zooming and saving

the image in Postscript format.

48


With the aid of these tools, an S4W user can now generate better and more sophisticated

visualizations.

5.2 Conclusions and Future Work

We integrated the PSE with a high-level graphical user interface and component-specific

visualization tools, which is believed to enhance the usability of the system. We examined

the use of domain specific ad hoc tools for visualizations in a PSE and a graphical user

interface with clean separation from the computational model. It turned out to be a fairly

stable and useful model for PSEs of domain specific nature. With the integration of a

graphical user interface and visualization tools, S4W has evolved as a complete Problem

Solving Environment for wireless system design. S4W supports fundamental problem solv-

ing in broadband wireless communication systems along with serving as a flexible design tool

for the deployment and performance evaluation of emerging wireless systems. It also vali-

dates new wireless communications modeling approaches. Enhanced designer performance

is achieved by the synergy resulting from the integrated PSE.

A variation of this design would be a web-based interface in place of portable GUI of

the system. But, the nature of problem domain requires security. As simulations are run

and stored in database per user. A security breach can play havoc with simulation data

stored in the database. The present form of the PSE serves well the purpose of domain

users. However, the possibility of web-based version of this PSE can be explored.

49

Chapter 6

LESSONS LEARNT FROM THE EXPERIENCEOF S4W

PSEs have come a long way from merely a tool to solve partial differential equations

to sophisticated software applications, capable of simulating complex scientific experiments

and managing gigantic amounts of data. Contributions were made by several PSEs, rang-

ing from distributed collaborative problem solving to software engineering of customizable

architectures. Although many of these PSEs were domain specific solution providers, they

contributed to the community in terms of enabling technologies and their experiments with

various design considerations and implementation options. S4W has many experiences to

share. We had successful experimentation with creating a graphical user interface and

integrating it with back-end computation using a scripting language, integration of data

management and execution management by the means of a relational database, use of the

DIRECT numerical optimizer, replacing expensive computation by computationally cheap

surrogate functions and creating a high level interactive visualization tool and integrating

it into the system, again using a scripting language. In following sections we outline the

main contributions of S4W to the PSE community and take stock of the lessons learnt from

our experience.

6.1 Experimentation with a relational database system

One of the primary contributions of this research is integration of data management

and simulation management by means of a relational database and providing high level

functionality for data-analysis. S4Ws architecture uses a Postgresql database as hub. User

50

CHAPTER 6. LESSONS LEARNT FROM THE EXPERIENCE OF S4W

interface and computing units both talk to database and most of the data processing is also

done with database using stored functions written in C and PLSQL. This topology is suit-

able for data-centric simulation experiments. It facilitates the data-analysis and optimizes

the data movement across the network. Also, it separates computing units from the user

interface completely. We can plug-in any computing unit according to our need. Most of

the intensive computation was done on a cluster of machines. But for small simulations

(computationally not so extensive) we also used single processors. This task of changing

the computational unit was made easy due to this architecture.

6.2 Experimentation with scripting in creating graphical user interface,

visualization tools and integration of the system

For heterogeneous systems scripting has often been the glue to create an integrated

system. For our system, we had options of a procedural language like java and scripting.

We selected Tcl/Tk as the scripting language for integration and it turned out to be a good

choice. In most of the implementation of PSEs, groups of people from different backgrounds

work together and in many cases development runs in parallel with different choices of

programming platforms and programming languages. The final stage is the integration

stage, where we need to take the pieces of the system and glue them together to create the

integrated system. For S4W also we had a similar situation. We had different components

written in different languages like C, FORTRAN and MATLAB and on different platforms

like Sun-Solaris and Microsoft-Windows, and our job was to create a portable user-interface.

Tcl/Tk suited all our needs and worked as glue for all of components. Also, a user-interface

written in Tcl/Tk is platform independent. We could have achieved this goal using some

platform independent language like Java. But extensive string manipulation capability,

excellent network connectivity and good support for database connectivity were the points

where Tcl/Tk scored over Java. We had a good experience with this scripting language as a

medium to integrate heterogeneous PSE components and provide a suitable graphical user

51


interface.

A requirement specific visualization tool is created and integrated to the database and

graphical user interface. This tool provides the user with capability to view the stored

simulation results in various domain-specific formats and also to compare results of different

simulations. This tool is also written using Tcl/Tk and integrated easily with the rest of

the system.

6.3 Surrogate functions

Even the fastest computers or a collection of such computers is not good enough in

many cases. For Monte Carlo simulations of a channel model, it takes days to run the

simulation on a 180 node Beoulf cluster of computing units for a few hundreds of points.

One important lesson from our experience is that the power of modern computing is no

substitute for good mathematics. To simulate the behavior of a WCDMA, we used a

surrogate model using multivariate adaptive regression spline. Using a surrogate function

we were able to effectively simulate the behavior of the original function at a fraction of the

cost.

6.4 Scenario and experiment management

A typical PSE consists of three phases – data preparation, simulation (or measurements)

and data analysis, and these three phases can be repeated and interleaved in arbitrary ways.

In our model, simulation corresponds to loading data into the database, data analysis cor-

responds to querying the database and presenting data-visualization at the graphical user

interface level, and data preparation corresponds to a combination of loading and querying.

The database approach of experiment management has been explored in some projects.

The ZOO desktop experiment management environment aims to achieve goals similar to

ours. However, ZOO is too generic to be directly applicable in a PSE setting. In particular,

it does not support parallel simulation, a task that is central in our PSE. Many systems

52


like Globus and Legion tried to integrate simulation execution, but they do not provide

a database interface. We adopted a hybrid approach that incorporates both simulation

data management and simulation execution management to create the experiment man-

ager EMDAG for S4W. This experimentation demonstrated that data management can be

usefully harnessed, in multiple ways, in a PSE.

6.5 Optimization

Decision making processes in PSEs are often complex and require support by automated

optimization techniques. S4W uses an optimization algorithm known as DIRECT (Divid-

ing RECTangles), a direct search algorithm proposed by Jones et al. A version named

VTDIRECT was integrated with S4W to find the optimal locations of transmitters. This

integration turned out to be a success and this global optimization algorithm has proved to

be an effective approach in solving transmitter placement problems [32].

6.6 Summary

We have shown that appropriate use of the relational model and a state-of-the-art

database management system can provide reasonably high level problem solving facilities.

For example, objective function evaluation for the numerical optimizer was implemented

using simple SQL queries and format conversion and surrogate models for PSE data are

implemented as stored database functions.

A sufficiently flexible relational database can act as interpreter for a scripting language

specifically designed for data processing. A library of custom data types, functions, and

aggregation operators naturally specializes this language for a particular application domain.

The utility of overloading query semantics is potentially enormous. Not only does this

approach simplify format conversion of the simulation data, it can ultimately change the

way users look at their experiments. Parts of simulations can, in principle, be implemented

as database queries.

53


On a more practical note, the overwhelming advantages of the relational model over its

more flexible competition are the maturity of the relational model and the wide availability

of high quality relational databases. Neither the semi structured nor the object oriented

data model can currently compete with the relational model along these dimensions.

Future PSEs may benefit from our experience of using a general purpose workflow

management system. Relational schemas enforce some constraints on workflow, but there

is no centralized workflow management. Workflows can be scripted (e.g., in Tcl), but there

is a long way from scripting workflows in a general purpose language to a high-level workflow

management system.

Finally, high level domain specific schema editing tools can be built. However one

must realize that databases do not magically solve all the data management problems. No

amount of point and click gadgets can replace a careful schema design. Designing appro-

priate schemas and integrating these schemas with those of the other system components

is ultimately the responsibility of the simulation developer. The most problematic part of

schema development is the precise definition of simulation inputs and outputs; once the

simulation is well defined, the data model flows.

54

REFERENCES

[1] R.G. Alscher, B.I. Chevone, L.S. Heath, and N. Ramakrishnan. Expresso — a PSEfor bioinformatics: Finding answers with microarray technology. In A. Tentner, editor,Proceedings of the High Performance Computing Symposium, Advanced SimulationTechnologies Conference, pages 64–69, April 2001.

[2] C.R. Anderson. Design and implementation of an ultrabroadband millimiter-wavelength vector sliding correlator channel sounder and in-building multipath mea-surements at 2.5 & 60 GHz. Master’s thesis, Virginia Tech, May 2002.

[3] R.F. Boisvert and J.R. Rice. Solving elliptic problems using ellpack. 1985.

[4] J.P. Bonomo, W.R. Dyksen, and J.R. Rice. The ELLPACK Performance EvaluationSystem. Technical Report CSD-TR-569, Department of Computer Sciences, PurdueUniversity, 1986.

[5] R. Bramley, K. Chiu, S. Diwan, D. Gannon, M. Govindaraju, N. Mukhi, B. Temko,and M. Yochuri. A component based services architecture for building distributedapplications. In Proceedings of the Ninth IEEE International Symposium on HighPerformance Distributed Computing (HPDC’00). IEEE Press, 2000.

[6] K. Brodlie, A. Poon, H. Wright, L. Brankin, G. Banecki, and A. Gay. Grasparc: Aproblem solving environment integrating computation and visualization. Proceedingsof IEEE Visualization 1993 Conference, pages pages 102–109, 1993.

[7] T.T. Drashansky, E.N. Houstis, N. Ramakrishnan, and J.R. Rice. Networked agentsfor scientific computing. Communications of the ACM, Vol. 42(3):pages 48–54, March1999.

[8] M.S. Eldred and W.E. Hart. Design and implementation of multilevel parallel opti-mization on the intel teraflops. In Seventh AIAA/USAF/NASA/ISSMO Symposiumon Multidisciplinary Analysis and Optimization, number AIAA-98-4707, pages pages44–54, September 1998.

[9] J.H. Friedman. Multivariate adaptative regression splines. Annals of Statistics, Vol.19(1):pages 1–141, 1991.

[10] E. Gallopoulos, E. N. Houstis, and J. R. Rice. Workshop on problem-solving envi-ronments: Findings and reccomendations. ACM Computing Surveys, Vol. 27(2):pages277–279, June 1995.

55

REFERENCES

[11] A. Goel. Visualization in problem solving environments. Master’s thesis, Virginia Tech,June 1999.

[12] A. Goel, C.A. Baker, C.A. Shaffer, B. Grossman, W.H. Mason, L.T. Watson, and R.T.Haftka. VizCraft: A problem-solving environment for aircraft configuration design.IEEE/AIP Computing in Science and Engineering, Vol. 3(1):pages 56–66, 2001.

[13] A. Goel, C. Phanouriou, F.A. Kamke, C.J. Ribbens, C.A. Shaffer, and L.T. Watson.WBCSim: A prototype problem solving environment for wood-based composites sim-ulation. Engineering with Computers, Vol. 15:pages 198–210, 1999.

[14] P. Guisset and N. Tzannetakis. Numerical methods for modeling and optimizationof noise emission applications. In ASME Symposium in Acoustics and Noise Con-trol Software, ASME International Mechanical Engineering Congress and Exposition,November 1997.

[15] J. He. Global optimization of transmitter placement for indoor wireless communicationsystems. Master’s thesis, Virginia Tech, August 2002.

[16] C. Johnson, S. Parker, C. Hansen, G.L. Kindlmann, and Y. Livnat. Interactive simu-lation and visualization. IEEE Computer, Vol. 32(12):pages 59–61, 1999.

[17] D.R. Jones, C.D. Perttunen, and B.E. Stuckman. Lipschitzian optimization without theLipschitz constant. Journal of Optimization Theory and Applications, Vol. 79(1):pages157–181, 1993.

[18] D. Olsen Jr. Developing user interfaces. Morgan Kaufmann Pub, 1998.

[19] B.W. Kernighan. Experience with tcl/tk for scientific and engineering visualization.Technical report, AT&T Bell Laboratories, Murray Hill, New Jersy.

[20] G. Kingsley, J.M. Siegel Jr.and V.J. Harrand, C. Lawrence, and J.J. Luker. De-velopment of a multi-disciplinary computing environment (mdice). In SeventhAIAA/USAF/NASA/ISSMO Symposium on Multidisciplinary Analysis and Optimiza-tion, number AIAA-98-4738, pages pages 251–260, September 1998.

[21] G. Kingsley, V.J. Harrand, , and C. Lawrence. A visual computing environment forcomputational aerosciences. In Proceedings of the 1996 Computational AerosciencesWorkshop, pages pages 331–338, 1996.

[22] S. Markus, S. Weerawarana, E.N. Houstis, and J.R. Rice. Scientific computing via theworld wide web: The net PELLPACK PSE server. IEEE Computational Science &Engineering, Vol. 4(3):pages 43–51, July-September 1997.

[23] A. Messac. Physpro: Software package for optimal design. In Optimal Systems. 1994.

56

REFERENCES

[24] A. Messac and X. Chen. Visualizing the optimization process in real-time using physi-cal programming. In Seventh AIAA/USAF/NASA/ISSMO Symposium on Multidisci-plinary Analysis and Optimization, number AIAA-98-4708, pages pages 55–66. Septem-ber 1998.

[25] J. K. Ousterhout. An Introduction to Tcl and Tk. Addison-Wesley, 1994.

[26] S.G. Parker, C.R. Johnson, and D. Beazley. Computational steering software systemsand strategies. IEEE Computational Scicnce and Engineering, Vol. 4(No. 4):pages50–59.

[27] T.S. Rappaport. Wireless Communications: Principles and Practice. Prentice Hall,New Jersy, 1996.

[28] J.R. Rice and R.F. Boisvert. From scientific software libraries to problem-solvingenvironments. IEEE Computational Science & Engineering, Vol. 3(3):pages 44–53,Fall 1996.

[29] S.Y. Seidel and T.S. Rappaport. Site-specific propagation prediction for wireless in-building personal communication system design. IEEE Transactions on VehicularTechnology, Vol. 43(4):pages 879–891, 1994.

[30] C.A. Shaffer, L.T. Watson, D.G. Kafura, and N. Ramakrishnan. Features of problemsolving environments for computational science. In Proceedings of High performanceComputing Symposium, Advanced Simulation Technology Conference, pages pages 242–247. A. Tentner Educational Society for Modeling and Simulation Int, San Diego,September 1999.

[31] S.S. Tong, D. Powell, , and S. Goel. Integration of artificial intelligence and numericaloptimization techniques for the design of complex aerospace systems. Number AIAA-92-1189. February 1992.

[32] A. Verstak, J. He, L.T. Watson, N. Ramakrishnan, C.A. Shaffer, T.S. Rappaport,K. Anderson, C.R. Bae, J. Jiang, and W.H. Tranter. S4W: Globally optimized design ofwireless communication systems. In Proceedings of the Next Generation Software Work-shop, 16th International Parallel and Distributed Processing Symposium (IPDPS’02).IEEE Press, April 2002. Fort Lauderdale, FL.

[33] A.A. Verstak. Data and computational modeling for scientific problem solving envi-ronments. Master’s thesis, Virginia Tech, july 2002.

[34] L.T. Watson, V.K. Lohani, D.F. Kibler, R.L. Dymond, N. Ramakrishnan, and C.A.Shaffer. Integrated computing environments for watershed management. Journal ofComputing in Civil Engineering, Volume 16(No. 4):pages 259–268, October 2002.

57

REFERENCES

[35] R.P. Weston, J.C. Townsend, T.M. Edison, , and R.L. Gates. A distributed computingenvironment for multidisciplinary design. In 5th AIAA/NASA/ISSMO Symposiumon Multidisciplinary Analysis and Optimization, number AIAA-94-4372, pages pages1091–1097, September 1994.

[36] J. Wood, H. Wright, and K. Brodlie. Cscv - computer supported collaborative visualiza-tion. In Proceedings of BCS Displays Group International Conference on Visualizationand Modelling.

[37] J. Wood, H. Wright, and K. Brodlie. Improving visualization through collaboration.In Proceedings of Eurographics Workshop on Scientific Visualization, Chia.

[38] J. Wood, H. Wright, and K. Brodlie. Collaborative visualization. Proceedings of IEEEVisualization Conference, pages pp 253–260, 1997.

[39] H. Wright, K. Brodlie, J. Wood, and J. Proctor. Problem Solving Environments:Extending the Role of Visualization Systems, volume Vol. 1900, pages pages 1323–1331.Springer-Verlag, 2000.

[40] H. Wright, K. W. Brodlie, and M. J. Brown. The Dataflow Visualization Pipeline asa Problem Solving Environment, pages pp 267 – 276. Springer-Verlag, Wien and NewYork, 1996.

[41] D.A. Yuen, Z.A. Garbow, and G. Erlebacher. Reamote data analysis, visualizationand problem solving environment(pse) based on wavelets in the geosciences. VisualGeosciences, 2003.

58

VITA

Dhananjay Mishra was born on March 1, 1979 in Patna, India. He received his un-

dergraduate degree in Mathematics and Computing from Indian Institute of Technology,

Kharagpur in 2001, and proceeded to Virginia Tech for graduate study. He will be gradu-

ating with a Master of Science degree in Computer Science in April 2004.

59

Documents

Integration of Graphical User Interface and Data ...1.1.2 WCDMA Simulation Model A ray tracing propagation model predicts the impulse response of a wireless channel. However, propagation