The Component-based Environment for Remote ... - PARL FTP Server

The Component-based Environment for Remote Sensing 12 Nathan A. DeBardeleben 864-656-7223 [email protected]

Walter B. Ligon III 864-656-1224 [email protected] Parallel Architecture Research Lab Department of Electrical and Computer Engineering Clemson University 105 Riggs Hall Clemson, SC 29634-0915 http://www.parl.clemson.edu

Abstract— As the quality and accuracy of remote sensing instruments available improves, the ability to quickly process remotely sensed data is in increasing demand. A side effect of this increased quality and accuracy is a tremendous increase in the amount of computational power required by modern remote sensing applications.

Dan C. Stanzione Jr. 864-656-7367 [email protected]

For users to take advantage of this data to perform their research or utilize the fruits of previous research, they must be provided with software tools. These tools must deal with the issues inherent in the growing data requirements. How to store and how to process the data are two such issues. The problems facing the remote sensing community are:

In this work, a problem solving environment for parallel computing named the Component-based Environment for Remote Sensing (CERSe) is proposed. CERSe’s runtime engine and graphical user interface are presented. Performance results with and without use of a parallel file system are given which show near linear speedup can be achieved through I/O tuning. TABLE OF C ONTENTS 1. 2. 3. 4. 5.

I NTRODUCTION R ELATED W ORK CERS E P ERFORMANCE R ESULTS C ONCLUSIONS AND F UTURE W ORK

1.

I NTRODUCTION

There is growing number of people who want to use remotely sensed satellite data and Geographic Information Systems (GIS) data. The different applications that users want to run require increasing amounts of temporal, spectral, and spatial resolution. Some users, for instance, are satisfied with a single image a day, while others require many images an hour. Scientists are beginning to take advantage of multi-spectral datasets obtained from satellites which, in many cases, have over 100 different spectral bands present. Also, there is growing interest in combining large numbers of datasets from different satellites taken at different times of the day of different geographical locations and at different spotsize resolutions [1]. 1 0-7803-7231-X/01/$10.00/ 2002 c 2 IEEEAC

IEEE paper #402, Updated Sept 24, 2001

• a diversifying user base requires lower cost solutions, • increasing amounts of temporal, spectral, and spatial resolution requires massive data storage and processing power (parallel computers), • parallel computers are difficult to program, • users are required to have expertise in many application domains, • researchers are re-engineering hardware and software tools rather than building off of existing code or reusing code from other projects, and • rapid code development, execution, analysis, and maintenance remains of major importance. In most remote sensing and satellite telemetry applications there are three main phases: the initial setup phase, the main computation phase, and the result fusion stage. The first phase involves setting up the data to be operated on. Next, the essential algorithms and computations are performed during the second phase. Finally, result data is combined together during the final phase. This combining of data often takes the form of overlaying, compositing, or mosaicing (such as taking the minimum, average, or maximum value). A great deal of coarse-grain parallelism is often found during the main computation phase and only the phases which require fusing data back together need to be performed sequentially. Beowulf clusters are large computers comprised of commodity off-the-shelf (COTS) hardware components such as cheap

memory, EIDE disks, inexpensive networks, and conventional CPUs. The software (including operating system) is low cost / no cost and parallel programming libraries and tools are available for development of user code. Due to the hardware organization, many problems (such as coarse-grain problems) perform well on Beowulfs and these machines show a beneficial cost-to-performance ratio over conventional supercomputers. A cluster also has the potential to provide balanced I/O, unlike many MPPs, since each node in the cluster can have its own I/O subsystem and disk. Parallel file systems for clusters can stripe data among the nodes of a cluster so that potential bandwidth is increased and network bottlenecks are minimized. Therefore, a Beowulf cluster provides accessibility to many classes of users, large high-performance data storage, and a fast processing system. Therefore, our approach targets this class of machines. For more information on Beowulf clusters, see [2]. Unfortunately, those who want to use existing remote sensing software tools must still have significant expertise not only in remote sensing, but also in numerical models, satellite telemetry, sensor calibration, applied mathematics, multiple arcane computer systems and languages, and parallel computing. The requirements are often so extreme that only a select few have the background to use the tools. Remote sensing scientists very often cannot program supercomputers. Atmospheric chemists have similar problems but also are not experts in satellite calibration and telemetry. Computer scientists are unfamiliar with the earth science as well as issues of calibration and telemetry. Finally, the non-scientist is often without background in any of the requirements and cannot use the tools at all. In the past, satellites and software tools to process the satellite’s data were often redesigned by every group interested in taking advantage of satellite data. Clearly, major disadvantages exist in the need to re-engineer hardware and software tools such as wasted time and lost money. One of NASA’s current goals is to shift from developing highly specific sensor platforms for a small research community to developing more general purpose sensor platforms for a wider range of users. Data can then be supplied to the researchers for study. As the user base continues to diversify, multi-million dollar investments are no longer feasible and organizations like NASA have recognized this. In the past decade or two they have begun launching general-purpose satellites which acquire data. This data can then be used by people with completely different research interests or goals. Smaller research groups, laboratories, or scientists who in the past could not have used this data for lack of funding are acquiring it now. We propose the design of a problem solving environment (PSE) which meets the needs of the remote sensing community by providing high performance, ease of use, and extensibility. This environment must

• Provide a mechanism for code reuse, • Run on parallel computers, • Be usable without advanced knowledge of parallel architecture or parallel algorithms, and • Provide tools which facilitate fast algorithm development and data analysis (such as a graphical environment, data selection tools, and performance analysis agents). We discuss a problem solving environment aimed at achieving these goals. This system accomplishes the goals of extensibility and code reuse through the use of interconnected components, or modules, to design algorithms. These modules consist of reusable blocks of code which are run in parallel on a parallel computer. Issues dealing with how to achieve the parallelism, passing data between modules, and synchronization are hidden from the user. We provide tools to address usability such as graphical dataflow editors, data visualization, data selection tools, and tools to constrain the region of interest. In the next section we discuss some related work in the component-based problem solving environment field. We then outline the design of a problem solving environment aimed at meeting the goals of the remote sensing community. We conclude with performance results and discuss both computational and I/O speedup.

2.

R ELATED W ORK

The Common Component Architecture [3] is a framework for defining the interaction between components. The CCA also provides services which the components can use. The scientific interface definition language (SIDL) is used to define component inputs and outputs. The CCA is a joint partnership between numerous Department of Energy national laboratories and academic institutions. The CCA Forum [4] is a place where interested parties can discuss new concepts and vote on CCA standards. Unlike many component standards, the CCA standard focuses on high performance computing. Khoros [5] is a commercial software package for modular program development on sequential computers. With Khoros, users lay glyphs onto a canvas and connect them together to form the dataflow. Each glyph is a seperate program and dataflow is handled by an underlying file system. Output from a glyph is written to a file and another glyph reads this file in as input. Cactus [6] is a multi-national project with support from the National Center for Supercomputer Applications (NCSA) and several Department of Energy laboratories. Cactus defines the interaction between components (thorns) and the driver (flesh). Users develop their programs in Fortan or C and write driver files in a metalanguage. Astrophysics, gridbased applications are the target problem domain but effort is

being made to expand this focus. Cactus runs on many different kinds of parallel machines such as Beowulf clusters, commercial supercomputers, and many research machines. Particular attention is being paid by the Cactus team on support for Globus and the computational grid. The Open Source Software Image Map (OSSIM) [7], is developed by the open source community and maintained by a group working for ImageLinks, a company in Florida. OSSIM aims to leverage existing open source tools in the remote sensing community to construct an integrated tool. OSSIM partitions datasets into tiles which are passed down an image chain. Different algorithms are performed along this image chain to form the application. While little support for parallelism is currently present, the OSSIM team intends to have full support for high performance parallel computers.

3.

CERS E

The Component-based Environment for Remote Sensing (CERSe) [8] is a problem solving environment that provides algorithm creation and execution facilities. CERSe has three major components, each with several subcomponents: • Runtime Driver – Tagged Partition Handle (TPH) - data structure for keeping related pieces of data together and facilitating easy exchange of data between modules. – Module Loader - dynamically loads the needed modules from the module library and hands them to the Program Sequencer. – Program Sequencer - runs on each slave processor which executes the dataflow algorithm by calling the loaded modules and passing the TPH. – Memory Manager - partitions datasets and creates TPHs which are enqueued on the least loaded slave node. – Mosaic-er - fuses intermediate result data into final results. • GUI Client – Graph Editor - a graphical component which assists in module and dataflow graph creation as well as data visualization, and miscellaneous tools that provide usability. – Code Generator - generates the source program and parameter file from a dataflow graph of modules. • Module Library – Module Library - collection of modules which can be used to create dataflow algorithms. Figure 1 depicts these components and their interactions.

Runtime Driver At its core CERSe is an execution engine for programs expressed as a dataflow graph. Nodes within the graph can be replaced to specify specific processing details. A key portion of the graph describes the processing algorithm used to produce the desired output data products. The flow template contains a subgraph (called the parallel subgraph) which defines the module dependencies of the core algorithms. The subgraph is executed in parallel over partitions of the input datasets. Thus, most of the algorithm processing codes can be written without specific consideration of the parallelism. Most remote sensing algorithms lend themselves very well to this model of interconnected components and dataflow between components. A CERSe program is a series of modules placed in a sequential order for execution. Multiple instances of the CERSe program run in parallel on the nodes of a parallel computer. Input datasets are divided into partitions each of which is processed by a different instance of the CERSe program. In Figure 1 the white columns marked P 1 . . . P N represent the instances of the CERSe program executing on each processor by the Program Sequencer. CERSe requires two source files to run a job: a source language program and a parameter file. The source program lists the modules, their order of execution, and the dataflow. The parameter file contains all necessary extras such as working directory names and parameters for visualization. These source files are copied to the host parallel computer and processed by the CERSe driver. The graphical user interface automatically generates these files from the dataflow graph created by the user. When a CERSe job is initiated, the driver first initializes the Module Loader which dynamically loads the modules to be used. The modules are sequential C-language functions with special macros compiled into shared objects. These loaded modules are then handed to the Program Sequencer which runs on each slave machine in the cluster. The Program Sequencer executes each loaded module sequentially over a partition of the dataset being processed. The Program Sequencer uses the dataflow graph and its own type of program counter to keep track of the sequence of modules to execute. A special data structure called a Tagged Partition Handle (TPH) is used for passing data between modules and keeping related pieces of data together. Through the TPH, modules process input data and allocate output buffers. The interface to the TPH seen by the module programmer and is handled through several helper functions. Based on knowledge of the data dependencies available through the source program file, the TPH can make intelligent decisions about garbage collection. Once each module in the dataflow graph is executed by the Program Sequencer the results are obtained for a portion of

Input Datasets RUNTIME DRIVER

Memory Manager TPH CLIENT Graph Editor

interaction TPH Queues

...

Parameter File Code Generator Source Program

Program Sequencer

Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 ... Step N

TPH

TPH

TPH

... ...

...

... Output

P1’s Memory Processors (1,2,...,N)

P1

P2’s Memory

P2

...

PN’s Memory

PN Mosaic−er

...... Module Loader MODULE LIBRARY

Figure 1: Diagram of CERSe the dataset. These results are sent to the Mosaic-er where they are fused together with other results. This fusing operation can take on whatever form the scientist requires. Examples include averaging the values, choosing the maximum or minimum, or performing a class discrimination algorithm. The Mosaic-er holds the composite results in memory until all datasets have been processed. Additionally, the Mosaic-er communicates with the graphical interface to provide updated output of the current composite results. Once all dataset partitions have been processed, the result can be written to storage for later analysis. After a dataset partition (represented as a single TPH) has been passed through the parallel subgraph on a processor the TPH queue is checked. If additional TPHs are enqueued then the next is dequeued and processing of that dataset partition begins. If no TPHs are available, the program sequencer can communicate with other program sequencers running on the other processors and transfer enqueued TPHs from another queue to its own. In this way, a form of load balancing is present. This process repeats until all dataset partitions on all processors have been used by the Program Sequencers.

Achieving Parallelism One of the main goals of CERSe is alleviating the need the for the earth scientist to understand parallel computing. The scientists present their algorithms as modular components (like function calls) which are executed concurrently by a parallel machine. The input datasets are partitioned and the user coded, sequential algorithms are executed over a single dataset partition on a single processor. This occurs in parallel with other dataset partitions and continues to occur until all partitions of all input datasets have been handled. Since the datasets generally are large (on the order of 100 - 1,000MB), and the typical application uses many datasets, this type of scheme provides a good deal of fairly coarse-grain data parallelism. Once the user-specified modules have been executed over a dataset partition the results must be handled. Many solutions require fusing the individual results together into a single, composite result. Modules are provided which perform this fusing task and can be edited to serve the specific need of an application. The partitioning and fusing of datasets are the only modules which require some understanding of parallel computing to code. CERSe provides sample partitioning and fusing modules, but if specific needs are required then these can be modified or replaced with alternate modules. These modules are

considered driver-level and are executed on the master processor only. The Memory Manager runs the partitioning module and the Mosaic-er handles the fusing module. MPICH [9], an implementation of Message Passing Interface (MPI) standard [10, 11] is used for parallel communication within CERSe. All MPI calls are performed by the CERSe driver and users need no understanding of MPI to take advantage of the parallelism provided by CERSe. Advanced users are able use MPI within their own modules to perform specialized parallelism if necessary.

The GUI Client CERSe provides a graphical interface which addresses usability. This GUI provides an environment for designing CERSe modules, developing dataflow graphs, assigning execution parameters, issuing jobs, analyzing performance, and visualization of results (intermediate and final). Facilities are provided for development of modules and dataflow programs. Additionally, visualization of output is provided by establishing a connection to the output of the Mosaic-er running on the parallel machine. The GUI includes colormap applicators and generators for better visualization. The GUI client drives the code generator. When the user initiates a CERSe job, the dataflow graph is used along with additional parameters to generate the source program and parameter file. These are then copied to the parallel machine and the driver is initiated. The CERSe GUI Client is built upon the CECAAD [12] framework, a toolkit for building problem solving environments. The CERSe dataflow graph is represented using the open graph format provided by CECAAD, and the CECAAD agent model provides the infrastructure to allow the various tools provided by the GUI to interact with each other, with the CERSe code generator, and with the runtime engine.

tial orderings. One of these orderings is chosen by the code generator during the generation phase. Additional graphical tools are provided which assist in setting up the parameters for a job run. Figure 3 allows the user select a region of interest and translates the selection into latitude and longitude coordinates. This region of interest is then used in conjuction with a relational database to select datasets which fall within the region. Figure 4 allows the user to refine the selection further through selection of satellite, year, month, day, hour, and minute. These selections are passed as a query to the database and the datasets which pass the criteria are returned. Figure 5 lists these datasets with specific information about each, such as the date it was received and the region (in coordinates) it covers. The tool also calculates the percent of the dataset that falls within the bounding box. This is useful as many datasets will reside in part within the user-selected region of interest but may only provide a small amount of data within that region.

Module Library CERSe modules consist of pieces of source code which process input data and produce output data. The source modules are compiled into shared library objects. They are placed into the Module Library where they used to create CERSe programs. These modules are later dynamically loaded by the Module Loader at runtime. Through the use dynamic loading, the environment can be halted, modules can be loaded or unloaded and then the job can be continued. All inputs and outputs to and from modules go through the TPH data structure. Helper functions are provided which make learning to use TPHs simple.

Figure 2 is a screenshot of the dataflow graph editor. The graph shown is a common remote sensing algorithm which uses different channels of AVHRR data, calibrates them, performs a vegetation index, masks out clouds, and projects the results to a common coordinate system. Each node in Figure 2 is a CERSe module and has an associated piece of source code implemented in either C, C++, or Fortran. The source can be edited by clicking on the .src button on the node. The source modules can be copied from group repositories or maintained in a user’s personal work space. Upon job execution, the source files cooresponding to the modules are copied to the host machine, compiled, and placed into the Module Library for loading by the Module Loader. Dataflow is represented by directed lines between modules. The shown dataflow graph can be represented as a dependency graph. This gives way to a number of valid sequen-

Figure 3: Latitude / Longitude Selector

Figure 2: Dataflow Graph Editor Example An example of a module is one that calculates the satellite zenith angle for each pixel in an AVHRR satellite image. This example shows the process of taking existing (legacy) code and incorporating it within CERSe. Figure 6 depicts the module code to calculate the satellite zenith angle for each pixel over each scan line partitioned to the module through the TPH.

Figure 4: Database Dataset Selector

Figure 5: Database Datasets Matching Query

The sections highlighted are those that were added to the legacy code to make a CERSe module. Figure 6, section A includes the CERSe header file which is needed for the relevant data structures and macros. Additionally it sets up the function pointer which will be loaded dynamically by the module loader. The second highlighted section, B, defines the interface to the module. Each component of the interface has three parts: a textual description of the component, the data type, and what type of component it is (input, output, inout, or parameter). Sections A and B can be automatically generated from the GUI representation together with the definitions in section C and need not be written by a user. The third highlighted area, C, shows the methods for accessing the TPH and either retrieving the necessary inputs or allocating the outputs. The final highlighted section, D, uses as a loop bound the number of scanlines that are associated with this particular TPH. A short description of the code follows.

Figure 6: Satellite Zenith Angle Calculation Module

The beginning of the satzenith function uses three calls to CERSe helper functions. These functions retrieve the requested data from the TPH transparently. The CERSe OUTPUT function allocates an array of floating point values and assigns the pointer to the local name satzens. Some constant values pertaining to the maximum scan angle and the radius of the earth are also defined. Recognizing that the earth is not a sphere, as this code assumes, one could readily implement code which calculates the earth radius for particular scan lines. Finally, there are two loops which iterate over the scan lines given to a particular processor. These loops are where the parallelism occurs since each processor operates on only a portion of the total number of scan lines. As this module is executed by the Program Sequencer on each slave node the TPH will contain data relevant only to a portion of a dataset. We achieve a great deal of data parallelism with this method. The satellite zenith angle is calculated for each point in these loops. These values are placed into the satzens data structure which was allocated by the call to CERSe OUTPUT as an array of float values and is now present in the TPH. This array is now available in the TPH for other modules to use as input.

Tests of CERSe were also run using PVFS [14, 15], a parallel file system for Beowulf clusters developed at the Parallel Architecture Research Laboratory at Clemson University. PVFS stripes data across the disks in a Beowulf cluster like a RAID. In the first set of tests all of the processors used performed both computation and I/O. Thus, when less than the maximum number of processors was used, the unused nodes were not used as I/O nodes. The datasets were partitioned along scanline boundaries and the default PVFS stripe size of 64KB was used initially. The second PVFS test case involved using four dedicated I/O nodes and varying numbers of compute nodes. Again, the default PVFS stripe size was used. These tests show the speedup due to I/O. As can be seen from the plot, PVFS incurs considerable overhead, but exhibits reasonably good scalability. As the number of processors increases beyond six, however, we find that the speedup when using PVFS decreases due to the file system being overloaded. The tests using dedicated I/O nodes suggest that I/O tuning can have beneficial effects. We further believe that a balance exists between stripe size and the size of partitions that are distributed out to each processor. The configuration of the file system can have a significant impact on both overhead and scalability and we are currently working to improve the interaction between PVFS and CERSe.

The code in Figure 6 that is not highlighted came from existing, non-modular, NASA remote sensing tools.

5. 4.

P ERFORMANCE R ESULTS

For our performance tests we used CERSe to create a common remote sensing application. This application computes the Normalized Difference Vegetation Index [13], masks clouds, and projects the output to a common coordinate system. Sequential remote sensing code exists which performs these algorithms and was used in speedup analysis. In an effort to distinguish speedup attributed to computation versus I/O, three sets of tests of CERSe were run on a dedicated cluster of computers. The cluster consisted of eight nodes connected by Fast Ethernet. Each node had 64MB of RAM, 80GB of disk space, and a 300MHz Pentium II processor. For the first series of tests no parallel file system was used. In these tests all the datasets consumed by CERSe were available on the local disks of each of the compute nodes in the cluster. Therefore, the data was replicated eight times. This kept all I/O accesses local and shows the computational speedup of CERSe without effects of I/O. Figure 7 shows the speedup curve for this simulation. It can be seen that using only local data provides very good speedup. This is to be expected as the problem is naturally parallel. A clear drawback of this simulation, however, is that it requires all the data to be replicated on all of the local disks within the cluster. With the massive amounts of data currently available and the increasing volume of new data this solution is not practical. To deal with this problem we incorporated parallel I/O.

C ONCLUSIONS AND F UTURE W ORK

The remote sensing community faces a number of challenges which are addressed by CERSe. The problem solving environment presented allows for existing remote sensing code and new algorithms to be written in a modular framework which can be executed on a parallel computer. Advanced understanding of parallel computing has been abstracted away from the user. Parallel computing is essential for handling the increasing amounts of data due to growing temporal, spectral, and spatial resolutions. CERSe is designed to provide high performance computing, extensibility, and usability for remote sensing problems. An environment for modular code development and easy pluggability of modules is provided. This environment makes it easy to both incorporate existing, legacy software as well as develop new algorithms. A graphical interface addresses usability by providing tools for dataflow graph creation, data visualization, and additional functionality specific to remote sensing problems such as specification of region of interest, choosing map projections, and database connectivity. Performance results show that near ideal computational speedup is achieved by CERSe. I/O tuning is still an issue and research is currently underway to address this. Additional research has begun to develop a more generalized environment for use in other realms of science in engineering. This environment focuses on performance through asynchronous I/O, computation, and communication while still abstracting these concepts away from the scientist.

Speedup vs. Num. Processors 8

7

6

S

5

4

3

2 Ideal Local Data Access PVFS Data Access PVFS Data Access With 4 Dedicated I/O Nodes 1 1

2

3

4

5

6

7

8

P

Figure 7: Speedup for Varying Number of Compute Nodes Using Local Data Access

ACKNOWLEDGMENTS

[6] E. Seidel, “Cactus,” IEEE Computational Science & Engineering, 1999.

This work was supported in part by NASA grant NAG5-8605 and by the ERC Program of the National Science Foundation under Award Number EEC-9731680.

[7] K. Melero, “Open Source Software Image Map Documentation.” http://www.ossim.org, 2001.

R EFERENCES

[8] N. A. DeBardeleben, “The Component-based Environment for Remote Sensing,” Master’s thesis, Clemson University, 2001.

[1] M. Halem, F. Shaffer, N. Palm, E. Salmon, S. Raghavar, and L. Kempster, “Can We Avoid A Data Survivability Crisis?,” Tech. Rep. 51, National Aeronautics and Space Administration, 1999. [2] T. Sterling, Beowulf Cluster Computing with Linux. The MIT Press, 2001. [3] R. Armstrong, D. Gannon, A. Geist, K. Keahey, S. Kohn, L. McInnes, S. Parker, and B. Smolinski, “Toward a Common Component Architecture for HighPerformance Scientific Computing,” in Proceedings of the 1999 Conference on High Performance Distributed Computing, 1999. [4] “Common Component Architecture http://www.acl.lanl.gov/cca-forum, 2001.

Forum.”

[5] J. Rasure and S. Kubica, The Khoros Application Development Environment. Khoral Research Inc., Albuquerque, New Mexico, 1992.

[9] W. Gropp, E. Lusk, N. Doss, and A. Skjellum, “A highperformance, portable implementation of the MPI message passing interface standard,” Parallel Computing, vol. 22, pp. 789–828, Sept. 1996. [10] MPI Forum, “MPI: A message passing interface standard, version 1.1,” tech. rep., University of Tennessee, 1995. [11] MPI Forum, “MPI-2: Extensions to the message passing interface,” tech. rep., University of Tennessee, 1997. [12] D. C. Stanzione Jr. and W. B. Ligon III, “Infrastructure for High Performance Computer Systems,” in IPDPS 2000 Workshops, LNCS 1800 (e. a. Jose Rolim, ed.), pp. 314–323, ACM/IEEE, Springer-Verlag, May 2000. [13] A. P. Cracknell, The Advanced Very High Resolution Radiometer. Taylor and Francis, 1997.

[14] R. Ross and W. Ligon III, “An Overview of the Parallel Virtual Filesystem,” in Proceedings of the 1999 Extreme Linux Workshop, 1999 June. [15] P. Carns, W. Ligon III, R. Ross, and R. Thakur, “PVFS: A Parallel File System For Linux Clusters,” in Proceedings of the 4th Annual Linux Showcase and Conference, October 2000.

Nathan DeBardeleben is a Ph. D. candidate in Computer Engineering at Clemson University. He received his Computer Engineering B.S. and M.S. from Clemson in 1998 and 2001 respectively. His research interests include problem solving environments for highperformance computing systems, remote sensing, and software engineering.

Walter Ligon received his Ph. D. in Computer Science from the Georgia Institute of Technology in 1992. Since then he has been at Clemson University where he is an Associate Professor in the Holcombe Department of Electrical and Computer Engineering. His current research interests are in parallel and distributed systems, I/O for parallel systems, reconfigurable computing,and problem solving environments.

Dan Stanzione, Jr. is a visiting assistant professor in the Electrical and Computer Engineering department at Clemson University. He received his B.S. in Electrical Engineering in 1991, and his M.S. and PhD in Computer Engineering in 1993 and 2000, all from Clemson. Dan’s research interests include reconfigurable computing, remote sensing, and problem solving environments for highperformance computing systems.