%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
\chapter{Introduction}

\section{Software System for the Integration of Real-Time Simulations
and Virtual Environments} 

Simulations--both parallel and distributed--are playing an increasingly
important role in all areas of science and engineering. With the
tremendous growth in the speed and architecture of parallel computers,
today we have the ability to run many of these simulations in
real-time. As the applications for these simulations expand, the demand
for their flexibility and utility grows. Interactive computational
steering is one way to increase the utility of these high-performance
simulations, as they facilitate the process of scientific discovery by
allowing the scientists to interact with their data. On yet another
front, the rapidly increasing power of computers and hardware rendering
systems has motivated the creation of visually rich and perceptually
realistic virtual environment (VE) applications. The combination of the two
provides one of the most realistic and powerful simulation tools available
to the scientific community.

National Aeronautics and Space Administration (NASA) scientists predict
that by the year 2022, three times as many people will travel by air as
they do today~\cite{nasascientists}. To keep the number of new airports
and runways to a minimum, there is an urgent need to increase their
efficiency while reducing the aircraft accident rate. Moreover, according
to the predictions by the United States Federal Aviation Administration
(FAA), by the year 2015, if the U.S. air transportation system does
not change in any significant way, there could be a major aviation
accident every seven to ten days. To greatly reduce the likelihood
of this disturbing scenario, the FAA has declared that the existing
Air-Traffic Control (ATC) system will shift to a new system soon, and
is seriously evaluating the likelihood of having a VE based system to
assist the ATC in its tasks.

This work attempts to create a general software system to integrate
Virtual Reality (VR) with real-time numerical simulations for Aerospace
applications, specifically ATC. As a particular case of the general
software system, this work aims at creating a wake-vortex hazard
avoidance system by realistically simulating an airport with real-time
visualization of the predicted wake-vortices generated by the moving
aircraft. If implemented, such a system has the potential to greatly
increase the utilization of airports while reducing the risks
of possible accidents. Aircraft will be able to adjust their flight
trajectory based on the information obtained from this VE system to
avoid the wake-vortices and operate more safely and efficiently. This
work also attempts to carry out a simulation of aircraft noise at
various points at and around the airport, thus giving an additional cue
to the ATC to determine new flight paths without increasing the noise
levels. Since the wake-vortex prediction for an entire fleet of
aircraft taking-off and landing at a busy airport is a computationally
intensive problem, a parallel solution for the same is proposed. The
output from the parallel code will then be sent to the VE system
via a computational steering framework.

\section{Applications}

\subsection{Wake-Vortex Hazards}
% http://europa.eu.int/comm/research/growth/gcc/in-action-vortex.html

Just as a moving boat or a ship leaves behind a wake in the water,
an aircraft leaves behind a wake in the air. The aircraft wake is generated
from the wings of the aircraft and consists of two counter-rotating
swirling rolls of air (as shown in Figure~\ref{fig:vortex}) which are
termed as the ``wake-vortex'' or ``wake-vortices''. These wake-vortex
pairs stretch for several miles behind the aircraft and may last for
several minutes. The strength of these vortices depends on several
factors, prominent amongst which are the weight, size and speed of
the aircraft. The strength generally increases with the weight of the
aircraft. The life of the vortex depends on the prevailing weather
conditions. Typically, vortices last longer in calm air and shorter in
the presence of atmospheric turbulence.

\myfigureW{figs/vortex.ps}{vortex}{12cm}
{B-727 vortex study photo (Courtesy: NASA Dryden Flight Research Center)}

Study of these vortices is very important for aircraft
safety~\cite{wake1, wake2, vortexhazard1}. The rapid swirling of air
in a vortex can have a potentially fatal effect on the stability of a
following aircraft. Past incidents and tests have repeatedly shown that
even a commercial aircraft can be thrown out of control if it follows
too close behind a large aircraft such as the Boeing 747. What makes the
problem worse is that these wake-vortices are normally invisible and
the pilots have no way to find out if they are heading into one. The
infamous US Air 427 (Boeing 737) disaster which occurred on September 8,
1997 is attributed to this phenomenon, wherein the aircraft encountered
the wake-vortices of a preceding Boeing 727~\cite{disaster1}. For this
reason, the International Civil Aviation Organization (ICAO) lays down
strict rules about the permitted spacing between aircraft, based on
their size. In instrument flying conditions, aircraft may follow no
closer than three nautical miles, and a small aircraft must follow
at least six nautical miles behind a heavy jet such as a Boeing 747.
These separations are extremely conservative; while they do not always
completely avoid the effects of wake-vortices, they are sufficient
to be safe in most meteorological conditions.

Nearly all airline pilots will have had encounters with vortices,
usually on the final approach to airports. They are experienced as a
buffeting of the aircraft. While of little concern to passengers and
crew who are wearing seat belts at this stage, pilots regularly report
minor injuries to crew members who are standing up or moving around the
cabin. However, the conservative ICAO regulations on aircraft spacing
have greatly reduced the risk of serious accidents, but they come at
the cost of reduced airport capacity. The spacing between aircraft is
very conservative to compensate for the incompetency in the accurate
prediction of the strength and the position of the wake-vortices, and is
often several times more than the actual safety limit, thus reducing the
number of take-offs and landings that can occur every hour.

%\subsection{Aircraft VOrtex Spacing System (AVOSS)}

To tackle this problem of reduced airport capacity, which is becoming
increasingly important, the NASA researchers have designed a system to
predict aircraft wake-vortices on final approach, so that the
aircraft can be spaced more safely and efficiently. This technology is
termed AVOSS or Aircraft VOrtex Spacing System (AVOSS)~\cite{avoss1}.

AVOSS determines how winds and other atmospheric conditions affect
the wake-vortex patterns of different types of aircraft. The system
uses laser radar, or lidar technology, to confirm the accuracy of
these forecasts. This information is processed by computers, which can
then provide safe spacing criteria automatically. The AVOSS concept
integrates the output from a number of subsystems such as the weather,
wake prediction, and wake sensors (Figure~\ref{fig:avoss}). Weather
gear at the airport measures the prevailing winds, temperatures
and turbulence levels aloft. The equipment also makes short term
predictions of potential weather changes. AVOSS then establishes an
invisible aircraft approach corridor with multiple wake prediction
windows. This information is fed into the wake prediction subsystem
which predicts the time it will take for wake-vortices to decay or drift
away from the flight path.
The prediction subsystem calculates spacing criteria and potential
runway capacity. It then provides appropriate aircraft separation
distances for the next 30 minutes. The system then predicts the time
it will take for the wakes to clear the corridor at multiple windows. The
most conservative time is taken as the final spacing time. The end
result is thus automatic and is considered accurate, safe and efficient
for the air-traffic controllers. 

\myfigureW{figs/avoss.ps}{avoss}{13cm}
{AVOSS subsystem architecture~\cite{avoss2}}

AVOSS is being extensively tested at the Dallas/Fort Worth (DFW) airport
since 1997. Further details and developments on AVOSS can be found
in references~\cite{avoss2,avoss3,avoss4,avoss5}.

AVOSS, in spite of carrying out a rigorous simulation of the
wake-vortices, does not implement any system for their visualization. It
only provides the ATC with the aircraft spacing time for each aircraft
which is all the current ATC systems can handle. Thus, at present, it is
unable to provide alternate trajectories for the take-off and landing of
aircraft.

%Write about Terminal Area Simulation System (TASS) here~\cite{tass1,tass2}.

\subsection{Aircraft Noise}

Aircraft noise has been a quality of life issue near airports for many
years. Even though the absolute single event noise levels have decreased
with the introduction of newer and quieter aircraft, aircraft fleet
noise impact will continue to constrain the growth of air travel as the
public expectation is for lower community noise impact. Many airports
in the U.S. are facing strong public resistance to adding new runways
or changing air-traffic flight paths. However, the demand for the goods
and services provided by our air transportation system is also very
strong. FAA projections show a 3-5\% increase in air travel per year over
the foreseeable future. Until objectionable aircraft noise is contained
within airport boundaries through successful implementation of advanced
noise reduction technology, noise from subsonic airplanes will continue
to be an issue resulting in the reliance on constraining mitigation
polices and procedures, such as curfews and noise budgets, for noise impact
relief.

Mani-Gliebe-Balsa theory (MGBK)~\cite{mgb} is a computer program that
predicts the mixing noise and the shock noise generated by a subsonic
or low-supersonic jet, given input data on the mean flow and turbulence
fields as predicted by a suitable state-of-the-art computational fluid
dynamics (CFD) program~\cite{jetnoise}. MGBK is an updated version
of a noise-prediction program, called ``MGB'', developed during the
1970s. MGBK predicts only the noise generated in the part of a jet plume
external to the exit plane of the nozzle of a jet engine. Using such a
noise prediction code opens another possibility for controlling aircraft
noise by planning the airport and its operation based on the information
obtained from its predictions.

%The MGB/MGBK code is well-suited to giving noise contours
%More stuff on aircraft noise here. Search for Sound MGB code.....sound
%contours on the airport ground.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
\chapter{Integrated Virtual Environments}

This chapter discusses the basics of Virtual Reality, and describes
the various hardware and software available to create an Integrated
Virtual Environment. Air-Traffic Control is also discussed here as a
potential Integrated Virtual Environment of the future.

\section{Virtual Reality}

\subsection{Definition}

Virtual reality (VR) represents a human-computer interface (HCI)
technology that is designed to leverage our natural human capabilities.
Today's familiar interfaces--the keyboard, mouse, monitor, and the
graphical user interface (GUI)--force us to adapt to working within
tight, unnatural, two-dimensional constraints. VR changes that by
allowing the user to interact with real-time 3D graphics in a more
intuitive and natural manner. This approach enhances our ability to
understand, analyze, create and communicate. VR is a way for humans to
visualize, manipulate and interact with computers and extremely complex
data. 

However, the term ``Virtual Reality'' is often considered to be a
misnomer since it happens to be an oxymoron. Other terms like Virtual
Environments (VE), Synthetic Environments, Artificial Reality, Simulator
Technology, etc. are also used for it.

A VR system that interactively simulates a particular environment
or scenario in real-time is termed as an ``Integrated Virtual
Environment'' (IVE). An IVE lets the user experience the data
directly. It generates an interactive simulation by providing the user a
graphics representation of a virtual environment via an output device.
Today's advanced interfaces let the user look and move around inside a
virtual environment, drive through it, lift items, hear sounds, feel
objects, and in other ways experience graphical objects and scenes much
as one might experience objects and places in the physical world. As
a result, VR serves as a problem-solving tool that lets us accomplish
what was previously deemed impossible. It is also a new medium of
communication, and ultimately, an artistic tool.

Wickens and Baker~\cite{wickens} have defined VR as incorporating
the following five features:
\begin{enumerate}
\item Three-dimensional (perspective and/or stereoscopic) viewing.

\item Dynamic display (rather than static images).

\item Closed loop (interactive or learner-centered design, where the user
is the active navigator as well as the observer).

\item Inside-out (ego-referenced) frame of reference. The image of the
virtual environment displayed is from the point of view of the user's
head as it is positioned in the world.

\item Multimodal interaction (via several input techniques and feedback
through several sensory modalities).

\end{enumerate}

\subsection{Classification of VR}

A major distinction of VR systems is the mode with which they
interface to the user. Some of the common modes used in VR systems
are~\cite{vrtypes}:

\begin{itemize}

\item {\bf Desktop VR} or {\bf Window on World Systems (WoW)}:
Some systems use a conventional computer monitor to display the
visual world. This is sometimes called ``Desktop VR'' or a ``Window on a
World'' (WoW). This concept traces its lineage back through the entire
history of computer graphics. In 1965, Ivan Sutherland laid out a
research program for computer graphics in a paper called ``The Ultimate
Display''~\cite{sutherland65} that has driven the field for the past
three decades.

\item {\bf Video Mapping}:
A variation of the WoW approach merges a video input of the user's
silhouette with a 2D/3D computer graphic. The user watches a monitor that
shows his body's interaction with the world. This concept is used
in popular arcade games such as Doom, Quake, etc.

\item {\bf Immersive Systems}:
The ultimate VR systems completely immerse the user's personal viewpoint
inside the virtual world. These {\em immersive} VR systems are often
equipped with a Head Mounted Display (HMD). This is a helmet or a face
mask that holds the visual and auditory displays. The helmet may be
free ranging, tethered, or it might be attached to some sort of a boom
armature. A nice variation of the immersive systems use multiple large
projection displays to create a ``cave'' or room in which the viewer
stands.

\item {\bf Telepresence}:
Telepresence is a variation on visualizing complete computer generated
worlds. This technology links remote sensors in the real world with
the senses of a human operator. The remote sensors might be located on
a robot. Fire fighters use remotely operated vehicles to handle some
dangerous conditions. Surgeons are using very small instruments on
cables to do surgery without cutting a major hole in their patients.
The instruments have a small video camera at the business end. Robots
equipped with telepresence systems have already changed the way deep
sea and volcanic exploration is done. NASA plans to use telerobotics
for space exploration. There is currently a joint US/Russian project
researching telepresence for space rover exploration.

\item {\bf Augmented/Mixed Reality}:
Merging the Telepresence and Virtual Reality systems gives the Mixed
Reality or Seamless Simulation systems. Here the computer generated
inputs are merged with telepresence inputs and/or the users view of the
real world. A surgeon's view of a brain surgery is overlaid with images
from earlier CAT scans and real-time ultrasound. A fighter pilot sees
computer generated maps and data displays inside his fancy helmet visor
or on cockpit displays.

\item {\bf Fish Tank Virtual Reality}:
The most pervasive display ``fixture'' is the conventional computer
monitor which can be augmented to view stereoscopic, three dimensional
environments as well as the more traditional interfaces. Such an
immersive effect obtained by using a pair of stereographic LCD shutter
glasses attached to a mechanical head tracker to look at the display
on the monitor is referred to as ``fish-tank'' VR, as it is analogous
to looking through the screen into another environment. The resulting
system is superior to simple stereo-WoW systems due to the motion
parallax effects introduced by the head tracker. However, because of its
limited field of view and poor sense of immersion, it has been generally
ignored by most Virtual Reality researchers.

\end{itemize}

Since VR has become such a vast field today, one can go on talking about
it with no end in sight. References~\cite{vrbook1} and~\cite{vrbook2}
discuss the various intricacies and applications related to VR.

\section{VR Hardware}

\subsection{CAVE}

The CAVE (Cave Automatic Virtual Environment) is currently the most
popular, as well as sophisticated, VR installation for scientific and
artistic projects. It was developed in 1992 by a team headed by Tom
DeFanti and Dan Sandin at the Electronic Visualization Laboratory (EVL)
of the University of Illinois, Chicago~\cite{cave1,cave2} and is now
being produced commercially by FakeSpace Systems~\cite{fakespace}.

CAVE is a projection-based VR system that surrounds the viewer with
4 screens. The screens are arranged in a cube made up of three
rear-projection screens for walls and a down-projection screen for the
floor; that is, a projector overhead points to a mirror, which reflects
the images onto the floor. A viewer wears stereo shutter glasses and
a six-degrees-of-freedom head-tracking device. As the viewer
moves inside the CAVE, the correct stereoscopic perspective
projections are calculated for each wall. A second sensor and
buttons in a wand held by the viewer provide interaction with the
virtual environment. A diagram of the CAVE environment is shown in
Figure~\ref{fig:cavediagram}. A screenshot depicting a 4-walled CAVE in
use is shown in Figure~\ref{fig:cave}. The CAVE has been used for wide
variety of applications, some of them being architectural walkthroughs,
cosmic exploration, fractal exploration, viewing the behavior of
algorithms implemented on parallel machines, and understanding weather
and molecular dynamics~\cite{cave3}.

\myfigureW{figs/cavediagram.ps}{cavediagram}{13cm}
{CAVE diagram}

\myfigureW{figs/cavesnapshot1.ps}{cave}{10cm}
{Screenshot of a CAVE application (Courtesy: SARA, Netherlands)}

RAVE (Reconfigurable Automatic Virtual Environment) and Immersadesk are
toned down and cheaper alternatives to the CAVE. RAVE can consist of one to
four projected screens, whereas Immersadesk has a single projected
screen. HMDs, once very popular devices for VR, are now losing ground to
sophisticated displays like RAVEs and CAVEs.

\subsection{Input Devices}

There are a plethora of input and tracking hardware devices available
for VR systems these days. Most can be added to an existing VR
installation like a CAVE or a RAVE very easily. Various motion trackers,
gloves, wands, 6D Spaceballs, force/haptic feedback device and 3D
digitizers are just a few examples of these devices.

\section{VR Software}

Owing to the complexity of VR and the various hardware devices involved
in their creating, specialized software packages and Application
Programming Interfaces (APIs) are essential to make the development of
VR applications easier.

\subsection{CAVELib}

The CAVELib is an API that provides general support for building
virtual environments for various types of immersive displays.
The CAVELib forms a building block used to create applications for a
variety of virtual environments. The CAVELib API provides functions
that can be used by programmers to create robust programs for virtual
display devices or desktops. CAVELib was originally developed by Dave
Pape of EVL, University of Illinois, and is now marketed commercially by
VRCO~\cite{cavelib}.

The CAVELib configures the display device, synchronizes processes,
draws stereoscopic views, creates a viewer-centered perspective and
provides basic networking between remote Virtual Environments. The
CAVELib allows a single program to be available on a wide variety of
virtual display devices without rewriting or recompiling. It uses a
resource configuration file that can be modified to change display and
input devices, making the programs written on the CAVELib portable to a
wide-variety of display devices. It automatically generates the right
viewing frustum for each wall and applies it to the scene. It also
converts the coordinates from the tracking system (world coordinates) to
the coordinate system of the 3D scene. Also, the CAVELib uses threads
to obtain simple parallelization in the calculation process by using
one process for the generation of the projection for each wall and the
other for getting data from the tracking device. The CAVELib provides
an API to control all its functions, which are mainly the query for the
tracking system and the input devices. All distributions of CAVELibs
are capable of running in simulator mode. The simulator uses the
keyboard and mouse to simulate head and wand movement, in a non-stereo
display on a workstation monitor. The simulator is a great means for
application development and testing using a workstation, without
requiring the use of the VR device.

\subsection{OpenGL}

The CAVELib by itself does not incorporate any functions for the
actual graphics programming. To generate the actual graphics seen in
the VR display, a separate graphics API like OpenGL~\cite{opengl}
needs to be used. OpenGL is the premier environment for developing
portable, interactive 2D and 3D graphics applications. Since its
introduction in 1992 by Silicon Graphics Inc. (SGI), OpenGL has become
the industry's most widely used and supported 2D and 3D graphics API,
bringing thousands of applications to a wide variety of computer
platforms. OpenGL fosters innovation and speeds application development
by incorporating a broad set of rendering, texture mapping, special
effects, and other powerful visualization functions. Owing to the
standardization of OpenGL, developers can leverage the power of
OpenGL across all popular desktop and workstation platforms, ensuring
wide application deployment. Among the drawbacks, OpenGL is not
object-oriented and is not scene-graph based. With the combination of
OpenGL and CAVELib, it is possible to create powerful VR applications
in the CAVE environment. The CAVELib does most of the configuration and
initialization tasks while the OpenGL handles the display function.
Mason et al.~\cite{openGLbook} is a very popular book to learn OpenGL
programming.

VR Juggler~\cite{vrjuggler}, being developed by the Iowa State
University, is another API similar to the CAVELib (albeit open-source).

\subsection{Other High-level Software}

While CAVELib and OpenGL provide the basic functionality for the
development of VR applications, they are usually not sufficient. They
lack important software components like one for {\em hierarchical
scenegraph rendering}, which is necessary for efficient rendering of
complex scenes commonly found in most VR applications. SGI's IRIS
Performer is an OpenGL-based scenegraph rendering library and is being
extensively used for creating VR applications. However, a big limitation
of using Performer is that it only works under IRIX (SGI's proprietary
operating system) and Linux operating systems.

There are also several high-level software development systems available
for building high-performance, real-time, integrated 3D applications
for scientific and commercial use, some of them being: WorldToolKit,
MR Toolkit, dVISE and DIVE. WorldToolKit (WTK) by Sense8
Corporation~\cite{sense8} is the most popular amongst them all.
WorldToolKit has the function library and end-user productivity tools
needed to create, manage, and commercialize VR applications. With the
high-level API, the programmer can quickly prototype, develop, and
reconfigure the applications as required. WorldToolKit also supports
network-based distributed simulations, CAVE-like immersive display
options, and the industry's largest array of interface devices, such
as HMDs, trackers, and navigation controllers. The system started
out as a 3D modeling and simulation package in 1990, but has now
matured into a full-fledged VR development toolkit. WorldToolKit is an
object-oriented toolkit that greatly simplifies programming of visual
simulation and virtual reality by offering a powerful, object-oriented,
C/C++ programmer's interface. WorldToolKit contains more than $1,100$
high-level function calls for developing, configuring, and controlling
real-time 3D simulations. WorldToolKit is unique in that it provides a
truly cross-platform development and delivery capability. WorldToolKit
automatically optimizes graphics performance based on functions unique
to each platform, to maximize the graphics hardware performance.
WorldToolKit also integrates all of the essential elements, including
high-performance graphics, intuitive interface components, 2D or
spatialized 3D sound, support for multiple database and media formats,
and a comprehensive list of input/output peripherals. The system is
available for a wide range of platforms running UNIX, and has a large
and growing user base. All the above-mentioned toolkits work in
conjunction with OpenGL for rendering the graphics.

CAVERNsoft (CAVE Research Network software)~\cite{cavernsoft} is a
toolkit for creating high-performance tele-immersive applications,
being developed by EVL, the inventors of CAVE. CAVERNsoft is designed
to enable the rapid construction of tele-immersive applications and
to equip previously single-user applications with tele-immersive
capabilities. It provides networking and database functionality
needed in a virtual reality system. CAVERNSoft toolkit allows
scientists to steer a program from a virtual reality system without
requiring any modification to the program. It enables interactive
and immersive analysis of simulations running on remote computers.
CAVEStudy~\cite{o_steering2} is another toolkit built on top of
CAVERNSoft which allows interactive and immersive analysis of a
simulation running on a remote computer. However, both CAVERNSoft and
CAVEStudy depend on Performer for rendering, and are hence limited to
SGI IRIX and Linux platforms.

\section{Air-Traffic Control (ATC)}

By the year 2015, if the U.S. air transportation system does not change
in any significant way, there could be a major aviation accident every
seven to ten days based on the Federal Aviation Administration (FAA)
projections depicted in Table~\ref{table:faaprojection}. Air-traffic
control related delays already cost the airline industry an estimated
US \$5.5 billion annually. The FAA has for the past two decades been
scrambling to replace, modernize, and improve the ATC.

\begin{table}[h!]
\centerline{
\begin{tabular}{|c|c|c|c|c|} \hline
{\bf Year}&{\bf Passengers}&{\bf Passenger Miles}&{\bf Jet Aircraft}&{\bf Domestic Departures} \\ 
{\bf }&{\bf  (Millions)}&{\bf (Billions)}&{\bf in Fleet}&{\bf (Millions)} \\ \hline
2000 & 639.8 & 661.8 & 5610 & 7.4 \\ \hline
2005 & 767.4 & 830.3 & 6903 & 8.6 \\ \hline
2010 & 931.1 & 1041.6 & 8360 & 9.9 \\ \hline
2015 & 1139.7 & 1306.2 & 10034 & 11.5 \\ \hline
\end{tabular}}
\caption{Commercial Air Carriers FY 1999-2010 (Source: FAA~\cite{faa})}
\label{table:faaprojection}
\end{table}

The U.S. air-traffic control system is organized around three types
of facilities: {\em airport towers}, which monitor aircraft on the
ground and give take-off and landing clearances; {\em terminal
radar approach control (TRACON) facilities}, which handle aircraft
ascending and descending to and from airports; and {\em enroute
centers}, which handle aircraft flying between airports at the higher
altitudes~\cite{atc1}. ATC is a highly demanding human-machine system.
With the rapid progress in real-time processing of speech and images,
together with database management, an intelligent system combining
satellite navigation, automated speech synthesis and recognition is
expected to be introduced to replace some human functions in the
foreseeable future~\cite{atc2}. The next logical step for the ATC would
be to transform itself into an Integrated Virtual Environment which
simulates a complete airport.

The FAA has declared that the existing ATC system will transition to
a new system known as ``Free Flight''. While ``Free Flight'' has not
been precisely defined in a way that is universally accepted, the basic
concept is to reduce the centralized control in the existing system to
allow pilots greater freedom in choosing and altering routes, leading
to reduced costs and increased capacity. In today's system, controllers
issue commands and pilots follow them. Pilots wishing to change their
routes must issue requests and receive clearance from controllers. The
control and responsibility for safe operation is centralized in the
controllers. In contrast, ``Free Flight'' will allow pilots to change their
routes in real-time, with controllers intervening only when necessary
to ensure adequate separation. In some definitions of Free Flight,
pilots themselves are responsible for avoiding conflicts in simple
situations~\cite{atc3}. Azuma et al.~\cite{atc3,atc4,atc5} have worked
extensively on advanced human-computer interfaces and visualization
tools to assist in the ``Free Flight'' air-traffic management. They
have created a VR based tested using C and WorldToolKit 7 for the
visualization of conflicts that may occur in a ``Free Flight'' scenario.
While their work may look similar to a part of the proposed work in this
dissertation, the fact that they do not deal with any vortex-wake
problem whatsoever, makes it actually different.

To facilitate this and to ease the pressure on the ATC, NASA has also
been working with a team of seven industry partners to help develop
the ``highway in the sky'' (HITS) system~\cite{nasa_HITS}. With this
system, pilots will follow a preprogrammed destination on a ``virtual
highway'' in the sky, drawn on a highly intuitive, low-cost flat panel
display. This display might even be a part of the cockpit window,
thus augmenting the real display seen through the glass with the
computer-generated path superimposing it. In addition to transforming
the cockpits, the technology developed by the team will redefine the
relationship between pilots and the ATC and fundamentally change the
way future general aviation pilots fly. This technology is expected to
significantly increase freedom, safety and ease-of-flying by providing
pilots with affordable, direct access to information needed for future
``Free Flight'' air-traffic control systems. Pilots will have the
ability to safely determine their routes, speeds and proximity to
dangerous weather, terrain and other airplanes. This display system
and other equipment will provide intuitive situational awareness
and enough information for a pilot to perform safely, with reduced
workload, in nearly all weather conditions. A multifunction display of
position navigation, terrain map, weather and air-traffic information is
expected, in addition to the digital radios which will send and receive
flight data in real-time.

NASA's FutureFlight Central~\cite{futureflight} is a national ATC
test facility dedicated to solving the present and emerging capacity
problems of the nation's airports. Designed in collaboration with
the Air Transportation Association (ATA), FAA, National Air-Traffic
Controllers Association (NATCA) and Supervisors Committee (SUPCOM),
NASA FutureFlight Central is operated and managed by NASA personnel,
including experts in ATC, computer graphics, human factors and
large-scale simulations. The two-storey facility is an Integrated
Virtual Environment offering a 360-degree full-scale real-time
simulation of an airport (Figure~\ref{fig:futureflight}), where
controllers, pilots and airport personnel can interact to optimize
operating procedures and test out new technologies.

\myfigureW{figs/futureflight.ps}{futureflight}{12cm}
{NASA FutureFlight Central's tower cab~\cite{futureflight}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
\chapter{Simulation Approaches}

\section{Parallel Computing and Beowulf Clusters}

Parallel Computing is a strategy for performing large, complex tasks
faster. A large task can either be performed serially, one step
following another, or can be decomposed into smaller tasks to be
performed simultaneously, i.e., in parallel. Thus, the terminology
``Parallel Computing'' refers to the use of multiple computers or
processors working together on a common task. 

Parallel computing paradigms fall into two broad classes: {\it
functional decomposition} and {\it domain decomposition}. These
classes reflect how a problem is allocated to processes. Functional
decomposition divides a problem into several distinct tasks that
may be executed in parallel; one field where this is popular today
is that of Multidisciplinary Design Optimization. On the other
hand, domain decomposition distributes data across processes, with
each process performing more or less the same operations on the
data. Domain decomposition is to be distinguished from the Single
Instruction Multiple Data (SIMD) model in Flynn's taxonomy of computer
architectures~\cite{flynn}: in the SIMD model, each process executes
the same instructions at the machine level, i.e., all processes proceed
in lockstep, doing exactly the same operations on different data. This
kind of parallelism (sometimes called fine-grain parallelism) is usually
found at the loop level, whereas domain decomposition is applied at
the problem level. In the {\it Single Program Multiple Data} (SPMD)
parallelism, the same code is replicated to each process. One
process acts as the master and collects the results from all other
processes, thus doing slightly more work than the other processes.
Each processor works on its section of the problem and is allowed to
exchange information (data in local memory) with other processors.

There are several reasons for the use of parallel computing over the
conventional single processor computation. Single processor computers
have a limited amount of memory and cannot process data faster than
their rated speed (which is also limited by the current semiconductor
technology). Parallel computing not only allows us to solve problems
that do not fit on a single processor machine, but is also capable of
obtaining the solution in a reasonable amount of time (dependant on the
size of the problem and the number of processors employed). One can thus
run larger problems than were previously possible and obtain solutions
much quicker.

Parallelism can be achieved by:
\begin{itemize}
\item Breaking up the task into smaller tasks 

\item Assigning the smaller tasks to multiple workers to work on
simultaneously

\item Coordinating the workers 
\end{itemize}

Traditionally, programs that have been written for serial computers
execute only one instruction at a time, use one processor, and
process instructions dependent on how fast data can move through
hardware. The fastest processors today execute approximately $1.5$ billion
instructions per second. One might think that this is fast enough, but
there are several classes of problems that require faster processing
such as various Simulation and Modeling problems, problems dependent on
computations/manipulations of large amounts of data, and Grand Challenge
problems such as Climate Modeling, Fluid Turbulence, Human Genome, etc.
Computers that support parallel computing are broadly referred to
as High Performance Computing (HPC) systems.

\subsection{Beowulf Clusters}

The Beowulf cluster is a multi-computer architecture which can be used for 
parallel computations. The word ``Beowulf'' was borrowed from one of
the earliest surviving epic poems written in English, which tells
the story about a hero (in this case the ``commodity computer'') of
great strength and courage who defeats a monster (in this case the
``existing supercomputers''). A typical Beowulf cluster consists of
one server node, and one or more client nodes connected together via
some network. A schematic of a typical Beowulf cluster is shown in
Figure~\ref{fig:beowulf}.

\myfigureW{figs/beowulf.ps}{beowulf}{10cm}
{Schematic of a typical Beowulf cluster}

The first Beowulf cluster was built by NASA in 1994~\cite{beowulf}
and consisted of $16$ 486DX4-100 MHz machines each with $16$ MB of
memory, which was the best available commodity hardware of the time.
Beowulf is a system built using commodity personal computers, standard
ethernet adapters, and switches. It does not contain any custom hardware
components and is trivially reproducible. Beowulf also uses commodity
software such as the Linux operating system~\cite{linux}, Parallel Virtual
Machine (PVM) and Message Passing Interface (MPI), and other widely
available open-source software. A Beowulf system behaves more like
a single machine rather than many workstations as the server node
controls the client nodes transparently. Today, the price-performance
(or dollars/MFLOPs) for these cheap clusters is far better (often
10 times or more) than for a typical supercomputer from IBM, SGI or
Hitachi, making them extremely attractive for small organizations and
research groups.

The COst effective COmputing Array (COCOA)~\cite{cocoa} is a Penn
State Department of Aerospace Engineering initiative to bring low cost
parallel computing to the departmental level. COCOA is a $50$-processor
cluster of off-the-shelf PCs connected via fast-ethernet ($100$
Mbit/sec). The PCs are running RedHat Linux with MPI for parallel
programming and DQS for queuing the jobs. Each node of COCOA consists
of Dual $400$ MHz Intel Pentium II Processors in SMP configuration and
$512$ MB of memory. A single Baynetworks $24$-port fast-ethernet switch
with a backplane bandwidth of $2.5$ Gbps was used for the networking.
The whole system cost approximately \$$100,000$ (1998 US dollars).
COCOA-2, a successor to COCOA was also recently built at the cost of \$
$60,000$, and is a $40$-processor rackmounted cluster (dual PIII-800s)
with 20 GB memory connected via two fast-ethernet adaptors (using Linux
channel bonding). Each of the clusters have 100 GB of usable disk space.
COCOA and COCOA-2 were built to enable the study of complex fluid
dynamics problems without depending on expensive external supercomputing
resources. To get even 50,000 hrs of CPU time in a supercomputing
center is difficult, while COCOA can offer more that 400,000 CPU hours
annually.

\subsection{Message Passing Interface (MPI)}

Message Passing Interface (MPI) is a specification for message passing
libraries, designed to be a standard for message passing in parallel
computing. Message passing is a paradigm used widely on certain classes
of parallel machines, especially those with distributed memory.
Although there are many variations, the basic concept of processes
communicating through messages is well understood. Over the last ten
years, substantial progress has been made in casting significant
applications in this paradigm and each vendor has implemented its
own variant. In 1994, an MPI standard was adopted which attempts to
establish a practical, portable, efficient, and flexible standard
for message passing~\cite{mpi}. The main advantages of having
a message-passing standard are portability and ease-of-use. In a
distributed memory communication environment in which the higher level
routines and/or abstractions are build upon lower level message passing
routines, the benefits of standardization are particularly apparent.
Furthermore, the definition of a message passing standard provides
vendors with a clearly defined base set of routines that they can
implement efficiently, or in some cases provide hardware support for,
thereby enhancing scalability.

There are several open-source MPI libraries available that run on
Beowulf clusters, the most prominent being MPI Chameleon (MPICH)
being developed by Argonne National Lab~\cite{mpich}, and the Local
Area Multicomputer MPI (LAM-MPI) being developed by the University of
Notre Dame~\cite{lammpi}. Most MPI libraries are written in ``C'',
and have C++ and FORTRAN 77/90 bindings. In a program using MPI, all
parallelism is explicit and the programmer is responsible for correctly
identifying parallelism and implementing the resulting algorithm using
MPI constructs (of the approximately 155 that are available). The number
of tasks dedicated to run a parallel program is static and new tasks
can not be dynamically spawned during run time. Pacheco's book on
MPI~\cite{mpibook} does a good job of teaching the reader how to write
parallel programs using MPI.

While there are several other parallel programming paradigms like
Parallel Virtual Machine (PVM), OpenMP, etc. available, they are not
very popular, and hence a discussion on them has been omitted for
the sake of brevity.

\section{Real-time Monitoring and Steering}

\subsection{Introduction}

While running a complex parallel program on a HPC system, one often
experiences several major difficulties in observing output. Usually,
the simulation severely limits the interaction with the program during
the execution and makes the visualization and monitoring slow and
cumbersome (if at all possible), especially if it needs to be carried
out on a different system (say a specialized system for visualization
like the RAVE). In the particular problem related to the simulation of
the wake-vortices, some of the questions that arise are:

\begin{itemize}
\item How do we get the location of the wake-vortices shed by each
aircraft for visualization on the RAVE in real-time while the parallel
program is running on a Beowulf Cluster?

\item How do we keep the simulation on the Beowulf Cluster updated about
the latest weather conditions and the changing trajectories of the
aircraft which can keep changing all the time?

\end{itemize}

These questions are of major importance to this research as the
predictions by the wake-vortex code need to be known in real-time for
the ATC to take appropriate action. This activity is referred to as
``monitoring'', which is defined as the observation of a program's
behaviour at specified intervals of time during its execution. On the
other hand, the weather conditions at the airport may keep changing
and both the number and the trajectories of the aircraft can change as
they take-off and land. Thus, there is a need to modify the simulation
based on these factors by manipulating some key characteristics of
its algorithm. This activity is referred to as ``steering'', which
is defined as the modification of a program's behaviour during its
execution. The above questions can thus be rephrased as ``How do we
monitor and steer our wake-vortex simulation?''.

Software tools which support these activities are called (computational)
steering environments. These environments typically operate in three
phases: instrumentation, monitoring, and steering. Instrumentation is
the phase where the application code is modified to add monitoring
functionality. Monitoring phase requires the program to run with some
initial input data, the output of which is observed by retrieving
important data about the program's state change. Analysis of this data
gives more knowledge about the program's activity. During the steering
phase, the user modifies the program's behavior (by modifying the input)
based on the knowledge gained during the previous phase by applying
steering commands, which are injected on-line, so that the application
need not be stopped and restarted.

\subsection{Previous Work}

A significant amount of work has been done on computational steering
over the past few years. Reitinger~\cite{steering5ms} provides a
brief review of this work in his thesis. Some of the well known
steering systems are {\em Falcon} from Georgia Tech~\cite{falcon,
vetter2}, {\em VASE} (Visualization and Application Steering) from
University of Illinois~\cite{steering6vase}, {\em SCIRun} from
Scientific Computing and Imaging research group at University of
Utah~\cite{steering4scirun}, {\em CUMULVS} from Oak Ridge National
Laboratory~\cite{steering7cumulvs}, {\em CSE} (Computational
Steering Environment) from Center of Mathematics and Computer
Science in Amsterdam~\cite{steering8cse}, and {\em Virtue} from
University of Illinois at Urbana-Champaign~\cite{vr3}. A summary of
the environment characteristics of these systems is shown in
Table~\ref{table:steering}.

\begin{table}[h!]
\centerline{\psfig {figure=figs/steeringtable.ps,angle=0,width=14cm}}
\caption{Summary of environment characteristics of existing steering systems~\cite{steering5ms}}
\label{table:steering}
\end{table}

Computational steering has also been attempted by coupling of
a 2-D solver with the VR environment by Carolina Cruz-Neira et
al~\cite{cosmicworm, cave3} at the EVL, UIC, in as early as 1993. They
worked on very simple simulations of Rayleigh-Taylor instability and
gravitational wave components predicted by Einstein's Theory of General
Relativity. The datasets were relatively small and calculations were
simplified by approximating theoretical algorithms and decreasing
rendering quality. The steering was implemented by providing a menu
to change input parameters of the simulation and then restarting
the simulation when a change was detected. The computation was done
simultaneously on a separate machine which was networked with the CAVE.
Parker et al. have several publications~\cite{o_steering1, o_steering3,
o_steering5} which discuss computational steering software systems
and strategies, and applications of their SCIRun system. Juler et
al.~\cite{vr8battlefield} have implemented a software architecture
called Dragon for real-time battlefield visualization. Taylor et
al.~\cite{vr2} have done some interesting work which explores the lag
time involved in interactive virtual reality applications.

\subsection{My Approach}

For the computational steering, an approach similar to that used in
{\em Falcon}~\cite{falcon,steering1,steering2,steering3} will be used.
{\em Falcon} is an on-line monitoring and steering toolkit for large
parallel programs. Falcon's on-line steering component consists of a
steering server on the target machine that performs steering, and a
steering client that provides the user interface and control facilities
remotely. The steering server is typically created as a separate
execution thread of the application to which local monitors forward only
those monitoring events that are of interest to steering activities.
The steering client receives the application run-time information
from the application, displays the information to the user, accepts
steering commands from the user, and enacts changes that affect the
application's execution. Communication between application and steering
client, and steering client and server, is handled by the transmission
tool, {\em Data Exchange}. Data Exchange is a transmission tool for
routing messages between multiple clients where clients can be broadly
classified as applications, visualization/analysis/steering tools, or
other {\em Data Exchanges}. Messages are identified by their format
names and registered with {\em Data Exchange} by both senders and
receivers. When a message is received, it is routed to those clients
who have registered their interest in receiving that message type.
Communication is done through UNIX sockets~\cite{socket}.

\section{Vortex-wake Hazards}

For the simulation of wake-vortex hazards, the real-time computational
steering method described in the previous section will be used. The
parallel numerical wake-vortex prediction code written in C++ and MPI
will be running on a remote Beowulf cluster and will be communicating
to the computational steering server using network sockets. RAVE from
FakeSpace Systems will be used as the display device. The RAVE will
be driven by an HP Visualize J-class workstation running the HP-UX
operating system.

\subsection{Wake-Vortex Theory}

Potential theory was used to predict values of the vortex detection
parameters. The entire circulation generated by the lift was assumed to
be contained without losses in two vortices of opposite signs trailing
from the tips of the wing. The wake was assumed to consist of a pair of
vortices which were parallel and the longitudinal axis of the detecting
airplane was assumed to be parallel to the vortex pair. The centers of
the vortices were on a horizontal line separated by a distance of $b_s
= \frac{\pi}{4} b_g$, a result of assuming an elliptic distribution,
where $b_s$ is the separation of the vortices in the wake-vortex
pair, and $b_g$ is the span of the airplane wing generating the wake
vortex~\cite{nvortex1}. The magnitude of the circulation of each vortex
is approximately:

$$ |\Gamma| = \frac{4}{\pi}\frac{L_g}{\rho V_g b_g} $$

where $L_g$ and $V_g$ are the lift and the velocity of the vortex
generating airplane, respectively. The tangential velocity component
$V_\theta$ due to each vortex is given by:

$$ V_\theta = \frac{|\Gamma|}{2 \pi r} $$

where $r$ is the radius from a vortex center to the position the
tangential velocity is calculated. References~\cite{tass1, tass2,
vortexsimulation} deal with more details on the numerical simulation
of these aircraft vortices.

After the strength of these vortices are computed, the effect due to the
prevailing weather data is applied to the prediction. The vortex
filaments propagate with the freestream wind conditions and decay
based on the turbulence present in the atmosphere.

\subsection{Problem Size and Other Complexities}

A typical metropolitan airport in the US is extremely busy with several
take-offs and landings occurring every few minutes. Dallas/Fort Worth
(D/FW), the country's third busiest airport, has seven runways that
handle nearly $2,300$ take-offs and landings every day. For the
wake-vortex code to track the vortices shed by an aircraft for $5$
miles after take-off, assuming that a vortex core is stored every
5 meters, $5 \times1600/5\times2=3200$ vortex filaments have to be
tracked. For $2,300$ take-offs and landings every day, it implies that
$3200\times2300/24=306667$ vortex filaments have to be
tracked every hour. Since, the average vortex does not decay before
15 minutes, vortices due to typically half the take-offs and landings
every hour need to be tracked at any given time. This amounts to
roughly $153,333$ vortex filaments. While this may not seem a very
large number on its own, the problem gets complicated by the presence of
a double loop for the calculation of the induced velocity of every
vortex on every other vortex. Even if the induced velocity effect due
to vortices from the other aircraft are ignored, this still amounts
to as much as $3200\times3200=10.24$ million computations for each
airplane at every timestep. For $2300$ planes/day, this comes out to
$10.24\times2300/24/2=490.7$ million calculations for the induced
velocity, a very large number indeed for a conventional uniprocessor
system. Hence, the code is parallelized to track vortex elements from
each aircraft on a different processor in such a way that we get an almost
real-time solution to this problem with tolerable lag.

Since the aircraft keep entering and leaving the airport, the
data-structure in the wake-vortex program should be able to account for
this. In order to achieve this, we use a doubly linked list to store
data related to each aircraft, which can be traversed from either
end and can delete any random element in linear time. Addition of an
aircraft to the list takes constant time since the new element is always
added to either the beginning or the end of the list. Also, a special
data-structure has to be maintained separately for the wake-vortices,
as the wake-vortices may remain in the simulation even after the
aircraft that generated it has gone far away from the vicinity of the
airport. The trajectory for each aircraft also needs to be continuously
specified using a network socket, since this data keeps changing and
will eventually be provided by the Global Positioning System (GPS) in
the aircraft.

The VR application will be written in C++ using OpenGL and GLUT (openGL
Utility Library) libraries on top of CAVELib. Sense8's WorldToolKit may
be used if it is available and works on our hardware. If this happens,
the application development time should be greatly reduced. A noise
prediction code would also be run simultaneously to generate the noise
levels around the plane due to its engines.

\section{Aircraft Noise}

For the simulation of aircraft/engine noise, a noise-prediction code
such as MGB/MGBK, or something similar, will be employed. As with the
wake-vortex hazard code, this code too will run on a separate cluster
and will send information regarding the noise levels from the aircraft
at specified points at and around the airport. This information
will then be used to plot noise contours on the ground of the
airport. An example of ground contours in the vicinity of 
the Minneapolis - St. Paul International Airport (MSP) is shown in
Figure~\ref{fig:noisecontours}.

\myfigureW{figs/noisecontours.ps}{noisecontours}{10cm}
{Noise contours (in decibels) shown around the Minneapolis - St. Paul
International Airport (MSP)}

%The MGB/MGBK code is well-suited to giving noise contours
%More stuff on aircraft noise here. Search for Sound MGB code.....sound
%contours on the airport ground.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
\chapter{Preliminary Results}

Ever since the topic for the dissertation was set in January 2001,
a reasonable amount of work has gone into the creation of
the proposed software system. 

A wake-vortex prediction code has been written in C++ using the Standard
Template Library (STL). STL provides optimized and highly efficient
implementations of the basic data structures such as dynamic vectors
and linked lists that are heavily used in this implementation. While
the wake-vortex prediction model is very basic, it seems to perform
adequately for the purpose of testing the entire system as a whole.
The wake-vortex prediction code is written as a separate library so
as not to interfere with the internals of the VR code. Eventually,
instrumentation will be added to this code, so that monitoring and
steering of the application can be carried on smoothly. Currently,
the aircraft trajectory is provided to the wake-vortex code as an
input file. In the final version, it will be obtained through a socket
connection from a remote destination.

A basic OpenGL-based visualization program to display the output
from the wake-vortex code has also been written. The program has
been successfully integrated with the wake-vortex library and
seems to work well on the RAVE system. A screenshot of the program
depicting three aircraft and their generated wakes is shown in
Figure~\ref{fig:screenshot}. To enable the use of the wand, head
tracking and stereo display, CAVELib support will soon be added to
the program. Work is also underway to develop more realistic looking
graphics by adding runways, control towers and buildings to the airport.

\myfigureW{figs/screenshot.ps}{screenshot}{14cm}
{Screenshot of the current Wake-Vortex simulation}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
\chapter{Timeline for Proposed Thesis}
\begin{itemize}

\item {\bf August 1997--May 1999}: Pursued my Master's degree in
Aerospace Engineering under Prof. Lyle N. Long, during which I worked on
my thesis titled ``Unsteady Separated Flow Simulations using a Cluster
of Workstations''. The thesis involved writing parallel programs in C
using MPI. I also built a Beowulf Cluster (COCOA) for the department. I
also obtained a minor in {\em High Performance Computing} (HPC) during
that period. Also took various courses in Parallel Computing (AE 597D),
Data Structures (CSE 465), Computer Vision (CSE 486), etc.

\item {\bf August 1999--December 1999}: Admitted in the CSE PhD program.
Took courses in Operating Systems (CSE 411), Programming Language
(CSE 428) and Computer Graphics (CSE 418) and prepared for my CSE PhD
candidacy. I learnt OpenGL programming in the Computer Graphics course.
Also worked on a rotorcraft-related research project.

\item {\bf January 14-17, 2000}: Passed the PhD candidacy exam.

\item {\bf January--May 2000}: Took the following courses: Database
Systems (CSE 541), Parallel Matrix Computations (CSE 557), and Digital
Image Processing II (CSE 585) to satisfy the course requirements.
Not much progress on the research front. Also finished the
miscellaneous PhD requirements such as Written English Test, Oral
Competency Test and Presentation Skills Test.

\item {\bf May--August 2000}: Did basic research in the field of
VR. Attended the CAC seminar on CAVE programming and prepared
myself for the forthcoming CAVE workshop.

\item {\bf August 15-17, 2000}: Attended the CAVE workshop at the University
of Michigan, Ann Arbor. Got a good exposure to the current research in
VR and met a few Who's Who in the field of VR. Got brief exposure
on CAVE programming and VR Juggler programming.

\item {\bf August--December 2000}: Started research on the PhD
topic ``Comparison of Computational and Experimental Data using
Computational Steering in a Virtual Environment''. Went through lots of
literature in computational steering, visualization and virtual reality.
Took the following courses: Interfaces to Virtual Environments (CSE
587), and Computer Networks (CSE 514), and CSE 590. Did a project on
``Building a Kiosk'' for the CSE 587 course which involved intensive
OpenGL programming.

\item {\bf January--April 2001}: The topic for my PhD research
underwent a change to its current state. I did intensive research
on the Wake-Vortex Hazard problem. Got an initial copy of the code
written in FORTRAN 90 which was completely rewritten in C++ using STL
and was made into a separate library. An OpenGL front-end for the
simulation of the wake-vortex code was written and demonstrated. Took
the final 2 credits of CSE 590 and got done with all my PhD course
requirements. Also built another Beowulf Cluster (COCOA-2) in February,
and helped set up the hardware and software in the RAVE room.

\item {\bf April 20, 2001}: PhD proposal and Comprehensive Exam.

\item {\bf June--August 2001}: Will work on adding CAVELib support.
Also plan to enhance the graphics and make the airport look more
realistic (possibly using WorldToolKit). Will also work on parallelizing
the wake-vortex code and instrumenting it to enable computational
steering. Will also be presenting a paper on ``Aeroacoustic and
Turbulent Flow Simulations using a Cluster of Workstations'' at the
Linux Revolution Conference to be held in University of Illinois at
Urbana-Champaign (UIUC) on June 26.

\item {\bf September--October 2001}: Complete the computational
steering of the wake-vortex portion and ensure that it works well
on the CAVE. Deal with all the complexities that arise in the
parallelization and steering of the code. Will also start on the aircraft
simulation problem.

\item {\bf November--December 2001}: Try to get the aircraft noise simulation
completed. Look for improvements and enhancements in the simulation.

\item {\bf January--February 2002}: Try to get realistic input for
the weather conditions, etc and simulate a busy US airport. Do some
analysis of the system and look for improvements.

\item {\bf March--April 2002}: Start writing the dissertation. Hope
to get done with 75\% of the work during this period.

\item {\bf May--June 2002}: Wrap up all the work, do final analysis
and finish the dissertation.

\item {\bf July 2002}: Final PhD defense.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
