Future Developments for the Linear System Analyzer
Future developments fall into three categories:
things which are currently being developed, things which
with hooks explicitly designed in the LSA, and a "wish list".
- Items under active development:
- 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.
- 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
PSE manager, or in the user interface. An exception handler needs
to be built to catch and interpret errors at the
- Items designed for the LSA but not yet built.
- I/O modules 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.
- Currently the machines on which a module can run are
provided in a static list. Better would be a dynamic
machine database, listing available machines and their
currently available resources, with some automatic
selection of the best resource to run a new module on.
- Collaborative component: 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
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.
- Wish list:
- 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 13:09:21 1999