• Elliptic Solvers. We propose to build a suite of multigrid elliptic solvers. We will build these on top of WebAMR, HPF, and DAGH. 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. Support will be for 50 % of our budget. [Klasky] INTERNALLY: These elliptic systems will be used for our testbed suite for WebVM proposal(s). NPAC advantage: Klasky has experience with these problems. If we do not do this, someone else must do it.

• Java front end to DAGH,WebAMR,HPF (PSE). 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 a multigrid code in DAGH. The modules would be hooked up together and then when a button is clicked, it would be formed into a DAGH code. This will require 30 % of our time.[Haupt] NPAC advantage: We have experience to do this. Without it only DAGH expert programmers will be able to use this powerfull product. We need a product that people like Richard can use.

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

• Module for the toolkit: Clustering. NPAC has considerable experience in this area. Geoffrey Fox is one of the formost authorities on optimization problems. We can pursue methods that researchers in AMR are not looking at, (spin models, etc.). The advanage of developing this here is that it will fit inside the toolkit, and we can take advantage of this for our proposal. This will require 20 % of our time. [Haupt, Klasky] 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.

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

• 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 render 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 (??). Cite the Visible Human, of which the only difference between these types of visulizations is that the 2D Visulization is now 3D. 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. We should propose this during the second year. Cite the terrain rendering. Same concepts, lots of data, lots of different runs. Database component can be the one that post-processes the data. For example, isosurface values can be done in this part.

• Incorporation of other modules into the toolkit. Integrators, Outer boundary conditions, etc.

Figure 1: VRML Visualization Screen 3