Future Developments for the Linear System Analyzer

• 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 proper level.
• 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 signals, etc.

Return to LSA Home Page

---

---

bramley@cs.indiana.edu

Last updated: Tue Jan 26 13:09:21 1999