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
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
communications subsystem, or in the user control and interface.
An exception handler needs
to be built to catch and interpret errors at the
- 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
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
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
Return to LSA Home Page
Last updated: Tue Jan 26 12:12:47 1999