Linear System Analyzer Usage Procedure

The LSA solves "stand-alone" linear systems, which the user extracts from the application code and writes to a file. Components will be added later which allow an application code to directly connect to the LSA, with the solution to the linear system returned to the application. Using the LSA involves starting the LSA Manager and a user control system which currently is a graphical user interface (GUI) written using Java AWT. The GUI is used in a fashion similar to the Iris Explorer, Khoros, or Paradise systems.

Linear System Input

The standalone matrix input files can be in two formats:

Matrix Market format, which consists of standard coordinatewise (COO) format. Each row has the row number, column number, and value for a stored value in the array. The first line consists of three integers, giving the numbers of rows, columns, and stored values in the sparse matrix. Comment lines can precede the first line.
Harwell/Boeing format , which is used to store systems in the standard compressed sparse row (CSR) format. Warning: the Harwell/Boeing format is actually for compressed sparse column (CSC) format, but because of its iterative solver heritage, the LSA uses CSR format. This means that a standard H/B file matrix used in the LSA will actually have the transpose of the original system solved. For people who have stored their matrices in the official H/B column-oriented format, LSA will later provide a filter which transposes the matrix. The LSA sparse system data structure itself also has fields for some information about the system.

Later, users will be able to input their systems from a running process, such as an application program or system generator.

Running the Linear System Analyzer

When the GUI is started up, the window has three major areas. One part of the interface, the Palette, has sets of components for sparse matrix manipulation and solution. A list of machines is also provided in the Palette. This list of machines is stored in a database dynamically maintained by the LSA. An image of the Palette is shown below:

For every component, the procedure is

Select a machine from the machine selector window (the list of available machines is part of the LSA resource database). The image above shows cotopaxi.indiana.edu as the selected machine. The user interface then consults the database of resources, and updates the palette of components. Ones not available on the chosen machine are greyed out; for example, in the above image the "Squeeze" filter is not available. On startup, the machine selected is the one on which the LSA server is running.
Select a component from the list of available ones. Doing so causes the interface sends a signal to instantiate the specified component on the remote machine, and creates an icon in the component canvas area. The icon has visual cues to indicate when it is successfully running and ready for interactions with other components.
Once it actually starts running on the specified machine, the instantiated component has a multipart icon which appears in a drawing area of the GUI. Each component has a similar icon on the canvas, as shown:

At the top is a status bar indicating if the component is ready, waiting for input, or is not yet instantiated. Below that is the name of the component (its type and an identifier number.) Below that are two side-by-side buttons, "Send Parameters" and "Summary Results". At the bottom of the icon is the name of the component's host machine.
Immediately after instantiation, a component's icon also presents an "Input Source" button which brings up a list of currently instantiated components from which the input port can receive the linear system. The user selects from which existing component the new one is to receive its input, and the GUI confirms the connection is made by drawing a line between the two icons. After this, the Input Source button disappears. The user can continue to create and connect components this way, forming a tree of components, the root of which is an input matrix. A typical session could lead to a Canvas part of the user interface below:

In the picture, a NewSystem component sends its input linear system to a BasicInfo module on the right. NewSystem also sends the linear system to a Scale and an SPLIB component. Scale propogates its result to a SuperLU and another BasicInfo component. Both BasicInfo components and SuperLU are processing the linear system, indicated by the red border. The borders become grey upon completion. Visual cues to indicate the state of the LSA to a user are important, since some of the numerical computations potentially could take hours or even days.
Selecting the "Send Parameters" button on a component's icon brings up a specialized subGUI for that component, providing standard Java AWT mechanisms (buttons, pull-down lists, entry forms) which allow setting parameters within the component. Such control parameters can be tolerances for residuals, method selection, output specifications, etc. For example, the SPLIB subGUI looks like:
Each subcomponent's "Send Parameters" subGUI also provides four control buttons, shown at the bottom of the image above. They are:
1. Set, which simply sets the control parameters
2. Set and Send, which sets the control parameters and causes the component to begin executing its computational code using those parameters.
3. Default, which sets the default parameters for the component.
4. Cancel, which simply closes the subGUI window without taking any action.

By continuing to instantiate, wire together, and fire components, a user can rapidly explore several solution strategies for a linear system. Furthermore, by resetting the input matrix, all components further downstream can automatically fire, allowing rapidly testing the different solution strategies for several systems.

The overall LSA process is distributed across machines because modules are running processes with data persistence: they retain the sparse system fed into them, until another one is input to the component or the component is killed. Because a large number of these components might be involved in an LSA session, using the memory and resources of networked computers is important. More than one copy of a component can be started on the same or different machines; the PSE server assigns a unique component identifier to each instantiation of a component.

Each module has the ability to create one or more "SummaryResults" files, which give information about what happened in the module. Handling these and presenting them to the user is the responsibility of the information subsystem.

Saving and Retrieving LSA Solution Strategies

The overall LSA structure of modules is a forest. Each tree in the forest is rooted at a NewSystem input module, and each module in the tree can have multiple children modules, receiving a copy of the output from the parent module. Since the user specifies for a new module a unique module from which it is to receive its input, every node in the Canvas has a unique parent module.

The Palette presents a "Save" and "Open" button at the top. The save operation saves the current component network, but not the internal state of each component. That is, it saves information about which components are open on which machines and the connection to their parent component. However, the particular linear system present in the component is not saved, nor are the internal control parameter settings. This design decision was made because typically the linear system will involve large amounts of data, and a user will want to save a solution strategy, not a particular solution. Selecting the "Open" button brings up a menu of saved component networks to select from, and choosing one causes the LSA to instantiate and connect all the components in it.

Next page: Future research using the LSA

bramley@cs.indiana.edu

Last updated: Tue Jan 26 12:30:17 1999