Post on 19-Mar-2020
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
CHAPTER 1. INTRODUCTION AND OVERVIEW
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
CHAPTER 1. INTRODUCTION AND OVERVIEW
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
CHAPTER 1. INTRODUCTION AND OVERVIEW
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
CHAPTER 1. INTRODUCTION AND OVERVIEW
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
CHAPTER 1. INTRODUCTION AND OVERVIEW
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
CHAPTER 2. RELATED WORK
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
CHAPTER 2. RELATED WORK
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
CHAPTER 2. RELATED WORK
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 3. THE S4W GRAPHICAL USER INTERFACE
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
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
((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>
- <!-- end of file -->
36
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
Figure 4.11: Visualization of power coverage on the environment map. Intensity of color isproportional to the power level.
42
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 4. VISUALIZATIONS FOR S4W
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
CHAPTER 5. COMPARISONS AND CONCLUSIONS
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
CHAPTER 5. COMPARISONS AND CONCLUSIONS
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
CHAPTER 5. COMPARISONS AND CONCLUSIONS
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
CHAPTER 6. LESSONS LEARNT FROM THE EXPERIENCE OF S4W
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
CHAPTER 6. LESSONS LEARNT FROM THE EXPERIENCE OF S4W
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
CHAPTER 6. LESSONS LEARNT FROM THE EXPERIENCE OF S4W
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