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
The GUI is used in a fashion similar to the
Linear System Input
The standalone matrix input files can be in two formats:
- Matrix Market
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,
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.
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
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,
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
- Set, which simply sets the control parameters
- Set and Send, which sets the control parameters and
causes the component to begin executing its computational
code using those parameters.
- Default, which sets the default parameters for the
- 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
the PSE server assigns a unique component identifier to each instantiation of
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
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
Last updated: Tue Jan 26 12:30:17 1999