EP0527907A1 - Simulation system employing causal tracing - Google Patents

Abstract

In a simulation system (10) a precompiler (18) receives modeling equations from a user via a keyboard (14) and produces, for each variable in the equations, a list of variables (a " list of causes ") on which this variable depends, and another list of variables (a" list of effects ") which depends on the first variable. From the equations entered by the user, the system (10) produces a simulation program (24) which simulates a system taken as a model and produces a list of values which represent the behavior of the variables entered by the user. In response to signals from the user and identifying a particular variable of interest, a presentation module (28) retrieves the list of causes or the list of effects associated with the variable of interest and displays on a device display (16) the results of the simulation for the variables contained in the retrieved list. In this way, the user can quickly study the process.

Description

SIMULATION SYSTEM EMPLOYING CAUSAL TRACING

BACKGROUND OF THE INVENTION The present invention relates to computer simulation and in particular to presentation of the simulation results to the user in a way that facilitates his understanding of the simulated process.

Computers are employed to simulate a wide variety of systems, such as electronic circuits, weather patterns, national economies, and manufacturing plants. All simulations depend upon models, i.e., statements of relationships among the variables employed in the simulation. A variable may, for example, be the strength of a material employed, the number of hours worked, or the prime interest rate as a function of time. The model ultimately is produced by a human user, who sets forth the relationships among the variables, typically in equation form. The user may also specify the attributes of the variables, such as their dimensions (e.g., hours, pounds per square inch, meters per second) .

Models can be exceedingly complex, so software tools have been developed to facilitate the creation of models and the running of simulations of the modeled systems. Such a software tool may provide a syntax and language that facilitate the entry of the variable relationships and attributes. Once the model has been written, the software tool typically compiles the source file representing the model into a program for performing a simulation. Performing the simulation usually involves computing series of values of simulation variables as functions of an independent variable, such as time.

The obvious reason for performing a simulation is simply to predict performance, i.e., to answer questions such as, What will XYZ Corporation's revenues be for the next 18 months? In this case, the payoff variable is revenues, while the independent variable is time, as it usually is.

But a simulation may additionally be run to identify ways in which to optimize results, i.e., to answer questions such as, How much will tax revenues increase over the next five years if the enforcement budget is increased by 10%? or How much will tax revenues increase or decrease if marginal rates are reduced by 3%? The model may also be run to test the accuracy of its assumptions: If we apply our present global- warming model to data taken over the past century, does it "predict" the observed results?

In the later two instances, although the simulation provides necessary results, a large part of the problem really is to identify parameters or model relationships that should be changed in order to improve the performance either of the modeled system or of the model itself. This task largely remains in the province of the human model writer or user; in most cases, the software does not include the insight required to make such determinations. Unfortunately, the models are in many cases highly complex, consisting of thousands of equations in tens of thousands of variables, so the human user's insight often is effectively neutralized by his lack of capacity to deal effectively with the model's complexity.

SUMMARY OF THE INVENTION The present invention removes a layer of complexity from the observation of the simulated system so that the user can bring his insight more effectively to bear on solving the problem at hand. In accordance with the present invention, the simulation system prepares cause and/or effect lists from the relationship-defining equations. Each equation specifies a relationship between an "effect" variable and one or more "cause" variables. In accordance with one aspect of the invention, the simulation system inspects the equations and, for each variable that shows up as a cause variable in at least one equation, prepares an effect list, i.e., a list of the effect variable in each equation in which that variable is a cause. In accordance with another aspect of the invention, the simulation system prepares a cause list; i.e., for each effect variable, it prepares a list of the cause variables in the equation in which that variable is the effect.

During the simulation, the simulation program must necessarily determine the values of the various cause variables in order to determine the value of the payoff variable, which it typically displays to the user. In accordance with one aspect of the present invention, the user can investigate the causes of the displayed variable—or, typically, of any other variable—by simply identifying the variable and entering a command that its causes be shown; he does not need to identify the cause variables explicitly. Instead, the simulation system consults the cause list for that variable and displays the determined values for the variables in the identified variable's cause list. In accordance with the other aspect of the invention, the user can investigate effects in a similar manner.

These facilities greatly expand the user's ability to investigate the model, and they free him to bring his insight to bear on the investigation; in tracing causes for various effects in the simulation, the user is not distracted by the need to search through the source program to identify cause variables or, once those variables have been identified, to double-check that he has found them all and then to call up the simulation results for each of them separately. The user can thus deal with a considerably higher level of complexity than he could without the causal-tracing facility.

BRIEF DESCRIPTION OF THE DRAWINGS

These and further features and advantages of the present invention are described below in connection with the accompanying drawings, in which:

FIGURE 1 is a block diagram depicting the performance of a system that employs the teachings of the present invention;

FIGURE 2 is a display of the causes of one of the variables involved in a simple simulation; and FIGURE 3 is a display of the effects of that variable.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT The drawing depicts in diagrammatic form a system that embodies the teachings of the present invention. Such a system typically includes a computer, which the drawing represents with dashed lines 12. The computer is programmed with software modules, described below, represented by blocks 18, 20, and 28. The computer is coupled to an appropriate input device such as a keyboard 14 by which a user can enter a simulation model and otherwise interact with the programs that the computer runs. A display device 16 displays the results of the simulation, and it is typically used for other purposes, too, such as to reflect the entries that the user makes by way of the keyboard 14.

Among the computer*s software modules is a pre¬ compiler 18. The pre-compiler 18 is the programming that enables the computer 12 to perform a number of functions having to do with the appropriate interpretation of the information that the user enters by way of the keyboard 14. The entries made from the keyboard 14 are ultimately compiled into object code—i.e., machine-language instructions—and I call module 18 a pre-compiler here because it typically does not perform all of the compiling function, although this is not a necessary feature of the invention.

The user enters equations in accordance with a simulation language that the pre-compiler 18 is designed to recognize. Most embodiments in which the pre-compiler does not perform the complete compiling process will employ a general-purpose computer language, such as C, for much of the operation. The pre-compiler in such arrangements would convert the user's input into, say, the C language for compiling by a compiler 20. The pre-compiler may additionally create symbol tables that appropriately store various descriptive information that the user enters concerning the variables. For instance, the user typically enters dimensions (e.g., dollars, gallons/minute, workers, etc.) and any comments that he considers it desirable to enter. It is the job of the pre-compiler to interpret all this information correctly and store it properly for its intended use.

In accordance with the present invention, the pre-compiler 18 additionally parses the user-entered equations to create cause lists, effect lists, or both, and store them in a part of the computer's memory appropriate for storage of the cause and effect lists 22. A cause list for a given variable contains those variables that are direct causes of the given variable, while an effect list for a given variable contains the variables that are the immediate effects of the given variable.

To illustrate this operation, we will set forth an example of how a user might create a simple simulation. The user might request from his computer that it run a simulation-environment program, which might cause the computer to present to the user a display image including, for instance, various icons, "buttons," and menus. To indicate that he wishes to create a model, the user might employ an input device such as a mouse to cause a display cursor to move to a button labeled "file" and then "drag" that button's icon to a menu item labeled "new" to indicate that he wishes to create a model. In response, the simulation environment would typically activate an editor routine.

At this point, the user may begin with entries such as the following:

CLIENT: MARY, JOHN ~ nil " The list of people who have bank accounts. |

This is a preliminary statement. The colon indicates that the variable at the left of it is a subscript variable whose values can be any of those at the right of the colon. We will then assume that the particular model-writing language employed requires, for each such entry, two tildes and a vertical line; the first tilde represents the beginning of a dimension-entry field, the second tilde represents the beginning of a comment- entry field, and the vertical line represents the end of the current entry.

After the initial entries, the user may then enter the model, which represents activity in a bank account:

BALANCE[CLIENT] = INTEG(MONEY_IN[CLIENT] - MONEY_OUT[CLIENT] , INITIAL_BALANCE[CLIENT]) dollars The total money in the bank balances of the clients.

I

MONEY_IN[CLIENT] = INTERES [CLIENT] + DEPOSITS[CLIENT] dollars/week

The total money in each account at the start of a simulation.

MONEY_OUT[CLIENT] = WITHDRAWALS[CLIENT] + FEES[CLIENT] dollars/week The total money leaving the bank account each time peri

I

INITIAL_BALANCE[MARY] = 700"

I INITIAL_BALANCE[JOHN] = 700 dollars

The initial money in each account at the start of a simulation.

I

INTEREST[CLIENT] =^'BALANCE[CLIENT] * INTEREST_RATE[CLIENT] dollars The interest payment received.

I

INTEREST_RATE[CLIENT] = FIRST_IF_TRUE(BALANCE[CLIENT] <1500, LOW_INTEREST_RATE, HIGH_INTEREST_RATE) / 100 dimensionless " The fractional rate of interest, which depends on the amount of money in the bank.

I

LOW_INTEREST_RATE = 8.00 dimensionless " The interest rate in percent if the balance is below $1,500.

I

HIGH_INTEREST_RATE = 9.00 dimensionless " The interest rate in percent if the balance is above $1,500.

DEPOSITS[MARY] = 600 "

DEPOSITS[JOHN] = 450 dollars/week " The weekly salaries deposited into their accounts.

I

WITHDRAWALS[MARY] = 475 "

I WITHDRAWALS[JOHN] = 300 dollars/week

The amount of money taken out of the account each week

I

FEES[CLIENT] = FIRST_IF_TRUE(BALANCE[CLIENT] <1000, 0.50,0) ~ dollars/week

~ If the balance goes below $1000, a $2 per month fee is charged. |

The first entry in the simulation defines relationships wo variables. Since the subscript CLIENT can have two values, namely, MARY and JOHN, the first entry essentially represents two equations, one in which the value of the subscript in all of the subscripted variables is MARY and the other in which it is JOHN.

The first statement specifies that the BALANCE at any given time is the sum of an initial value

INITIAL_BALANCE[CLIENT] and the integral of the difference between MONEY_IN[CLIENT] and MONEY_OUT[CLIENT] between some initial time to the given time. As before, the entry after the first tilde represents the dimensions (dollars) , and the entry after the second tilde is a comment explaining the meaning of BALANCE[CLIEN ] . Note that the effect variable for this entry is BALANCE[CLIEN ] , while the cause variables are MONEY_IN[CLIENT] , MONEY_OUT[CLIENT] and

INITIAL_BALANCE[CLIENT] . Again, the vertical line indicates the end of the entry for BALANCE[CLIENT] .

The next entry defines a relationship between the variable MONEY_IN[CLIENT] and the variables INTEREST[CLIENT] and DEPOSITS[CLIENT] . The entry indicates that MONEY_IN has the dimension dollars/week and explains that MONEY_IN is a rate.

The next entry defines MONEY_OUT as the sum of the variables WITHDRAWALS and FEES.

Unlike the first three entries, each of which actually represents two equations, the next entry represents only one equation; it uses as a subscript the constant MARY rather than the variable CLIENT. The fifth entry similarly represents only one equation. In accordance with the syntax of the model- writing language, the dimensions and comments for two variables that differ only in subscripts can be written in common, even though their equations are entered separately, and this is the result of following the first equation simply with two tildes and a vertical line but following the second equation with a dimension and a comment.

The sixth entry, the one for INTEREST[CLIENT] , is self- explanatory. The seventh entry describes a two-level interest rate. It states that INTEREST_RATE[CLIENT] takes on the value of LOW_INTEREST_RATE/100 if the BALANCE[CLIENT] is less than $1,500 and is equal to HIGH_INTEREST_RATE/100 otherwise.

In response to the foregoing equations, the pre-compiler generates the following cause lists:

BALANCE[ ARY] : MONEY_IN[MARY] , MONEY_OUT[MARY] , INITIAL_BALANCE[MARY]

BALANCE[JOHN] : MONEY_IN[JOHN] , MONEY_OU [JOHN] , INITIAL_BALANCE[JOHN]

MONEY_IN[MARY] : INTEREST[MARY] , DEPOSITS[MARY]

MONEY_IN[JOHN] : INTEREST[JOHN] , DEPOSITS[JOHN]

MONEY_OUT[MARY] : WITHDRAWALS[MARY] , FEES[MARY]

MONEY_OUT[ OHN] : WITHDRAWALS[JOHN] , FEES[JOHN]

INITIAL_BALANCE[MARY]:

INITIAL_BALANCE[JOHN] :

INTEREST[MARY] : BALANCE[MARY] , INTEREST_RATE[MARY]

INTEREST[JOHN] : BALANCE[JOHN] , INTEREST_RATE[JOHN]

INTEREST_RATE[MARY] : BALANCE[MARY] , LOW_INTEREST_RATE,

HIGH_INTEREST_RATE

INTEREST_RATE[JOHN] : BALANCE[JOHN] , LOW_INTEREST_RATE,

HIGH_INTEREST_RATE)

LOW INTEREST RATE: HIGH_INTEREST_RATE:

DEPOSITS[MARY] : _

DEPOSITS[JOHN] :

WITHDRAWALS[MARY] :

WITHDRAWALS[JOHN] :

FEES[MARY] : BALANCE[MARY]

FEES[JOHN] : BALANCE[JOHN]

Each list corresponds to a different effect variable, and it lists the variables that are its immediate causes. A review of the cause lists indicates that each corresponds to a single equation. The reason for this is that each effect variable is an effect in only one equation, and that equation therefore lists on the right side of the equals sign all of the variables that are causes of the variable on the left side.

The pre-compiler may additionally generate effect lists. The effect lists for the model described above are as follows: MONEY_IN[ ARY] : BALANCE[MARY]

MONEY_IN[JOHN] : BALANCE[JOHN]

MONEY_OUT[MARY] : BALANCE[MARY]

MONEY_OUT[JOHN] : BALANCE[JOH ]

INITIAL_BALANCE[MARY] : BALANCE[MARY]

INITIAL_BALANCE[JOHN] : BALANCE[JOHN] INTEREST[MARY] : MONEY_IN[MARY]

INTEREST[JOHN] : MONEY_IN[JOHN]

DEPOSITS[MARY]: MONEY_IN[MARY]

DEPOSITS[JOHN] : MONEY_IN[JOHN]

WITHDRAWALS[MARY] : MONEY_OUT[ ARY]

WITHDRAWALS[JOHN] : MONEY DUT[JOHN]

FEES[MARY] : MONEY_OUT[MARY]

FEES[JOHN] : MONEY_OUT[JOHN]

BALANCE[MARY] : INTEREST[MARY] , INTEREST_RATE[MARY] , FEES[MARY]

BALANCE[JOHN] : INTEREST[JOHN] , INTEREST_RATE[JOHN] , FEES[JOHN]

INTEREST_RATE[MARY] : INTERES [MARY]

INTEREST_RATE[JOHN] : INTEREST[JOHN]

LOW_INTEREST_RATE: INTEREST_RATE[MARY] , INTEREST_RATE[JOH

HIGH_INTEREST_RATE: INTEREST_RATE[MARY] , INTEREST_RATE[JO

The effect lists do not have one-to-one correspondences to model equations; each list can have contributions from more than one equation. For instance, the effects of BALANCE[CLIENT] are INTERES [CLIENT] , INTEREST_RATE[CLIENT] , and FEES[CLIENT] , as the pre-compiler infers from the equations that have those variables on the left side of the equals sign.

The remaining entries are self-explanatory in light of the foregoing discussion.

Reflection reveals that, although time is never explicitly mentioned as an independent variable in the foregoing equations, the first equation invokes it implicitly, and many of the variables consequently are functions of time. Specifically, since the first equation invokes the function INTEG, which represents valuation of a definite integral whose upper limit depends on time, BALANCE[CLIENTS] is a function of time. Since the variable FEES[CLIENT] depends on BALANCE[CLIENT] , it also is time-dependent, as are INTEREST_RATE[CLIENT] , INTEREST[CLIENT] , MONEY_OUT[CLIENT] , and MONEY_IN[CLIENT] .

The purpose of the simulation program to evaluate the various variables at successive values of the independent variable, which is typically assumed to be time. Accordingly, the simulation language will typically have variables reserved for this function, and the user may give them values in the following manner:

FINAL TIME = 1995 year The final time for the simulation.

J INITIALJTIME = 1990 year

The initial time for the simulation.

I

TIME_STEP = 1/52 year The time step for the simulation a week of time.

I

SAVEPER = TIME_STEP year ~ The frequency with which data is stored.

I

The first two entries tell when, in simulated time, the simulation is to start and stop. The third entry specifies that the simulation is to make successive calculations in steps of one week of simulated time. The user may not be interested in the results of each week however; he may instead be interested only in the results of each year. In such a situation, the simulation would not need to retain the weekly results for display purposes, and it could discard them as soon as they are no longer needed for subsequent calculations. In the illustrated example, however, the user wants to see all of the results, and the fourth entry, which specifies that the save period is equal to the time step, gives this information to the simulation routine.

As was suggested above, the illustrated embodiment uses a separate compiler. Use of a separate compiler is not a requirement, since the "pre-compiler" 18 could in theory be a program for making a direct conversion from the user's modeling language to the machine language employed by the computer hardware. In the typical case, however, an intermediate compiling step (or, equivalently, an intervening interpreting step for an interpretive system) would be employed because it makes writing the pre-compiler 18 easier. The output of the compiler 20 is machine code for the simulation program 24, which the user requests that the computer 20 run.

The output of the simulation program 24 is simulation results 26, which include the values of one or more variables, typically as a function of time. In the foregoing example, the payoff variables are BALANCE[MARY] and BALANCE[JOHN] . In order to determine those values, the simulation program must additionally determine the values of intermediate-cause variables in all but the simplest of simulations. The sequences of values of these variables also form part of the simulation results 26, all of which are stored in an appropriate part of the computer memory. To display one or more payoff functions to the user, a presentation module 28 fetches the values from the results section of the memory and generates from them an appropriate display, such as a graph. If the payoff variable in the illustrated example is the variable BALANCE[MARY] , the presentation program 28 typically begins with a display of that variable. As was indicated above, however, it is often important for the user to know more than the behavior of the payoff variable; it may be important to understand why the payoff variable behaves as the simulation indicates that it does.

In the simple case depicted in the tables, the reasons for the behavior of the payoff variable BALANCE[MARY] are relatively apparent; one needs only to inspect the modeling equations to determine the reasons for its behavior. To gain a further understanding, one might even arrange to display the results for the particular variables that a perusal of the input equations has indicated are important. For complex systems, however, this approach is extremely difficult; although the problem is the same in principle, it proves in practice to be so time-consuming and tedious as to obscure the overall relationships that the approach is intended to reveal.

In accordance with the present invention, however, the presentation module 28 has a feature that greatly facilitates the user's study of the simulated system. According to the present invention, the user can simply identify the variable whose causes he wishes to see, and the system will display the cause variables without the user's having had prior knowledge of their identities.

Specifically, the presentation module responds to a request from the user for the causes of a given variable by fetching from the cause and effect lists 22 the cause list for the given variable and then fetching the results 26 for the entries in that cause list. The presentation module 28 then operates the display 16 so as to display these results to the user, who is thereby relieved of the tedium of studying the modeling equations to identify the variables of interest and then requesting that those variables be displayed. For example, suppose that the payoff variable that the user wants to investigate is BALANCE[MARY] . At the end of the simulation run, the simulation program may present a variable-selection list, and the user chooses BALANCE[MARY] from that list. The program may also display a "toolbox," i.e., a group of icons representing different investigative functions. By, for instance, using a mouse to "click on" the icon representing presentation of cause variables in graph form—without explicitly identifying the cause variables—the user can obtain a display such as that depicted by FIGURE 2. That drawing shows graphs of BALANCE[MARY] and of its two cause variables MONEY_IN[MARY] and MONEY_OUT[MARY] as well as a non-graphic indication of its constant cause, INITIAL_BALANCE[MARY] .

In a complex simulation, such a capability can greatly enhance the user's appreciation of the process and, in some cases, make it possible to see features that would otherwise be lost because the user is distracted by the task of searching through the modeling equations.

In addition to tracing the trail of causation "backward" in this way, the user is also able to trace "forward." If, for instance, the user encounters a variable whose behavior seems anomalous or counterintuitive, he may want to see what variables the variable in question affects. He may also know of a variable for which he is not particularly confident of his data, and he may want to trace forward to see what the major effects of any errors are likely to be. In such cases, the user identifies the variable in question to the presentation module 18 and indicates that he would like to see its effects displayed. In response, the presentation module 28 fetches from the cause and effects lists 22 the entries in the effect list for the variable in question, fetches the results for the listed variables, and displays those results on the display 16. For instance, the user requests that the program display the effects of BALANCE[MARY] , the resultant display may be similar to FIGURE 3, which graphs BALANCE[MARY] and its effect variables FEES[MARY], INTEREST[MARY] , and INTEREST_RATE[MARY] .

By employing a system of this type, the user can obtain considerable insight into the operation of complex systems. The present invention thus constitutes a significant advance in the art.

Claims

A simulation system comprising:

A) means adapted to receive signals representing relationships among variables in the forms of equations, each of which states the dependency of an effect variable on one or more cause variables;

B) means for creating for each effect variable a cause list, associated therewith, of the cause variables on which the equation in which it was used states its dependence;

C) means for performing a simulation by determining the values assumed by the effect variables for each of a succession of values of an independent variable in accordance with the entered equations; and

D) causal-tracing means, adapted for reception of a signal identifying an effect variable, for displaying as a function of the independent variable the values, determined during the simulation, of variables in the cause list associated with the identified effect variable.

A simulation system comprising:

A) means adapted to receive signals representing relationships among variables in the forms of equations, each of which states the dependency of an effect variable on one or more cause variables;

B) means for creating for each cause variable an effect list, associated therewith, of every effect variable whose dependence on that cause variable at least one equation states;

C) means for performing a simulation by determining the values assumed by the effect variables for each of a succession of values of an independent variable in accordance with the entered equations; and means, adapted for reception of a signal identifying a cause variable, for displaying as a function of the independent variable the values, determined during the simulation, of variables in the effect list associated with the identified cause variable.