General Linear System Analyzer Usage Ideas
The user interface
is fairly self-explanatory, but some basic ideas
about using the LSA can help in getting started.
The LSA is intended to initially be used on "stand-alone" linear systems,
which the user extracts from the application code and writes to a file.
Modules and interfaces will be added later which allow an application
code to directly invoke the LSA, with the solution to the linear system
returned to the application.
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 the standard compressed sparse row (CSR) format. Warning:
the Harwell/Boeing format is actually 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 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.
Using the Linear System Analyzer
After installing and
starting up the LSA, the user is presented with
a graphical user interface. One part of the interface has sets of modules
for sparse matrix manipulation and solution. The user selects a module to
start up and a machine to start it on.
Modules can be run on any machine that the user has access to and which is
specified in the start up script process. The overall LSA process is
distributed in this way, because modules are running processes with
data persistence: they retain the sparse system fed into them, until another
one is input to the module or the module is killed.
Because a large number of these modules might be involved in an LSA session,
using the memory and resources of networked computers is important.
More than one copy of a module can be started on the same or different machines;
the PSE server assigns a unique module identifier to each instantiation of
a module.
Once it actually starts running on the specified machine, the
instantiated module has a multipart icon which appears in a drawing area of
the GUI. The user selects from which existing module the new one is
to receive its input, and the GUI confirms the connection is made by
drawing a line between the two modules.
The user then can construct solution strategies, or compare multiple
strategies for the same system, by continuing to create and wire together
LSA modules.
Linear systems are input using NewSystem modules, which read in a
matrix (and optionally a right hand side vector) and perform some
simple validation checks. Solution vectors are output using ExtractVector
modules, which specify where the solution is to be sent.
Each module has the ability to create one or more "SummaryResults" files,
which give information about what happened in the module. The
SummaryResults files are HTML format documents written to a file on
the local machine where the module actually ran. Users can retrieve and
view SummaryResults files from selected modules, or can save the session's
results. A session results save operation retrieves all of the
SummaryResults files, and creates a graphic image of the drawing window
with the module icons. A user examine the files at a later date by
opening the drawing window image in a browser; selecting a module icon
brings up the corresponding SummaryResults file.
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, each 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 tree has a unique parent module.
Visual cues in the LSA GUI inform a user when a module is running, since
some of the numerical computations potentially could take hours or even
days.
Next page: Current LSA Modules
bramley@cs.indiana.edu
Last updated: Tue Jan 26 13:04:46 1999