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 HPC++. 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.

Provided Modules

The LSA modules currently are grouped into four categories, with others to be added later.
  1. I/O modules.
    1. NewSystem, which reads in a new system from a file.
    2. ExtractVector, which writes out a vector (typically, the solution vector) to a file.
  2. Information modules. These provide information and analysis about a particular system.
    1. BasicInfo 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.
    2. IterativeInfo provides estimates of storage for using different iterative solvers and identifies easily-solved cases (symmetric matrices, strongly diagonally dominant, etc.)
    3. DirectInfo provides storage estimates for sparse direct solvers, and recommendations on using those solvers.
    4. SpectralInfo 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.
  3. Filter modules take a sparse system and manipulate it to provide another sparse system.
    1. Reorder applies row and column permutations to the matrix, with the row permutation also applied to the right hand side vector.
    2. Scale applies row, column, or row and column scaling to the matrix.
    3. Squeeze will filter out stored values below a given cut-off from a sparse matrix (but leaves the right hand side vector alone).
    4. Transpose does the obvious. This is useful for those who have stored their matrices in CSC format, because LSA assumes CSR.
  4. Solve modules (try to) actually solve the linear system.
    1. Dense is a wrapper for the general real matrix driver of LAPACK. It converts the matrix to dense storage representation and and so should only be used for small systems.
    2. Banded 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.
    3. Skyline is a standard skyline solver without pivoting.
    4. SPLIB is a library of preconditioned iterative solvers. SPLIB is particularly useful for its extensive instrumentation output.
    5. SuperLU is a sparse direct solver from Xiaoye Li . SuperLU is in the LAPACK philosophy and provides good error estimates; it uses a supernodal factorization approach to achieve good efficiencies on modern workstation architectures.
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.

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

[REORDER MODULE IMAGE]

The components of a module's icon are:

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:

[SPLIB CPP IMAGE]

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 making choices.

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


    [ IU CS ] [ Extreme! Computing ] [ PSEware ] [ LSA ]
    bramley@cs.indiana.edu

    Last updated: Tue Jan 26 13:04:51 1999