
\section{\bf Introduction}

Development of large applications is a complex process, and assistance
of adequate tools is always very welcome. Not surprisingly, there are
numerous commercially available tools for this purpose. These days 
visual debuggers, profilers, data analysis and visualization packages
are integral parts  of the developer environments on scientist's and
engineer's workstations.

The situation is different for the high performance, parallel or
distributed architectures. The performance tuning, debugging and data
analysis is more difficult, and yet the tools are not widely
available. One also face a problem of software integration, as
different software components often follow different parallel
programming paradigms.

On the other hand, we witness a rapid progress of Web based
technologies that are inherently distributed, heterogeneous, and
platform independent.  Of a particular interest are definition and
standardization of interfaces that enable cross-platform software
interoperability.  As an example of such new standards let us mention JDBC that
provides a common interface for a remote data base access.
We note that this software integration
is achieved by using interpreted scripts, with Java emerging as an
industry standard for this purpose.

In this report we describe a system that borrows ideas from these web
technologies. Using interpreted protocols implemented in Java we
interactively control execution of parallel programs written in HPF.
In particular, this technique provides us a real time access to data
generated by these codes. The data can be then used as an input for a
debugger or visualization package. More, the coupling between the
running application and the controlling it Java server allows for a
``duplex'' (bi-directional) communication, and therefore the system can
be used as a software integration tool.

\section {\bf The Model}

\begin{figure}[htbp]
\centerline{\psfig{figure=arch.eps,width=5.0in,height=5.0in}}
\caption{\sf General structure and Control Flow of Software
Architecture with Client-Server Model .}
\label{fig:architecture}
\end{figure}

The architecture of the system is shown in fig. 1. The heart of it is 
the HPF server which controls the execution of the HPF
application and processes requests from the clients.
The server is implemented in C, and is a part of an
instrumented HPF code. Consequently, it is active only after the HPF
application is launched. The client that allows the user to connect
with the server is implemented as a Java Applet.

After instrumenting the code, the user connects to the HTTP server on
the server host to submit the code for execution (a CGI script). The
HPF server gets initialized; it pauses the execution of the
application and waits till the client gets connected to it.
After the execution of
application is resumed, the server polls for user's requests
after each HPF statement. 

TCP/IP sockets are used for exchange XDR encoded data
between the client and the HPF server.    

\section {\bf Data Analysis and Visualizations}

The simplest application of the system is data analysis and
visualizations. To this end, the user requests the data at any point
during the execution of the code.  The requested data are sent to the
client to be displayed using Java AWT methods. The data can be
filtered on either server (performance) and/or client (data analysis)
side. When the request is placed inside a loop, the user is allowed to
specify the frequency of the data transfer ("send the data every k-th
iteration"). Once the data are sent, the server automatically resumes
execution of the application.

User can benefit from computational steering commands which allow him
to alter the the parameters of the simulation on the fly and
immediately receive feedback on the effect. 

\section {\bf HPF Debugger}

For debugging purposes, it is desirable that when the execution of the
code is interrupted, the server keeps accepting user's requests 
until an explicit command to resume is issued. Our prototype
implementation supports the following debugger commands:
  
\begin {itemize}
  \item {\bf DISPLAY} the value of the variable
  \item {\bf SET} breakpoint
  \item {\bf DELETE} breakpoint
  \item {\bf STEPOVER} (execute a single HPF statement; take
              function/subroutine call as a single statement)
  \item {\bf STEPINTO} (execute a single HPF statement)
  \item {\bf NSTEPOVER} (execute N steps in the STEPOVER mode)
  \item {\bf NSTEPINTO} (execute N steps in the STEPINTO mode)
  \item {\bf GOUNTIL} (continue till the specified logical expression is true)
  \item {\bf NITERATION} (execute N iteration of the current loop)
  \item {\bf CONTINUE} (continue execution till next breakpoint)
  \item {\bf RUN} (execute till completion of the code)
  \item {\bf STOP}(stop execution of the program )
  \item {\bf PAUSE} execution
\end {itemize}

The use of client/server architecture to implement a portable debugger
for distributetd systems in not a new idea (for example, see [5]). Our
approach is unique (c.f. [1-6]) is that we use a preprocessor for an
automatic code instrumentation (see Sec. 6), and that we use Java to
implement the debugger's front-end (GUI). We can easily integrate the
debugger with the visualization tool (Sect. 3) and and the HPF
interpreter (Sect. 5) to provide capability for manipulation of large
data sets (e.g., multidimensional, distributed arrays) to create a
powerful application development environment.

\section {\bf HPF Interpreter as a Dynamic Software Integration Tool}

So far we discussed a passive access to the data for debugging and
visualization purposes. The architecture of the proposed system
allows also for a real time interaction with an executing HPF code. 
At each synchronization point (when the HPF server is accepting
requests), the data can be extracted and processed as if an explicit
call to an HPF extrinsic procedure was made. In particular, HPF
statements can be executed in such an interactive fashion. This way
the system would get functionality of an HPF interpreter. 

The visualization and debugger capability of the system are in fact 
implemented as the HPF sequential extrinsics.  The HPF interpreter
would make use of the HPF local extrinsics and use directly
distributed data, as mapped by the HPF code. The interprocessor
communication between local (node) code would be facilitated by 
a generic message passing library, such as MPI, a high level
communication library, such as PCRC compiler runtime support, or 
a native HPF runtime support (HPF precompiled modules). 

The performance of the HPF interpreter implemented this way would be
necessarily poor as compared to a compiled, fully optimized HPF code.
The unique feature of our system is that it allows for dynamical
switching on and off the interpreter mode. In situations where
interactivity is more important than the high performance (debugging,
data analysis, prototyping) the interpreter is a very valuable
addition to the HPF compilation/runtime systems.

Going beyond the model of a classical interpreter that processes the
source code one statement at a time, we plan to use our HPF
interpreter as a software integration tool for a high performance, 
multidisciplinary computations. Here we envision invoking in the
interpreted mode execution not of single HPF statements but complete, 
precompiled library routines or even complete applications. In this
approach the role of the interpreter is shifted to enforce
interoperability of various runtime systems and computational modules
implemented using different parallel programming paradigms. The
components of such a multidisciplinary application would be controlled
by a precompiled driver, taking advantage of the HPF/Fortran 90 
expressiveness.  

\section {\bf Instrumentation of the HPF application} 

The instrumentation of the code involves three steps: 
\begin {enumerate}
\item  adding the server functions (implemented as a HPF extrinsics)
\item insertion calls to the HPF server before each HPF statement
\item identification of types of all variables used in the application
\end  {enumerate}

The process is fully automated and it requires no user
intervention. The instrumentation is done by a preprocessor that
transforms a valid HPF source code into the instrumented one. The
instrumented code is a valid HPF code itself to be compiled by a
generic HPF compiler. 

The preprocessor must have capability to parse HPF codes. Therefore we
built it using the HPF Front End (HPFfe) developed at NPAC (Syracuse 
University) \cite{HPFfe}. HPFfe is based on the SAGE++ system
\cite{Sage}, 
which in
addition to  parsing, provides means
to access and modify the abstract parse tree (AST), the symbol table,
the type tables, and source-level program annotations. For our
purposes, we developed functions that identify attributes of all
variables used in the HPF application (including the data type and
runtime memory addresses) and operates on the AST to insert variables'
``registration'' calls (allowing the server to determine the size
and location of the data to be sent) and calls to the server.

Capability of the HPFfe to parse C++ codes will make it possible to
use our system to integration of parallel codes written in HPF and
parallel C++.

\section {Summary}
The integration of compiled and interpreted HPF gives us an
opportunity to design a powerful application development environment
targeted to high performance, parallel and distributed
systems. Capability to alternate between compiled and interpreted mode
provides means for interaction with the code at real time while
preserving
acceptable performance. An interactive access to the data allows us to
implement a debugger, data vizualisation and analysis tools. 
Thanks to interpreted interfaces, typical for the Web technologies, we
can use our system as a software integration tool as well.


  