\section{\bf Introduction}

We are proposing that Java can be used as an interface to a
Web-implemented High Performance Fortran simulation 
in order to do the visualization of its data and its debugging. 
We picked HPF as a representative
for parallel language. A lot of parallel software was written before
but we lack an easy-to-use interface trough which we can use these
parallel programs from any platform on Internet and control and make
some visualization of running parallel program interactively.
Java,combined with web browser
and other Web technologies, is an excellent resource for graphical
user interfaces(GUI) on any type of computer. User writes his GUI in
java and uses it on any platform. Also user doesn't have to login into its
account ,on which his parallel software is stored, to see and run his
application. With using our proposed architecture,
user can start his parallel application on any platform in Internet
from Web browser , do control-steering and debugging its execution, 
receive data from running
application directly and make visualization from this data .We see
this type of using java as a natural Web ``seed'' that can grow into
the more pervasive use of java \cite{Gcf}. Writing interfaces
for Java to connect to
already written software , or outside World is very recent new idea. 
We have already examples
of this type of using Java, JDBC kit which allows java programmers to
connect a data base server , query it or update it using the industry
standard query language. Another example is  (JNDI)
Java Naming \& Directory Interface which provides Java 
applications a unified interface to multiple
naming and directory services in the enterprise. Last example is 
Java IDL which provides a way for transparently connecting Java clients to
network servers using the industry standard IDL Interface Definition
language. In our work, we will just apply this idea in such a way that
we will get access ,control and visualize running parallel or
serial program (written before) interactively trough Java Applet.
  
User doesn't have to modify his original application to do these jobs.
We will talk about general structure and control flow of our software
architecture in Section 2 , instrumentation of HPF program in Section 3,
communication interface between Java Client(Applet) and HPF server in Section 4
, debugging and visualization of HPF program in Section 5 and 
interpretation of HPF statements in Section 6.
 

\section {\bf General structure and Control Flow of Integration of
High Performance Computing with Java Applet}


\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}

We will explain the general structure and control flow of our
software in the client-server model  in the figure(~\ref {fig:architecture}).
{\bf Web Browser} is a Java-enabled World Wide(WWW) Web Browser.{\bf
Java Applet} is a Java program that can be downloaded from the
Internet and run in any Web Browser.{\bf HTTP Server} is the public
domain apache server. {\bf HPF Server} is one running HPF application
which has instrumented HPF program code,including calls to server
function before each executable HPF statement. Actually the program points 
where these calls occurred are yield points where HPF Server can get
requests from Java Applets and and responses results
back. {\bf Server Host} is the any node of High Performance Parallel
Cluster on which HTTP Server and HPF Server are running. Other nodes
are shown as Node1-6. User also can connect to other Server Hosts,such
as Host A and B , at other parallel platforms. All the Java Applet
codes at different Server Hosts are same. We can say that HPF
application is source code of HPF Server and use interchangeably.

The execution flow is as the following. First user clicks the link to
HPF Server Home page at Server Host and WWW Browser loads the Java
Applet as Graphical User Interface(GUI) .
All the interactions between applet and
server are occurred in the server function.
We have to differentiate the
server function from HPF server and HTTP server. This function  is C 
function including code for receiving requests,processing them and
sending results back. 

Then user can look at the
available HPF applications at the Server Host by sending necessary
commands to HTTP Server and chose the original source code of anyone.
Then he has control over
when he send  the command to HTTP server to start HPF Server 
.After HPF server is initiated , user can send many
commands to it trough applet directly and gets results . 
After User starts its execution,
he can use known debugger commands which are sent to 
server automatically and watch the control flow (where the program
counter is ). Also user can ask  the value of any program variable and
evaluate any HPF expression in parallel . User can set the some
parameters to the value he gives from Java applet at any time during
execution .It is also possible
to give one boolean expression and continue to run until that
expression is true/false. If the execution control is in one loop,
user can also give the command `` Iterate this loop k times'' to the
server.
The one of the unique features of our work is interpretation of HPF
statetements at runtime dynamically. User will give the textual
representation of any valid HPF statement to HPF Server which
evaluates it without changing current environment and send result 
back to user who may visualize it
with Java AWT.
 
\section {\bf Instrumentation of HPF program}

We are instrumenting the user HPF program  using HPF
Front End (HPFfe) developed at NPAC \cite{HPFfe} before compiling it. 
As said in previous chapter, we are inserting some extrinsic functions
into suitable points in the program to lift some overhead over user.
The previous related works \cite{Hack} \cite{Falcon},\cite{Tuchman},
\cite{Cumulvs} and \cite{Vista} were
pressing on the user to instrument his program and insert some program
segments to use their visualization and control-steering tools. 
In our work, we benefit from available compiler infrastructure
technology on HPF \cite{HPFfe},to make
instrumentation of user HPF program automatically. 

The HPFfe,based on SAGE \cite{Sage}, contains parser for HPF in addition to
C++,F90 and F77 with one class library.
 This library provides a
means to access and restructure program tree ,symbol and type tables
and source-level program annotations.HPFfe provides an underlying
infrastructure on which all types of program preprocessors are built.

During multiple sending of same variable to Java applet each time we need
to know the some of its attributes ,such as data size and the runtime
memory address. Therefore,we wrote simple functions to traverse parse
tree to find the attributes for each defined variable and insert the
one function(register function) call ,
which takes these attributes as parameters and
store them in registration table,  before first executable statement
.After we stored attributes of variable, we can access them easily
next time. Also we are inserting server function call before each
executable statement. These two function,register and server function
are defined HPF extrinsics and just two representatives for 
instrumentation. Our transformation above is just from source to
source and don't change program semantics. Other types of restructuring
we did during transformation also is not changing semantics.
User doesn't
have to add anything to his HPF program  to make visualization of 
its data by using  our tool. Because HPFfe is extended from SAGE compiler p
preprocessor toolkit,our tool will easily be extended to support F90,C
and  C++ programs. 

\section {\bf Communication Interface between Java Client and HPF
server}

Communication between {\bf Java Client} and {\bf HPF Server} is done
with  TCP/IP sockets. In order to solve the problem of different data
representations of computer architectures, we used External Data
Representation(XDR) of SUN Microsystems \cite{XDR} such that {\bf HPF Server}
has to transform every data to XDR format before sending it to {\bf
HPF Client}. Fortunately, Java Language is storing the program data in XDR
format so that {Java Server} can understand the data coming from {\bf
HPF Server}, also sends data to HPF server in same format. 
This feature of Java Language will stimulate its heavily using
for connecting already written software  applications to running Java
Applet. Encoding of primitive data types and arrays  in XDR
format is handled in our related library functions, but for complex data
types such as F90 records ,we used {\bf rpcgen} tool of SUN  to generate
automatically the function which will transform the structured data to
XDR format. Using XDR will give the advantage of running HPF
application on any platform supporting XDR and connecting the
application with the Applet via Web browser.

\section {The Structure of Actual Server Function}

We will give the general structure of our server function. This function
handles the user requests received from Java Applet(Client). These requests are
consist of two main groups: Visualization and Debugging commands. At he
startup of HPF application, execution stops at the first call to this
server function and waits any further commands from the Java Client. 

We are following
``apparent Concurrency using A single process'' model for our server function. 
In this model, the server creates a descriptor 
(master descriptor) and binds to the one well-known 
port for service just only one time during running of HPF application.
Each time control flow came into calling of this function,
it polls incoming requests on existing descriptors.If master descriptor
is ready ,then it allocates new descriptor and add it to the list of those
on which new request from one Java Client can come. For each
descriptor other than master which is ready, it 
gets request from it ,process that request and response
back to corresponding Java Client. Therefore, many users can connect
to the running HPF application by using ``New Connection'' command and see the
its internal state and control its  execution altogether
concurrently. If the application was not started, first ``New
Connection `` command will starts it.

User has control over the execution of this server function with using
debugger commands. We are summarizing debugger commands and its
processing by the server function:
\begin {itemize}
\item {\bf Put Break Point }: Receives command containing two items:
message tag,{\bf BREAK} and the number of line on which he puts break point,
{\bf lineNumber}.Then wait for any command from any client. 
\item {\bf Delete Break Point} : Receives command
(UNBREAK+lineNumber) and takes off break point on  that line.
Then wait for any command from any client.
\item {\bf Step Over} : Receives command {\bf (STEPOVER)} and execute current
HPF statement and stop at the next calling of server function 
(don't go into body of called HPF functions )
\item {\bf Step Into} : Receives command {\bf (STEPINTO)} and execute current
HPF statement and stop at the next calling of server function
one(including body of called HPF functions )
\item {\bf NStep Over} : Receives command including message
tag,{\bf NSTEPOVER} and number of steps,{\bf N}
and execute N statements and stop at (N+1)th calling of server
function(don't go into the body of called HPF functions )
\item {\bf NStep Into} : Receives command {\bf (STEPINTO+N)} and execute N
statements and stop at (N+1)th calling of server function(including
the body of called HPF functions )
\item {\bf Continue} : Receives command {\bf CONTINUE} and execute
until we find one break point or program finishes.
\item {\bf Run} : Receive command {\bf RUN } and run into completion.
\item {\bf Stop} : Receive command {\bf STOP} and stop 
executing of application.
\item {\bf NIteration}: Receives command {(\bf NITERATION + N)} and if
program counter is in one loop ,then do N iteration for this loop and
stop at the first call of server function, otherwise send error
message to Java Client.
\item {\bf GoUntil} : Receives command {\bf (GOUNTIL+boolean\_expression)}
and continue the execution until the boolean\_expression is true.
\item {\bf Display the Value of the Program Variable} : Receive command
{\bf DISPLAY+variable\_name} and sends its value back with 
reply message(DISPLAY+variable\_name+value) if server sent the
registration information of this variable before.Otherwise,
it sends the message(DISPLAY+registration\_info+variable\_name+value). 
This variable
can be simple or array types or structured type,record.Then wait for
more command from any client. 
\end {itemize}

Each time we stopped at the server function 
HPF server sends the line number of current HPF statement . Therefore,
Java Client can update the program counter of running HPF application
in his GUI.

Visualization commands are {\bf Simulate, FilterVariable}.{\bf
Simulate} command including  message tag,SIMULATE, variable\_name and
step\_size (the interval between  two sending) should be received
before we entered one sequential loop. While execution flow is in that
loop, all the values of that variable are sent to client.

But {\bf FilterVariable} can be sent at any point of
execution(excluding the parallel constructs).It has same format as
{\bf Simulate} but extra field {\bf Filter function} which will be
applied on the value of this variable before it is sent back to Java Client.

We have also one control steering command {\bf SetVariable} including fields
,message tag SETVARIABLE , variable name and the new value. Server
will set new value to the variable . 

\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.







    

