LSA CAT Demo

This is an example of the Component Architecture Toolkit (CAT) for a particular application domain: finding a solution strategy for solving large, sparse, nonsymmetric linear systems of equations. The approach is to take standard manipulations and solution methods and turn them into CAT components. The CAT then allows a numerical linear algebraist or other application expert) to connect together the components to explore differen solution options and to analyze the system. These components are from the LSA (Linear System Analyzer), an earlier PSEWare project at Indiana University. The components fall into categories of I/O, filters (symmetric reorderings, scalings, nonsymmetric reorderings), solvers (Splib, SuperLU, Dense, Banded), and information. We call this particular application the CAT/LSA.

First, some of the GUIs and ideas behind the CAT are described. Then a walk-through is presented for the earlier run.

Getting Started

Although the best way to see the CAT/LSA is live in action, these pages step through a sample use of it from a run made December 1, 1998 on nodes of the IBM SP-2 at Indiana University. After starting up and logging in, the CAT/LSA presents the workspace:

At this point selecting either the "New" button or the script "I" button will bring up a dialogue box that lets the user select components and machines on which to instantiate them. The script "I" button is an interface to a LDAP/MDS mechanism that manages a dynamic database of components and is described elsewhere. Selecting the "New" button consults a static database and presents the following interface:

At the top is an icon indicating for which CAT session the new component will be created - CAT sessions can themselves be treated as components and composed hierarchically. After that is a window for selecting the database file containing information about the available software components. Next are lists of components and machines on which to run them. Selecting a component/machine pair and the "Create" button at the bottom of the interface causes the CAT system to instantiate (start running) the specified component on the specified machine. This is indicated in the main workspace by the appearance of an icon, with the usual visual cues to indicate its state (waiting, running, or killed). Because multiple instantiations of a component can be run in the same session, each is assigned a unique identifying number by the CAT/LSA system - which is part of the components GUI icon in the system. An LSA session consists typically of first reading in a sparse linear system using a NewSystem component which reads in from a local file (either in Harwell-Boeing format or Matrix Market format), or can take input from a remotely running program or URL.

Connecting Components

Usually the next thing a user does is to examine it by starting up a BasicInfo component and connecting the output port of NewSystem to the input port of BasicInfo. After instantiation, each component's GUI icon has four selectable areas, as shown in the blank icon image below:

The large left arrow brings up a menu of the input ports which that component has. For the LSA application, most components have only one input port which takes a sparse linear system in compressed sparse row format. Selecting that input port then brings up a menu of the output ports of components currently running in the map, which can be connected to the given input port. Selecting an output port then allows connecting the two components even if they are running on different machines. A user can similarly connect components by first selecting an output port (accessed via the large arrow on the right-hand side of a component's icon) and then an available input port.

The details of how the CAT carries out this connection are described elsewhere, but briefly the Java GUI front end invokes HPC++ methods, which use a Nexus RMI (remote method invocation) communications run time system. The port model in the CAT allows a single output port to be connected to multiple input ports, for a component to feedback its own output to itself, etc. This allows the output from a component to be multiplexed to a variety of solving methods.

Once components are connected in the CAT/LSA, changing parameters in an "upstream" component, or feeding in a new linear system at the root NewSystem component, can automatically propogate downward through the tree of connected components. Ports can also be disconnected and new components "hotwired" into place in a running CAT system.

Setting Component Parameters

Choosing the large rectangle in a component brings up dialogue GUI for the component which allows setting parameters. In the CAT, a component parameter is any variable which is not relayed through an input port. The GUI is automatically generated, using the names given in the Java stub for the component (which in turn are generally simply taken from the C/C++/Fortran computational code that the component executes.) The image below shows the CAT/LSA session with several parameter setting boxes opened.

The parameter GUI on the right shows the settings for SPLIB, a library of preconditioned iterative solvers. It shows settings to use a relative residual stopping test, allowing 20 million integer words of storage, using preconditioning method 1 (which is ILU), with zero levels of fill. The iterative solver specified is number 5, which is biconjugate gradients stabilized. Note the defects of using automatically generated GUIs like this - we are currently adding the capability to allow a user to specify their own Java GUI, which would allow setting choices like the iterative solver without having to know the mapping between the number and the solver name.

Getting Results from a Component

Many components generate important summary data in addition to the output data. This is particularly important for the LSA, since a goal is to allow a user to find a good sparse system solution strategy easily. A bandwidth reduction reordering component, for example, may report the bandwidth achieved in addition to performing the actual reordering. A preconditioned iterative solver may record the amount of memory it required, the amount of time spent in different phases, or other performance measures. The CAT/LSA allows each component to write out local files with this information, and a design principle has been to allow a user to ignore or examine the files as desired.

Each CAT/LSA component wrapper will automatically generate a local HTML page, which records every execute event the component has. In addition, it will provide links to any local files the component generates as well as timings for the events. The small rectangle on each component's icon is a link to its start Web page, and selecting it on the CAT/LSA main GUI will bring it up in a Web browser.

A Sample Session

The end result of a session is shown below. The image below has each icon selectable by most Web browsers, and will take you to the pages automatically generated by the components as they ran.

The steps that were taken in this session were:

The session was started by reading in a system of order 20284 from the local file system, using the NewSystem 1 component.
The linear system was fed into the BasicInfo 1 component, whose result file showed that the Frobenius norm of the coefficient matrix's symmetric part is significantly larger than that of its nonsymmetric part. This suggests that an iterative solve might be effective, so ...
the Splib 1 component was instantiated and connected to NewSystem 1, with a summary results file showing 134 iterations required when CG stabilized with ILU(0) preconditioning is used.
Because scaling of linear systems can significantly reduce the required numbers of iterations and error norm, a Scale 1 component was also instantiated and set to apply row scaling, with the results fed to another Splib component (Splib 2) with the same choice of iterative solver and preconditioner. However, the results file shows that scaling had no effect on either numbers of iterations required or achieved accuracy.
To further explore the iterative solution of this system, four more Splib components were created and connected to the BasicInfo component:

Splib 3, running transpose-free QMR and ILU(0) preconditioning
Splib 4, with transpose-free QMR and ILU(1) preconditioning
Splib 5, with GMRES(20) and ILU(1) preconditioning
Splib 6, with GMRES(20) and tridiagonal preconditioning

Next a sparse direct solver was explored in the components SuperLU 1 with and SuperLU 2 without reordering. The results files from those two show that reordering reduces the time required from 225 seconds to 83 seconds, and the amount of additional memory required from 99 to 59 Mbytes. This is not a big surprise to a numerical linear algebraist, but the same reordering component will allow an expert to compare various reorderings quickly and easily.
After testing the various solvers for the first system, NewSystem was used to read in two more linear systems also of order 20284 (this is typical for PDE applications, which present a sequence of linear systems of the same order). However, because the CAT/LSA components were already connected this simply involves resetting the NewSystem component to point to different files - the execution is automatically propogated downwards through the tree to the other components, and the results are added to the output files as needed.

Here are some links to images of the workspace during different phases of this automatic propogation, showing how the user interface indicates the state of the components:

first level execution

second level execution

third level execution

At this point, the reader should also explore the results of the run by navigating around the image map of the CAT/LSA session shown above. In case your Web browser does not support client-side image maps, the links listed here correspond to the ones the image map provides.

Summary

These experiments are typical of what a numerical linear algebraist would run when faced with a new sparse, nonsymmetric, linear system of equations. The CAT/LSA allows more than just varying parameters in testing a linear system:

The input component NewSystem could take its input from a running finite element code application by replacing the application code's linear solver invocation with an RMI call.
The solution vector that comes from one particular branch of the tree of components shown above can be directed back to the running application
Combining the above two, the CAT/LSA allows actually "hot-wiring" a solution strategy into a running application - and dynamically changing the strategy as desired.

This shows how a single (important) application area can be aided by using a Grid-enabled system. Although this Web version is a poor reproduction of actually using the CAT/LSA system, it gives something of the flavor and gives an idea of how useful the National Grid can be - if a high-level resource location, managment, and composition tool is provided.

A listing of funding agencies for the CAT project can be found here.

cat@extreme.indiana.edu

Last updated: Sat Jan 23 11:16:46 1999