\documentstyle[]{article}
\input{psfig}
\begin{document}

\begin{center} {\bf COMPONENT PROJECTS} \end{center}
\begin{enumerate}
\item HPF implementation of AMR T2 code

Within 3 months we will complete this activity. We will produce
documentation (a Technical Report) and publish the code, so that the
effort can be continued later, when and if  enough interest and/or better
compiler technology will be available. This paper will certainly
have significant value to community interested in HPF as this code is
one of largest on which HPF has been applied and non trivial use is
made of Fortran90 constructs.
In further activities we will target DAGH but build systems that
bear in mind requirements of HPF so that this can be incorporated later on
if necessary.

\item Elliptic Solvers

We propose to build a suite of multigrid elliptic solvers to become a
part of the toolkit.  The importance of these are the following:
Coordinate conditions can be described by a series of elliptic
systems.  These systems will be solved on each time slice during the
evolution of the hyperbolic system.  The obvious method of solution
will be multigrid and MLAT techniques.  These systems need to be built
ontop of DAGH as well as in HPF.   These elliptic
systems will be used for our testbed suite for WebVM proposal with Texas.
NPAC advantage: Klasky has experience with these problems.  If we do
not do this, someone else must do it.

\item Java front end to the toolkit

 This is the most exciting thing that NPAC can bring to this alliance.
Interface will be Web based, and will support easy ways to build the
toolkit that is described in the GC proposal.  Its use was to link
modules together from a workbench, in order to form an adaptive
multigrid code.  The modules would be hooked up together and then when
a button is clicked, it would be formed into a complete code. The
primary focus is DAGH, but design will be general enough that it will
be possible to reuse it for other purposes (HPF, Web based AMR
computations and more).  { NPAC advantage}: We have experience to
do this (Web technologies, including CGI and Java).  Without it only
DAGH expert programmers will be able to use this powerful product.  We
need a product that people like Richard can use. We are preparing an
independent NSF proposal to leverage this effort.

The front end will be then extended to include the initial value
problem. Data base support will be needed here. This will help choose
for the initial value set.  It can then do interpolations onto the
base mesh(es). Data base support can be included in the second year.
{NPAC advantage:} We have experience to do this (Web technologies,
databases, and Web interfaces to the databases).  Without it ``the
code'' will have to be initialized first by calling G. Cook up to make
the run.  Then, he will have to convert the data to make it usable for
the current run.  Thus, someone must do this.

\item Module for the toolkit: Clustering

NPAC has considerable experience in this area.  Geoffrey Fox is one of
the formost authorities on heuristics for optimization problems. We
can pursue methods that researchers in AMR are not looking at.  The
advanage of developing this here is that it will fit inside the
toolkit, and we can take advantage of this for our proposal.
NPAC advantage: We have experience to do this.  Without good
clustering routines, the AMR payoff will be low.  By looking into
several different algorithms, we can make AMR work better in
particular on distributed memory systems.

\item Module for the toolkit: Stability modules

By adding dissipitation terms into the equations we can alliviate the
stability problems that inccur when unigrid codes are turned into AMR
codes.  We can develop a suite of modules that can take into account
the experience of AMR experts (Choptuik) to provide an easy way for
non-AMR experts to use the toolkit. This will be worked on in the
second year.
NPAC advantage: We will gain experience with AMR stability through
Matt. Since we will design the toolkit, we can put this expertise into
the toolkit.  Without it, all users must become experts on AMR, which
means that less ``real'' runs can be done.

\item VRML visualization: Navigating through AMR worlds.

Visualization is the key to working with AMR.  NCSA is putting
considerable effort into this area.  We will take their work, and then
put it into a Web environment, making the rendering engine VRML with
Java applets included. This will be a AMR navigator.  The navigation
will occur through a Java applet that will show a spacetime diagram.
The user can click on a small section of the spacetime diagram in
order to view a portion of the data as shown in Fig.1. See the well
known NPAC Visible Human applet, of which the only difference between
these types of visulizations is that the 2D Visulization is now 3D.
We are in another project building 3D visible human viewer extending
our 2D case.

NPAC advantage : We are gaining the experience to do this.  This will
provide collboration tools with other members of the alliance.
Alternative approaches will be done at NCSA?  Our expertise with
Database support for VRML visulalization, along with interpolation
expertise, make NPAC a clear choice for doing this work.  Without this
work, collaboration among GC researchers will again be hampered, since
a researcher at Cornell would have an almost impossible time showing a
researcher at Texas his results.  Too much data to start moving
around, just to look at a few images.  Displays are too complicated to
show someone, unless both parties can manipulate the data at the same
time.

Interactive runs using VRML will need DataBase support. At NPAC we
demonstrated critical importance of it for performance (the terrain
rendering project).  Same concepts, lots of data, lots of different
runs. VRML or other visualization technologies does not address the
storage problem.  Database component can be the one that
post-processes the data.  For example, isosurface values can be done
in this part.

\item Incorporation of other modules into the toolkit
Integrators, outer boundary conditions, etc.

\item Physics support for the GC code. TA student David Rideout will be working
on his dissertation based on AMR work on the GC code.  Since the GC code will
be based on the T2 code, a code writen by Texas with Syracuse support,
David will be
able to provide usefull modules to be used in the GC ADM code.  Among the
modifications Rideout and Klasky are are working on, and are 99\% finished
are conversion from $K^i_j$ evolution to $K_{ij}$ evolution. Rideout will also
be looking to provide updates to the overall GC code, that will incorporate
modules from the alliance. 


\end{enumerate}

\begin{center} {\bf PROPOSAL!!} \end{center}
In the first year we will concentrate on the JAVA front end (30%), elliptic
solvers (50%) and clustering (20%). During the second year we move the
emphasis to VRML visualizations (50%) and stability modules (20%). The
remaining 30% of our effort will be directed to the elliptic solvers,
the JAVA frontend, and/or other toolkit modules, as necessary.

\end{document}
