- Email: [email protected]
Experiences with an expert system for odes
Mathematics and Computers North-Holland
EXPERIENCES D. BARNETT
in Simulation
31 (1989) 315-323
WITH AN EXPERT SYSTEM * and D. KAHANER
315
FOR ODES
**
* University of the District of Columbia, Computer Science Department, Washington DC 20008, U.S.A. * * NIST, Center for Computational and Applied Mathematics, Teihnology Building, Room AISI, Gaithersburg MD 20899, U.S.A.
An Expert System can be defined “bottom up” as a software package that uses a knowledge base and inference engine, or “top down” as one that attempts to simulate the reasoning of a human expert. PLOD, a package for solving systems of ordinary differential equations satisfies the second form of the definition but not the first. We describe the major features of the package, and how we have been forced to “reinvent the wheel” in order to provide needed capabilities. Certain standard building blocks are described in the hope that these can be developed for use in other systems.
1. Introduction For the past few years we have been developing an interactive solver for the initial value problems associated with systems of ordinary differential and difference equations (PLOD). Several hundred users have helped to locate bugs and describe areas needing improvement. As far as this group is concerned, PLOD satisfies all the usual requirements for an Expert System easy to use, eliminates routine decisions by inexperienced users, and incorporates knowledge by experts in the form of program flow and access to a high quality integration engine. Nevertheless PLOD was designed ad hoc and does not utilize what software specialists would call “Expert System Technology.” This paper describes the design goals and general capabilities of the package. In particular we focus on those areas where we have had to “reinvent the wheel,” including input/output, menus, error handling, and graphics. We identify certain functions that seem likely to be commonly needed in future scientific Expert Systems. PLOD is an acronym for PLotted solutions of Ordinary Differential equations [l]. PLOD solves systems of the form
_Y’=fk Y)
037%4754/89/$3.50
0 1989, Elsevier
316
D. Barnett, D. Kahaner / Expert System for ODES
Critical ingredients of any software for exploring solutions of (1) are flexibility, interaction, and graphics. These must work together and be flexible enough to allow a user to develop his or her own route to a solution. An interactive system can be very flexible, although this is often at variance with the need to perform many thousands or millions of integration steps. Flexibility need not mean a large selection of different numerical techniques; while it is interesting for numerical analysts to compare different methods, problem solvers are usually content to allow the choice of methods to be made for them by an expert. Some other software has been developed to address the needs in this problem area. Solvers such as Phaser [4] and others are described in [5], but most of these use relatively primitive numerics and are unsuitable for difficult cases. Large scale (mainframe) simulation packages often incorporate good ODE solvers. A compendium published in “Simulation,” lists several hundred, but most are expensive and difficult to use. Few are designed to be interactive although they can be very flexible in other ways, as for example ACSL 161, or ATOMCC [7] which have also been implemented on micros. One of the earliest fully interactive systems was developed by Korn and Wait at the University of Arizona in the late 1970s [8]. There seemed to be a need for software which addressed the casual user rather than the numerical analyst, but which was of high numerical quality. PLOD has been designed with the following seven criteria (more details are given in [l]): (1) Solves 25 (or fewer) ordinary differential equations with up to 10 parameters. (2) Integration to be done while the user is at the terminal. (3) So easy to use that it will to run first try. (4) The numerical methods and their implementation should be current. (5) Rapid, flexible and attractive graphics should be integrated. (6) As portable as possible. (7) In the public domain. PLOD runs in two interactive steps, called PLOD0 and PLODl. A small “batch” program, called PLOD runs and PLOD0 and optionally will do the processing to pass the PLOD1 step. A user installs the distributed files and types PLOD. During the PLOD0 step, the user enters the functional form of the equations via a built-in screen editor. Syntax errors are noted and corrected at this time. There is no integration during this step and, in fact, no numerical values are requested at this time. PLOD0 is a preprocessor; its output is a Fortran program having the user’s equations in a form which will enable them to be integrated numerically. It also has a mechanism to communicate the names and other information to the next, or PLOD1 step. The batch program PLOD takes the output Fortran program and invokes a compiler. Upon successful compilation PLOD links to several already precompiled modules which are supplied with the package, resulting in an executable program which is then immediately executed. Running this program called the PLOD1 step. During the PLOD1 step the user is asked for values of the parameters, initial values for the dependent variables, and the interval on which the integration is to take place. After the integration the user can request various information about any combinations of variables and parameters, either through graphs or listings, can change parameter values, initial conditions, integration interval, etc., and examine results under varying conditions. Sophisticated users can alter the integrator parameters, including the integration and iteration methods, error tolerances, etc. During PLOD1 one cannot alter the functional form of the model by adding terms, or adding or removing equations. To make those changes requires returning to the PLOD0 step.
D. Barnett, D. Kahaner / Expert System for ODES
317
2. PLOD as an expert system An expert system can be viewed as a computer program that attempts to simulate the reasoning of a human expert in some limited problem domain. Accordingly, PLOD’s attempt to simulate the reasoning of an expert in writing a program to solve and plot a set of ODES qualifies it as an expert system. Because PLOD is written in a procedural language and does not have an explicit knowledge base and inference engine, some might take exception to this claim. However, in the authors’ opinion many programmers not involved in numerical work are too quick to view numerical software as strictly algorithmic without the heuristic rules one usually associates with expert system problem domains. For example, it would be naive to implement an ODE solver based upon an algorithm from a numerical analysis text; to be robust such a program must incorporate the expertise and heuristics of an experienced expert analyst. PLOD attempts to incorporate the best expertise available (algorithms and heuristics) for solving ODES. PLOD’s interface has also been developed and refined with another type of important expertise-the feedback from hundreds of users in universities, research laboratories, and industrial organizations. Being responsive to the user community has helped to give PLOD the kind of dynamic and evolving knowledge base that one associates with expert systems. There have been many instances in which user suggestions have resulted in alterations to the interface; most of these are minor. In the next section, this interface is discussed in more detail, but here we mention two significant examples of the importance of user feedback. (1) Difference equation simulation. Users asked to be able to perform the same kinds of calculations on difference equations that PLOD enabled them to perform on ODES, and this capability was then built-in. We adopted the convention that if n was used to signify the independent variable, an expression like Y’ = SIN(Y) would be thought of as referring to the equation Y, + 1 = sin Y,. In all other respects PLOD treats these systems just as if they were ODES, except, of course that “integration’ from n to n + 1 is trivial and bypasses the integrator. (2) Special events. Engineering problems are characterized by situations occuring at times that are not known in advance - motors and valves turn on and off, weapons strike targets, containers become full or empty, etc. The time sequencing of these events depends upon the solution of the system and often represents the dominant properties of the integration. Good ODE software already has the bility to determine the times at which functionals of the solution take on specified values [9], and we were able to include this in a natural way. The user invokes it by entering X + Y = Z * Z & X - Y > 0, meaning that special action is to be taken whenever X + Y = Z2, if also X is greater than Y.
3. The PLOD interface With the proliferation of personal workstations and the increase in users who are not computer professionals, user interfaces have become increasingly important. Today’s users are not tolerant of poorly designed interfaces, nor are they highly motivated to spend a large amount of time learning to use software. Instead they want interfaces that let them get started immediately (preferably without a manual). Interfaces that frustrate the user by demanding an extremely high threshold of knowledge can ruin the effectiveness of the software. Programmers
318
D. Barnett, D. Kahaner / Expert System for ODES
tend to separate the user interface and the underlying application, but users are more likely to view the application’s “look and feel” and its functionality as the same. From the end user’s point of view, an interface should be simple and consistent. Simplicity allows the beginner to easily begin “learning by example” with the absolute minimum of prerequisite documentation. This simplicity is conveyed in the way in which the user is: - informed of what the present options are and of what comes next, - directed to additional information if help is needed or requested, - told that a problem exists and how it should be addressed. Although simplicity is desirable, the interface should not stifle the experienced user. For instance, allowing commonly used commands to be entered with a minimum number of keystrokes might assist the experienced user avoid navigating through a long path of unnecessary questions. Consistency is the attempt to make as much of the interface’s behavior as possible independent of context. Thus the user can rely on certain types of behavior of the interface independent of the state of the application. This is a good way to build confidence in using the software. We do not claim to have achieved the ultimate in simplicity and consistency, however these continue to be two of our most important design objectives in the interface. From a programmer’s point of view, a user interface should be easy to assemble and encourage good software engineering through code modularity and reusability. Programming the user interface traditionally requires the same order of magnitude of effort as programming the underlying application. In the past, this has been a major obstacle to the development of “polished” interfaces. Hence schemes that encourage code reusability from one application to the next are highly desirable. Such schemes enhance productivity even more if the applications programmer can reuse this software without attention to low level details. Modularity, as used above, refers to the attempt to insulate the application from the interface. It would be ideal if modifications and adjustments to the interface could be made with minimum modifications to the underlying application. The above concerns have been the driving force behind the recent activity in user interface toolkits. In Section 5 we will describe the kind of toolkit that would have simplified the writing and maintenance of the PLOD interface.
4. Major interface components Menus play a major role. They allow user specification of problem parameters and modification of default package parameters. In addition to menus offering a finite set of explicit choices, users also need to input data directly. Hence, the menu must have error handling facilities to ensure that the right type of data is entered and that the data falls within bounds (or meets other constraints). The menu requires facilities so as to be able to set these bounds. In future versions, menus will also be used to allow more control of program flow. Menu software needs to deal with several distinct issues. First is screen presentation-what the user actually sees-as well as cursor and keystroke control. Second is menu content, how data is “fed” to the menu, what controls exist between menu choices and what restrictions can be placed on menu entries. We were unable to locate any Fortran callable menu packages for numerial applications, so we wrote one, CARTE suitable for our needs. Fig. 1 shows a typical menu presentation. At the moment that Fig. 1 was printed the menu was highlighting the line Iteration
319
D. Barnett, D. Kahaner / Expert System for ODES Title:
nTonlinc>ar
Eps:
accuracy
Max
integration
Plotting
strps
tolerance:
Frequency Connect
O:Maximum
L:Cycles
Zero:
Kewton’s Functional Pressing
nlethod
c;car’s
m&hod
order: step
5 size:
Defaulted
l.llOOOOE-15
kept
within
for non-positive to plots:
about
G:Digits
1
Newton’s
integration
dots
400
yes
integration
B:\‘ariables
Data
points:
in plot: method:
S:Maximum
l.OOOOOOE-04 warning:
I .OOOOOOE-03 percent
method:
N:Integration
Z:Problem
Equation
before
of saving points
Iteration
Add
Bifurcation
of intrgration:
bounds:
Defaulted
log plots:
4
no
integration
in displays: method iteration space
4 requires
bar
dots togglr-s
finite not
difference
and
from
is faster,
one
to the
approximations but
is unsuitable
to Jacobian for stiff
matrix. prohlrms.
other.
Fig. 1. Typical PLOD expert menu.
method: Newton’s method and also displaying the note at the bottom of the screen which provides subsidiary explanation of what this choice means. The programmer calls CARTE by passing it a menu title, the number of menu items NMENU and arrays, each NMENU in length. The ith element in each array gives information about the i-th menu item. Thus NOTES(I) contains up to 240 characters that are automatically displayed at the bottom of the screen when MENU(I) is highlighted, MTYPE(1) describes what a user is allowed to do with this item, i.e., just read the note, enter data (real, integer, string, etc.), sequence through a preselected set of choices, and so forth. BOUNDS(I) specifies whether input is to be bounds checked, and if so how. Menu entries can have some replaceable text to make them more readable. CARTE manages the cursor movement, checking input for validity, displaying menu choices, error messages, etc. Provision is also made for bounds checking that is too complicated to be done by the menu handler but must be passed back to the calling routine. In J?g. I an example of the latter occurs in the interaction between maximum allowed integration order and integration method. Parsers are used in PLOD0 and PLODl, particularly for error handling. A simple parser is used to determine whether a user-input represents a valid number, and another parses the differential equation model. One of the design objectives of PLOD is to ensure that the user is not confronted with Fortran error messages. Hence we must be able to catch the source of any syntax errors in the model and state them in terms of the differential equation model. By examining the ODES, PLOD’s model parser also identifies independent variable, dependent variables, parameters, and temporaries, and passes this information on to the Fortran program. In PLOD1 a Fortran callable parser is used in order to allow users to print or plot expressions involving the variables and parameters such as LOG(Y) + X * ALPHA. This routine is passed a string with an expression to be parsed and a list of variables. It returns a “parse-tree” description of the string and a list of the variables that were involved. A second routine can be called to evaluate the parsed string given an array of the values of the variables that are used. Knowing which variables are used in the string can be helpful in determining if additional computation is
320
D. Barnett, D. Kahaner / Expert System for ODES Select with
arrows
or Alt+first
character;
Esc
to exit
To MOVE CURSOR use Arroxs, PgUp, PgDn, Home, End To EXIT % CONTINUE use Esc, To ERASE CHARACTER ABOVE CURSOR use DEL To DELETE FROM CURSOR TO LINE END ise Ctr; and T (together) Independent variable is T Note: [________~_________~_________3-_-----____~-------___~_--------~_________
IThis is a comment!
(Apollo in Earth-Moon
orbit)
P = 1./82.45 q = 1.-P % Try initial values x=1.2, y=O, xp=O, ~~'-1.1 % Try friction term f in the range LO, 11 % Integration interval [O, 61 and plot x vs y Rl = (x+P)**2+Y**2 R2 = (x-q)**2+Y**2 X' = XP % Note use of primed variables Y' = YP XP' = 2*Y' + X - q*(X+P)/R1++1.5 - P*(X-q)/R2+*1.5 - F+X' ypJ = -2*X' + Y - q*Y/Rl++I.S - P+Y/R2**1.5 - F*Y'
Fig. 2. The appearance of the PLOD model editor.
needed before the evaluator can be called. For example, a user may want values of Y * Y + ABS(Y’). PLOD determines values of the primed variable by re-evaluating the right hand sided of the ODES - a wasteful activity if not actually required. Separating parsing from evaluation is also appropriate if the same expression is to be evaluated at many different times, as in plotting. Again we were unable to locate suitable Fortran callable software and had to write our own expression parser. PLOD has a built-in, easy-to-use screen editor for creating and editing the ODE model. There are many text editors but we were unable to find one that could be used from within a running program, even though this seems to be a facility that could be of value in many applications. Our editor uses a small subset of the capabilities of a full featured word processor-cursor movement around the screen, insert and delete characters, etc. Fig. 2 shows a typical screen as displayed by the editor on which a PLOD user will input equations. Currently editor and parser are not integrated. However, our next version will be structured so that when the parser detects a problem, control will pass to the editor with a message displayed explaining the nature of the problem and with the cursor positioned at the location of the error. It might also be possible to allow users to insert their favorite editor. Plotting is an essential feature that is available in PLOD. We were unable to loate any nonproprietary Fortran graphics software. Some quasi-public-domain software such as NCAR [lo] was available but seemed designed for batch rather than interactive graphics. Proprietary mainframe software, that has been moved to PCs, such as DISSPLA [ll] seemed to suffer from the same difficulties. Several proprietary Fortran callable libraries are available for the IBM PC family, including IBM GKS [12], HALO [13], and GRAFMATIC [14]. Each was able to satisfy our requirements, but the PLOD user needs to compile and link programs, hence the graphics library must be available to the linker. Distributing a proprietary library would violate the vendor’s purchase agreements. Furthermore, we were committed to development of public domain software, and graphics, or at least plotting, was seen as an important need. Consequently, we wrote a small set of screen plotting subroutines to be used with PLOD, which also
D. Barnett, D. Kahaner / Expert System for ODES
321
could be called (from Fortran) independently. General plotting sofware is desperately need for use with almost every type of scientific problem solving software. Plotting is very hardware dependent, but even some simple issues have not been addressed. For example, a common plotting problem is that the number of data points is either too few to generate a smooth plot or too many to be able to plot individually on a finite resolution display device. Splines or other interpolation/smoothing algorithms exist for the first situation. But the second case is also important because plotting redundant points is time consuming and wasteful. To date we have only seen one effort to deal with this [15]. Another neglected area relating to graphics “data editing.” Before sophisticated analysis or modeling can be performed a program must be given some data, typically read from files or generated internally. Most scientists will want to look at the data to get a sense of what should be expected. In the process some preliminary “eyeball” analysis may suggest that some data points ought to be deleted or transformed. The easiest way to do this via graphical interaction, in other words a graphical data editor. A software tool designed to permit such editing would be an essential part of many modeling packages. The PLOD distribution disk includes two tutorial files that explain all the details of the PLOD system. There is also some on-line help to assist the user in determining the hardware/software requirements, the capabilities of the package, and the procedures for using PLOD. There are also a few isolated help facilities for explaining the options available at specific points in the program. Experience has also shown that the tutorials are rarely read. There appears to be an inverse relationship between the amount of interaction in a piece of software and the fraction of users who will look at anything except the software. In our next version a more comprehensive set of help facilities will be implemented allowing the user to get to any specific advice at any point in the program in a consistent and comprehensible fashion.
5. The need for tools PLOD’s interface was not designed in a unified manner but evolved in response to user feedback over several years. The programming effort to develop this interface demonstrated the need for user interface toolkits to reduce the resources needed to implement, polish and maintain a user interface. These toolkits can be described as software modules “. . . used to write user interface components (‘widgets’), to organize a set of widget instances into a complete user interface, and to link a user interface with the functionality provided by an application.” [16] Although such toolkits are becoming more prevalent (especially for UNIX-based workstations), there is little available for the PC-based Fortran environment. This emphasizes the gap between software developers and users. We are in the process of designing and implementing a toolkit to address this need. What attributes should a toolkit have? A primary attribute must be the ability to create and customize “widgets” (menus, parsers, editors, etc.) via high level specifications. For example, to create a parser one might only provide a BNF specification for the grammar (YACC - Yet Another Compiler Compiler- is an example of such a tool in the UNIX/C environment which imposes “structure on the input to a computer program” [17]). Or a menu might be instantiated by providing by providing the choices available (and optionally location, color attributes, etc.).
322
D. Barnett, D. Kahaner / Expert System for ODES
The primary objective is for the application developer to be removed from the low level detail of coding the widget. Another desirable toolkit feature would allow the developer to organize a set of widget instances into a complete user interface. This could be achieved via specifications embedded in the application’s code. One drawback is that to reorganize or modify the interface, the application code must be modified. A friendlier approach is to allow the widgets to be instantiated and organized into an interface with a user interface editor. This trades off some of the low level functionality available through the application maintaining control for the ability to easily construct, modify, maintain, and customize interfaces [18]. Finally it would be desirable to use an “event-driven” programming paradigm to link the interface with the application functionality. Then the application registers event subroutines (what subroutine should be the application execute when an event occurs such as making a menu selection) with the interface and then passes control to the interface. The application is released from the responsibility of control flow (at least as it relates to interface events). This reduces the burden on the application developer and allows the interface to be modified without disturbing the application.
6. Conclusion Nonscientific software for small computers raises the standard by which scientific software is judged. Users expect a similar level in technical applications. Many proprietary scientific software products have acceptable interfaces, often implemented at great cost, but these are not available to the academic software developer. If functions of the type described in this paper can be created with standard interfaces they will make writing expert systems easier, and can also assist users who will see more uniformity in distinct products.
References [l] E. Agron, I-Lok Chang, G. Gunarantna, D. Kahaner and M. Reed, Mathematical software: PLOD, IEEE Micro, 8, 4 (August 1988) 56-61. [2] D. Kahaner, M. Reed and S. Stewart, PLOD/PC, Interactive solver for ordinary differntial equations on microcomputers, subm. J. Appl. Math. and Computing (1988). [3] D. Kahaner, C. Moler and S. Nash, Numerical Methods and Software (Prentice Hall, 1989). [4] H. Kocak, Differential and Difference Equations through Computer Experiments (Prentice Hall, 1985). [5] H. Lewis Penn, A review of differential equations software, Collegiate Microcomputer 6 (1988) 33-42. [6] Advanced Continuous Simulation Language (ACSL) Reference Manual, Mitchell and Gauthier, Assoc., 290 Baker Ave., Concord, Mass. (1981). [7] Y. Chang and G. Corliss, ATOMCC User Manual, ODE-Matic Software, 2745 Anderson Drive, Lincoln, NE 68506 (1983). [8] G. Korn, The invisible compiler, IEEE Computer (May 1983) 55-62. [9] D. Kahaner, W. Lawkins and S. Thompson, On the use of rootfinding ODE software for the solution of a common problem in nonlinear dynamical systems, to be published in Proceedings of the ICCAM (1988). [lo] G. McArthur, An introduction to the SCD graphics system, NCAR/TN-161+ lA, National Center for Atmospheric Research, Boulder Colorado (1981). [ll] ISSCO Graphics, 4186 Sorrento Valley Blvd, San Diego, CA 92121.
D. Barnett, D. Kahaner / Expert System for ODES
323
[12] IBM Personal Computer Graphical Kernal System, IBM Personal Computer Software, Number 6138807 (Nov. 1984). [13] HALO, Media Cybernetics Inc. 2042 Carroll Ave, Takoma Park MD 20912. [14] GRAPHMATIC, Microcompatibles, 11443 Oak Leaf Drive, Silver Spring MD 20901. [15] W. Chung, Automatic curve fitting for interactive display, UIUCDCS-R-75-713, COO-2382-0022, Department of Computer Science, University of Illinois at Urbana-Champaign, Urbana, Illinois 61801 (1975). [16] J. McCormack, An overview of the X toolkit, Proc. ACM Sigraph Symposium on User Interface Software (Oct. 1988). [17] S. Johnson, Yacc: Yet Another Compiler-Compiler, Bell Laboratories, Murray Hill, New Jersey 07094 (1978). [18] L. Cardelli, Building user interfaces by direct manipulation, Proc. ACM Sigraph Symposium on User Interface Software (Oct. 1988).
EXPERIENCES D. BARNETT
in Simulation
31 (1989) 315-323
WITH AN EXPERT SYSTEM * and D. KAHANER
315
FOR ODES
**
* University of the District of Columbia, Computer Science Department, Washington DC 20008, U.S.A. * * NIST, Center for Computational and Applied Mathematics, Teihnology Building, Room AISI, Gaithersburg MD 20899, U.S.A.
An Expert System can be defined “bottom up” as a software package that uses a knowledge base and inference engine, or “top down” as one that attempts to simulate the reasoning of a human expert. PLOD, a package for solving systems of ordinary differential equations satisfies the second form of the definition but not the first. We describe the major features of the package, and how we have been forced to “reinvent the wheel” in order to provide needed capabilities. Certain standard building blocks are described in the hope that these can be developed for use in other systems.
1. Introduction For the past few years we have been developing an interactive solver for the initial value problems associated with systems of ordinary differential and difference equations (PLOD). Several hundred users have helped to locate bugs and describe areas needing improvement. As far as this group is concerned, PLOD satisfies all the usual requirements for an Expert System easy to use, eliminates routine decisions by inexperienced users, and incorporates knowledge by experts in the form of program flow and access to a high quality integration engine. Nevertheless PLOD was designed ad hoc and does not utilize what software specialists would call “Expert System Technology.” This paper describes the design goals and general capabilities of the package. In particular we focus on those areas where we have had to “reinvent the wheel,” including input/output, menus, error handling, and graphics. We identify certain functions that seem likely to be commonly needed in future scientific Expert Systems. PLOD is an acronym for PLotted solutions of Ordinary Differential equations [l]. PLOD solves systems of the form
_Y’=fk Y)
037%4754/89/$3.50
0 1989, Elsevier
316
D. Barnett, D. Kahaner / Expert System for ODES
Critical ingredients of any software for exploring solutions of (1) are flexibility, interaction, and graphics. These must work together and be flexible enough to allow a user to develop his or her own route to a solution. An interactive system can be very flexible, although this is often at variance with the need to perform many thousands or millions of integration steps. Flexibility need not mean a large selection of different numerical techniques; while it is interesting for numerical analysts to compare different methods, problem solvers are usually content to allow the choice of methods to be made for them by an expert. Some other software has been developed to address the needs in this problem area. Solvers such as Phaser [4] and others are described in [5], but most of these use relatively primitive numerics and are unsuitable for difficult cases. Large scale (mainframe) simulation packages often incorporate good ODE solvers. A compendium published in “Simulation,” lists several hundred, but most are expensive and difficult to use. Few are designed to be interactive although they can be very flexible in other ways, as for example ACSL 161, or ATOMCC [7] which have also been implemented on micros. One of the earliest fully interactive systems was developed by Korn and Wait at the University of Arizona in the late 1970s [8]. There seemed to be a need for software which addressed the casual user rather than the numerical analyst, but which was of high numerical quality. PLOD has been designed with the following seven criteria (more details are given in [l]): (1) Solves 25 (or fewer) ordinary differential equations with up to 10 parameters. (2) Integration to be done while the user is at the terminal. (3) So easy to use that it will to run first try. (4) The numerical methods and their implementation should be current. (5) Rapid, flexible and attractive graphics should be integrated. (6) As portable as possible. (7) In the public domain. PLOD runs in two interactive steps, called PLOD0 and PLODl. A small “batch” program, called PLOD runs and PLOD0 and optionally will do the processing to pass the PLOD1 step. A user installs the distributed files and types PLOD. During the PLOD0 step, the user enters the functional form of the equations via a built-in screen editor. Syntax errors are noted and corrected at this time. There is no integration during this step and, in fact, no numerical values are requested at this time. PLOD0 is a preprocessor; its output is a Fortran program having the user’s equations in a form which will enable them to be integrated numerically. It also has a mechanism to communicate the names and other information to the next, or PLOD1 step. The batch program PLOD takes the output Fortran program and invokes a compiler. Upon successful compilation PLOD links to several already precompiled modules which are supplied with the package, resulting in an executable program which is then immediately executed. Running this program called the PLOD1 step. During the PLOD1 step the user is asked for values of the parameters, initial values for the dependent variables, and the interval on which the integration is to take place. After the integration the user can request various information about any combinations of variables and parameters, either through graphs or listings, can change parameter values, initial conditions, integration interval, etc., and examine results under varying conditions. Sophisticated users can alter the integrator parameters, including the integration and iteration methods, error tolerances, etc. During PLOD1 one cannot alter the functional form of the model by adding terms, or adding or removing equations. To make those changes requires returning to the PLOD0 step.
D. Barnett, D. Kahaner / Expert System for ODES
317
2. PLOD as an expert system An expert system can be viewed as a computer program that attempts to simulate the reasoning of a human expert in some limited problem domain. Accordingly, PLOD’s attempt to simulate the reasoning of an expert in writing a program to solve and plot a set of ODES qualifies it as an expert system. Because PLOD is written in a procedural language and does not have an explicit knowledge base and inference engine, some might take exception to this claim. However, in the authors’ opinion many programmers not involved in numerical work are too quick to view numerical software as strictly algorithmic without the heuristic rules one usually associates with expert system problem domains. For example, it would be naive to implement an ODE solver based upon an algorithm from a numerical analysis text; to be robust such a program must incorporate the expertise and heuristics of an experienced expert analyst. PLOD attempts to incorporate the best expertise available (algorithms and heuristics) for solving ODES. PLOD’s interface has also been developed and refined with another type of important expertise-the feedback from hundreds of users in universities, research laboratories, and industrial organizations. Being responsive to the user community has helped to give PLOD the kind of dynamic and evolving knowledge base that one associates with expert systems. There have been many instances in which user suggestions have resulted in alterations to the interface; most of these are minor. In the next section, this interface is discussed in more detail, but here we mention two significant examples of the importance of user feedback. (1) Difference equation simulation. Users asked to be able to perform the same kinds of calculations on difference equations that PLOD enabled them to perform on ODES, and this capability was then built-in. We adopted the convention that if n was used to signify the independent variable, an expression like Y’ = SIN(Y) would be thought of as referring to the equation Y, + 1 = sin Y,. In all other respects PLOD treats these systems just as if they were ODES, except, of course that “integration’ from n to n + 1 is trivial and bypasses the integrator. (2) Special events. Engineering problems are characterized by situations occuring at times that are not known in advance - motors and valves turn on and off, weapons strike targets, containers become full or empty, etc. The time sequencing of these events depends upon the solution of the system and often represents the dominant properties of the integration. Good ODE software already has the bility to determine the times at which functionals of the solution take on specified values [9], and we were able to include this in a natural way. The user invokes it by entering X + Y = Z * Z & X - Y > 0, meaning that special action is to be taken whenever X + Y = Z2, if also X is greater than Y.
3. The PLOD interface With the proliferation of personal workstations and the increase in users who are not computer professionals, user interfaces have become increasingly important. Today’s users are not tolerant of poorly designed interfaces, nor are they highly motivated to spend a large amount of time learning to use software. Instead they want interfaces that let them get started immediately (preferably without a manual). Interfaces that frustrate the user by demanding an extremely high threshold of knowledge can ruin the effectiveness of the software. Programmers
318
D. Barnett, D. Kahaner / Expert System for ODES
tend to separate the user interface and the underlying application, but users are more likely to view the application’s “look and feel” and its functionality as the same. From the end user’s point of view, an interface should be simple and consistent. Simplicity allows the beginner to easily begin “learning by example” with the absolute minimum of prerequisite documentation. This simplicity is conveyed in the way in which the user is: - informed of what the present options are and of what comes next, - directed to additional information if help is needed or requested, - told that a problem exists and how it should be addressed. Although simplicity is desirable, the interface should not stifle the experienced user. For instance, allowing commonly used commands to be entered with a minimum number of keystrokes might assist the experienced user avoid navigating through a long path of unnecessary questions. Consistency is the attempt to make as much of the interface’s behavior as possible independent of context. Thus the user can rely on certain types of behavior of the interface independent of the state of the application. This is a good way to build confidence in using the software. We do not claim to have achieved the ultimate in simplicity and consistency, however these continue to be two of our most important design objectives in the interface. From a programmer’s point of view, a user interface should be easy to assemble and encourage good software engineering through code modularity and reusability. Programming the user interface traditionally requires the same order of magnitude of effort as programming the underlying application. In the past, this has been a major obstacle to the development of “polished” interfaces. Hence schemes that encourage code reusability from one application to the next are highly desirable. Such schemes enhance productivity even more if the applications programmer can reuse this software without attention to low level details. Modularity, as used above, refers to the attempt to insulate the application from the interface. It would be ideal if modifications and adjustments to the interface could be made with minimum modifications to the underlying application. The above concerns have been the driving force behind the recent activity in user interface toolkits. In Section 5 we will describe the kind of toolkit that would have simplified the writing and maintenance of the PLOD interface.
4. Major interface components Menus play a major role. They allow user specification of problem parameters and modification of default package parameters. In addition to menus offering a finite set of explicit choices, users also need to input data directly. Hence, the menu must have error handling facilities to ensure that the right type of data is entered and that the data falls within bounds (or meets other constraints). The menu requires facilities so as to be able to set these bounds. In future versions, menus will also be used to allow more control of program flow. Menu software needs to deal with several distinct issues. First is screen presentation-what the user actually sees-as well as cursor and keystroke control. Second is menu content, how data is “fed” to the menu, what controls exist between menu choices and what restrictions can be placed on menu entries. We were unable to locate any Fortran callable menu packages for numerial applications, so we wrote one, CARTE suitable for our needs. Fig. 1 shows a typical menu presentation. At the moment that Fig. 1 was printed the menu was highlighting the line Iteration
319
D. Barnett, D. Kahaner / Expert System for ODES Title:
nTonlinc>ar
Eps:
accuracy
Max
integration
Plotting
strps
tolerance:
Frequency Connect
O:Maximum
L:Cycles
Zero:
Kewton’s Functional Pressing
nlethod
c;car’s
m&hod
order: step
5 size:
Defaulted
l.llOOOOE-15
kept
within
for non-positive to plots:
about
G:Digits
1
Newton’s
integration
dots
400
yes
integration
B:\‘ariables
Data
points:
in plot: method:
S:Maximum
l.OOOOOOE-04 warning:
I .OOOOOOE-03 percent
method:
N:Integration
Z:Problem
Equation
before
of saving points
Iteration
Add
Bifurcation
of intrgration:
bounds:
Defaulted
log plots:
4
no
integration
in displays: method iteration space
4 requires
bar
dots togglr-s
finite not
difference
and
from
is faster,
one
to the
approximations but
is unsuitable
to Jacobian for stiff
matrix. prohlrms.
other.
Fig. 1. Typical PLOD expert menu.
method: Newton’s method and also displaying the note at the bottom of the screen which provides subsidiary explanation of what this choice means. The programmer calls CARTE by passing it a menu title, the number of menu items NMENU and arrays, each NMENU in length. The ith element in each array gives information about the i-th menu item. Thus NOTES(I) contains up to 240 characters that are automatically displayed at the bottom of the screen when MENU(I) is highlighted, MTYPE(1) describes what a user is allowed to do with this item, i.e., just read the note, enter data (real, integer, string, etc.), sequence through a preselected set of choices, and so forth. BOUNDS(I) specifies whether input is to be bounds checked, and if so how. Menu entries can have some replaceable text to make them more readable. CARTE manages the cursor movement, checking input for validity, displaying menu choices, error messages, etc. Provision is also made for bounds checking that is too complicated to be done by the menu handler but must be passed back to the calling routine. In J?g. I an example of the latter occurs in the interaction between maximum allowed integration order and integration method. Parsers are used in PLOD0 and PLODl, particularly for error handling. A simple parser is used to determine whether a user-input represents a valid number, and another parses the differential equation model. One of the design objectives of PLOD is to ensure that the user is not confronted with Fortran error messages. Hence we must be able to catch the source of any syntax errors in the model and state them in terms of the differential equation model. By examining the ODES, PLOD’s model parser also identifies independent variable, dependent variables, parameters, and temporaries, and passes this information on to the Fortran program. In PLOD1 a Fortran callable parser is used in order to allow users to print or plot expressions involving the variables and parameters such as LOG(Y) + X * ALPHA. This routine is passed a string with an expression to be parsed and a list of variables. It returns a “parse-tree” description of the string and a list of the variables that were involved. A second routine can be called to evaluate the parsed string given an array of the values of the variables that are used. Knowing which variables are used in the string can be helpful in determining if additional computation is
320
D. Barnett, D. Kahaner / Expert System for ODES Select with
arrows
or Alt+first
character;
Esc
to exit
To MOVE CURSOR use Arroxs, PgUp, PgDn, Home, End To EXIT % CONTINUE use Esc, To ERASE CHARACTER ABOVE CURSOR use DEL To DELETE FROM CURSOR TO LINE END ise Ctr; and T (together) Independent variable is T Note: [________~_________~_________3-_-----____~-------___~_--------~_________
IThis is a comment!
(Apollo in Earth-Moon
orbit)
P = 1./82.45 q = 1.-P % Try initial values x=1.2, y=O, xp=O, ~~'-1.1 % Try friction term f in the range LO, 11 % Integration interval [O, 61 and plot x vs y Rl = (x+P)**2+Y**2 R2 = (x-q)**2+Y**2 X' = XP % Note use of primed variables Y' = YP XP' = 2*Y' + X - q*(X+P)/R1++1.5 - P*(X-q)/R2+*1.5 - F+X' ypJ = -2*X' + Y - q*Y/Rl++I.S - P+Y/R2**1.5 - F*Y'
Fig. 2. The appearance of the PLOD model editor.
needed before the evaluator can be called. For example, a user may want values of Y * Y + ABS(Y’). PLOD determines values of the primed variable by re-evaluating the right hand sided of the ODES - a wasteful activity if not actually required. Separating parsing from evaluation is also appropriate if the same expression is to be evaluated at many different times, as in plotting. Again we were unable to locate suitable Fortran callable software and had to write our own expression parser. PLOD has a built-in, easy-to-use screen editor for creating and editing the ODE model. There are many text editors but we were unable to find one that could be used from within a running program, even though this seems to be a facility that could be of value in many applications. Our editor uses a small subset of the capabilities of a full featured word processor-cursor movement around the screen, insert and delete characters, etc. Fig. 2 shows a typical screen as displayed by the editor on which a PLOD user will input equations. Currently editor and parser are not integrated. However, our next version will be structured so that when the parser detects a problem, control will pass to the editor with a message displayed explaining the nature of the problem and with the cursor positioned at the location of the error. It might also be possible to allow users to insert their favorite editor. Plotting is an essential feature that is available in PLOD. We were unable to loate any nonproprietary Fortran graphics software. Some quasi-public-domain software such as NCAR [lo] was available but seemed designed for batch rather than interactive graphics. Proprietary mainframe software, that has been moved to PCs, such as DISSPLA [ll] seemed to suffer from the same difficulties. Several proprietary Fortran callable libraries are available for the IBM PC family, including IBM GKS [12], HALO [13], and GRAFMATIC [14]. Each was able to satisfy our requirements, but the PLOD user needs to compile and link programs, hence the graphics library must be available to the linker. Distributing a proprietary library would violate the vendor’s purchase agreements. Furthermore, we were committed to development of public domain software, and graphics, or at least plotting, was seen as an important need. Consequently, we wrote a small set of screen plotting subroutines to be used with PLOD, which also
D. Barnett, D. Kahaner / Expert System for ODES
321
could be called (from Fortran) independently. General plotting sofware is desperately need for use with almost every type of scientific problem solving software. Plotting is very hardware dependent, but even some simple issues have not been addressed. For example, a common plotting problem is that the number of data points is either too few to generate a smooth plot or too many to be able to plot individually on a finite resolution display device. Splines or other interpolation/smoothing algorithms exist for the first situation. But the second case is also important because plotting redundant points is time consuming and wasteful. To date we have only seen one effort to deal with this [15]. Another neglected area relating to graphics “data editing.” Before sophisticated analysis or modeling can be performed a program must be given some data, typically read from files or generated internally. Most scientists will want to look at the data to get a sense of what should be expected. In the process some preliminary “eyeball” analysis may suggest that some data points ought to be deleted or transformed. The easiest way to do this via graphical interaction, in other words a graphical data editor. A software tool designed to permit such editing would be an essential part of many modeling packages. The PLOD distribution disk includes two tutorial files that explain all the details of the PLOD system. There is also some on-line help to assist the user in determining the hardware/software requirements, the capabilities of the package, and the procedures for using PLOD. There are also a few isolated help facilities for explaining the options available at specific points in the program. Experience has also shown that the tutorials are rarely read. There appears to be an inverse relationship between the amount of interaction in a piece of software and the fraction of users who will look at anything except the software. In our next version a more comprehensive set of help facilities will be implemented allowing the user to get to any specific advice at any point in the program in a consistent and comprehensible fashion.
5. The need for tools PLOD’s interface was not designed in a unified manner but evolved in response to user feedback over several years. The programming effort to develop this interface demonstrated the need for user interface toolkits to reduce the resources needed to implement, polish and maintain a user interface. These toolkits can be described as software modules “. . . used to write user interface components (‘widgets’), to organize a set of widget instances into a complete user interface, and to link a user interface with the functionality provided by an application.” [16] Although such toolkits are becoming more prevalent (especially for UNIX-based workstations), there is little available for the PC-based Fortran environment. This emphasizes the gap between software developers and users. We are in the process of designing and implementing a toolkit to address this need. What attributes should a toolkit have? A primary attribute must be the ability to create and customize “widgets” (menus, parsers, editors, etc.) via high level specifications. For example, to create a parser one might only provide a BNF specification for the grammar (YACC - Yet Another Compiler Compiler- is an example of such a tool in the UNIX/C environment which imposes “structure on the input to a computer program” [17]). Or a menu might be instantiated by providing by providing the choices available (and optionally location, color attributes, etc.).
322
D. Barnett, D. Kahaner / Expert System for ODES
The primary objective is for the application developer to be removed from the low level detail of coding the widget. Another desirable toolkit feature would allow the developer to organize a set of widget instances into a complete user interface. This could be achieved via specifications embedded in the application’s code. One drawback is that to reorganize or modify the interface, the application code must be modified. A friendlier approach is to allow the widgets to be instantiated and organized into an interface with a user interface editor. This trades off some of the low level functionality available through the application maintaining control for the ability to easily construct, modify, maintain, and customize interfaces [18]. Finally it would be desirable to use an “event-driven” programming paradigm to link the interface with the application functionality. Then the application registers event subroutines (what subroutine should be the application execute when an event occurs such as making a menu selection) with the interface and then passes control to the interface. The application is released from the responsibility of control flow (at least as it relates to interface events). This reduces the burden on the application developer and allows the interface to be modified without disturbing the application.
6. Conclusion Nonscientific software for small computers raises the standard by which scientific software is judged. Users expect a similar level in technical applications. Many proprietary scientific software products have acceptable interfaces, often implemented at great cost, but these are not available to the academic software developer. If functions of the type described in this paper can be created with standard interfaces they will make writing expert systems easier, and can also assist users who will see more uniformity in distinct products.
References [l] E. Agron, I-Lok Chang, G. Gunarantna, D. Kahaner and M. Reed, Mathematical software: PLOD, IEEE Micro, 8, 4 (August 1988) 56-61. [2] D. Kahaner, M. Reed and S. Stewart, PLOD/PC, Interactive solver for ordinary differntial equations on microcomputers, subm. J. Appl. Math. and Computing (1988). [3] D. Kahaner, C. Moler and S. Nash, Numerical Methods and Software (Prentice Hall, 1989). [4] H. Kocak, Differential and Difference Equations through Computer Experiments (Prentice Hall, 1985). [5] H. Lewis Penn, A review of differential equations software, Collegiate Microcomputer 6 (1988) 33-42. [6] Advanced Continuous Simulation Language (ACSL) Reference Manual, Mitchell and Gauthier, Assoc., 290 Baker Ave., Concord, Mass. (1981). [7] Y. Chang and G. Corliss, ATOMCC User Manual, ODE-Matic Software, 2745 Anderson Drive, Lincoln, NE 68506 (1983). [8] G. Korn, The invisible compiler, IEEE Computer (May 1983) 55-62. [9] D. Kahaner, W. Lawkins and S. Thompson, On the use of rootfinding ODE software for the solution of a common problem in nonlinear dynamical systems, to be published in Proceedings of the ICCAM (1988). [lo] G. McArthur, An introduction to the SCD graphics system, NCAR/TN-161+ lA, National Center for Atmospheric Research, Boulder Colorado (1981). [ll] ISSCO Graphics, 4186 Sorrento Valley Blvd, San Diego, CA 92121.
D. Barnett, D. Kahaner / Expert System for ODES
323
[12] IBM Personal Computer Graphical Kernal System, IBM Personal Computer Software, Number 6138807 (Nov. 1984). [13] HALO, Media Cybernetics Inc. 2042 Carroll Ave, Takoma Park MD 20912. [14] GRAPHMATIC, Microcompatibles, 11443 Oak Leaf Drive, Silver Spring MD 20901. [15] W. Chung, Automatic curve fitting for interactive display, UIUCDCS-R-75-713, COO-2382-0022, Department of Computer Science, University of Illinois at Urbana-Champaign, Urbana, Illinois 61801 (1975). [16] J. McCormack, An overview of the X toolkit, Proc. ACM Sigraph Symposium on User Interface Software (Oct. 1988). [17] S. Johnson, Yacc: Yet Another Compiler-Compiler, Bell Laboratories, Murray Hill, New Jersey 07094 (1978). [18] L. Cardelli, Building user interfaces by direct manipulation, Proc. ACM Sigraph Symposium on User Interface Software (Oct. 1988).