Future Developments for the Linear System Analyzer

The LSA is still under active development, and the following is only a partial list of research prompted by it.

Intelligent guidance: every module's Control Parameters menu has a prominent "Defaults" button. An intelligent system needs to be added to learn what does and not work well for a particular user's application area, and use that knowledge to better guide in parameter selection. David Leake and David Wilson are working on a case-based reasoning (CBR) system to integrate with the LSA.
Exception handling Each module has its own self-defined error conditions which are returned, and those vary from mild warnings about potential inaccuracies in the solution vector to numerical breakdown. In addition, exceptions can occur in the wrapper (running on a remote machine), in the LSA manager accessing the resource database, in the Nexus communications subsystem, or in the user control and interface. An exception handler needs to be built to catch and interpret errors at the proper level.
I/O module extensions should be able to accept a sparse linear system coming from an application code, and return the solution vector to that code. This is a minor extension, but will help in the creation of solution strategies for nonlinear solvers, which present a long sequence of sparse systems which can vary greatly in their characteristics.
Dynamic resource managment. Currently the machines on which a module can run are provided in a simple database. This needs to be extended to also have information about the capabilities of the machine (memory, computation rate, etc) to prevent trying to run a component on an inadequate resource. Globus may be used for this. Dynamic checking of network availability and speed can also greatly improve the overall performance, and we hope to build on Netsolve for this as well as some automatic selection of the best resource one which to run a new component.
Collaborative capabilities: the LSA is intended to be used in a collaborative fashion, with users scattered across the internet working on the same LSA Manager window simultaneously. We will introduce collaboration in two stages: first by running TechTalk (Drexel University) alongside the LSA, using its Chat and Matlab abilities, then secondly by having Infospheres from Caltech handling the multiple user interfaces to a single LSA session as djinns.
Most applications users (the second target audience category) want C/Fortran source code which they can extract and add to their own code. Once a solution strategy has been developed, an "extract code" button should be provided allowing users to do precisely that. We do not want to simply provide all the code in the LSA as a library, since that is typically much larger than is needed.
To allow users to experiment with the LSA without having to install the complete system, a Web interface with server and compute resources running at IU needs to be created. This brings up security issues, however, which have been ignored until now.
A scripting language (Perl, Python) interface should be provided, particularly for users who do not want the extra baggage and effort involved with a GUI.
The LSA codes are for nonsymmetric linear systems. When the coefficient matrix is symmetric, more efficient and robust methods are available. Introducing a symmetric system datatype and codes will be useful for the large number of applications that generate such systems.

In addition, the PSE infrastructure itself needs to be better generalized, allowing a PSE developer full control over what signals can be sent to a module, how the GUI will interact with those signals, etc.

Return to LSA Home Page

bramley@cs.indiana.edu

Last updated: Tue Jan 26 12:12:47 1999