Linear system analyzer modules
Under the Hood
As described in the section on
general usage ideas, modules are selected
from a predefined set and each is instantiated on a user-specified
machine. A module is a complete Unix process, started up
by the hpcxx_invoke() remote context invocation in
Data sent between modules are handled by
Nexus, with the
data sent directly between the modules instead of going through
the Hserver. In addition to remote method invocation (RMI),
HPC++ allows global pointers to be used which simplifies
some inter-process synchronization and coordination.
Using Nexus provides efficient
and portable data transfers. Nexus handles all of the data conversion
needed for messages between modules running on different machines.
Each module has an HPC++ context wrapper with some standard functions:
Because the target domain is sparse linear systems, the intermodule
data transfers have been simplified to one object: a sparse linear system
data type, defined as a CSR represented matrix, a right hand side vector,
and some auxillary data. Details of the LSA
sparse system object are in the code source.
- ReceiveSystem(), which receives a sparse system from the invoking module.
- SendSystem(), which invokes another module's ReceiveSystem() method.
- Gang, need to put in the full list, with links to HTML User's Guide
The LSA modules currently are grouped into four categories, with others to
be added later.
An important design goal of the LSA is to allow users
to easily add their own components, allowing a ``plug and play''
modularity and the ability to quickly test new sparse system
solvers in a uniform setting which allows fair comparisons.
Generic LSA wrappers are provided for the three classes of
modules to help users wanting to extend the system this way.
- I/O modules.
which reads in a new system from a file.
which writes out a vector (typically, the solution
vector) to a file.
- Information modules. These provide information and analysis about a
implements the same functionality as (and uses only
slightly modified code from) SPARSKIT, the toolbox of
sparse matrix utilities by Yousef Saad and Edmund Chow.
It tells the user characteristics which are quickly and
easily computed: degree of symmetry, number of zeros on
main diagonal, etc.
provides estimates of storage for using different
iterative solvers and identifies easily-solved cases
(symmetric matrices, strongly diagonally dominant, etc.)
provides storage estimates for sparse direct solvers,
and recommendations on using those solvers.
is only for small matrices or large computers. It
computes and displays the eigenvalues or singular values of
the matrix, and provides some discussion about what they
imply for solvers for this particular system.
- Filter modules take a sparse system and manipulate it to
provide another sparse system.
applies row and column permutations to the matrix,
with the row permutation also applied to the right hand
applies row, column, or row and column scaling to the
will filter out stored values below a given cut-off from
a sparse matrix (but leaves the right hand side vector alone).
does the obvious. This is useful for those who have
stored their matrices in CSC format, because LSA assumes CSR.
- Solve modules (try to) actually solve the linear system.
is a wrapper for the general real matrix driver of
It converts the matrix to dense storage representation and
and so should only be used for small systems.
is also a wrapper, for the LAPACK banded solver with pivoting.
It converts the matrix to banded storage representation, with
space for the pivoting provided.
is a standard skyline solver without pivoting.
is a library of preconditioned iterative solvers. SPLIB is
particularly useful for its extensive instrumentation output.
is a sparse direct solver from
Xiaoye Li .
SuperLU is in the LAPACK philosophy and provides good error
uses a supernodal factorization approach to achieve good
efficiencies on modern workstation architectures.
Module User Interface
Every module follows the same generic representation in the GUI,
regardless of its type. For example, the Reorder
module's icon in the graphical user interface is
The components of a module's icon are:
This contains the name of the module, and a unique module
identifier (an integer). This is for connecting modules, when the user
needs to specify which active modules are to be connected.
- Input Source:
Selecting this part of the icon image brings up a drop-down
menu of currently active modules from which the input to the
current module could come. Selecting one of those results in
a line being drawn connecting the modules, and the output
from the specified module being fed to the current one.
- Control Parameters:
Clicking this part of the image brings up a separate GUI,
in which the user selects input parameters for the module.
For the Reorder module, this is a simple selection of
the reordering methods. For a package like SuperLU, control
parameters include the Markovitz pivot parameter, type of
error estimation, supernode size,
relaxation parameters for supernode size, etc. Each
Control Parameter GUI has a default button, which is important
for nonexpert users.
- Summary Results:
Clicking on this part of the icon causes the LSA to
retrieve an HTML file (possibly with multiple files and
associated graphics files), which contains a summary of the
results of that module's run. SuperLU, for example, simply
returns the error estimates, the amount of storage required,
and the time. In the future, it will also return a graphical
view of the elimination tree from the solve.
- Host Machine:
This gives a short name of the machine on which the module is running,
or an IP address if the name is not available.
Control Parameters Panel
Each module has a "control parameter panel", for inputting parameters
that determine the computations for that module. Each one differs;
the Reorder module has a simple drop-down selection list, while
SPLIB has several interlinked choices. The SPLIB control parameter
GUI looks like:
When choosing an iterative solver like GMRES (shown above),
non-applicable choices like SOR relaxation parameter
are "ghosted out", not allowing the user to select them.
Each time a selection is made that takes a numerical
parameter (such as ILU(s) shown above), a default
choice is supplied. Furthermore, a "Default" button for the
entire panel is supplied at the bottom, allowing a user to avoid
Each control parameter panel also has a button labeled "CBR Wizard".
In later releases of the LSA, this will be connected to a
case-based reasoning system providing guidance based on previous runs.
Next page: LSA User Interface
Last updated: Tue Jan 26 13:04:51 1999