WO2001001206A2 - System dynamics model builder and simulator - Google Patents

Abstract

A system dynamics modeling environment has a graphical user interface to allow a model developer to define a model through graphical inputs, for example by selecting icons and dragging them onto a representation of a flow diagram. The data and other information regarding a particular model are stored within a database structure that efficiently organizes the data. A second non-graphical editor is provided as a separate and distinct tool for editing the equations and other information representative of a model. The system dynamics modeling environment allows the definition of a plurality of groups, with each group consisting of a data set representing a complete flow diagram and capable of being coupled to another group defining a portion of the model on the same layer of the model. An efficient simulation environment is provided that determines which groups within a model are active and performs simulations only on those active groups. Users will also have the ability to create customized user interfaces, or 'dashboards' for their models, without requiring programming experience. Users also have access to features that make it easy to create and save scenarios and models.

Description

SYSTEM DYNAMICS MODEL BUILDER AND SIMULATOR

COPYRIGHT NOTICE:

A portion of the disclosure, including the drawings, of this patent document

contains material subject to copyright protection. The copyright owner has no objection

to the facsimile reproduction by anyone of the patent document or the patent disclosure,

as it appears in the Patent and Trademark Office patent file or records, but otherwise

reserves all copyright rights whatsoever.

PRIORITY:

This application claims priority from U.S. provisional patent application Serial

No. , filed June 30, 1999, which application is hereby incorporated by

reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to systems, methods and products for developing

and executing system dynamics models.

2. Description of the Related Art System dynamics and system dynamics modeling provide tools for analyzing

complex systems. For example, system dynamics modeling has been applied to

biological systems including the production and regulation of insulin within a human

body, to educational processes including modeling how students learn, to social systems

including modeling the relationship between crime and drug availability, and to a variety

of economic and business situations. By applying the principals of system dynamics,

computational models with qualitative and, often, quantitative accuracy can be developed

and can be used to gain an understanding of the modeled system. Even when a model is

highly schematic, insights can be drawn simply because the system dynamics model

adequately represents the structure and relationships among elements of a system. Causal

relationships that are not evident in a static model can become apparent in a system

dynamics model.

Once an accurate system dynamics model is developed, the model can be used to

perform computer-based experiments and simulations to evaluate changes in structure

and in the coupling between structures, and how varying the initial conditions or input

variables affect the system. For example, control mechanisms such as rules or policies

can be tested on a system dynamics model to determine if the control will have the

desired effect and whether the control is likely to be cost effective or advantageous.

What has allowed system dynamics modeling to be applied to such diverse

problems is the generality of the system dynamics methodology. In developing a system

dynamics model, a model developer breaks down the system or problem to be analyzed

into constituent elements and defines the relationships among the various elements of the

system or problem. To the extent possible, the model developer attempts to define a model in terms of fundamental constituent elements so that the model is as simple as

possible while still having an appropriate level of structural detail. One way in which

fundamental elements can be characterized is by identifying the minimum set of variables

that describe the system. The relationships among the fundamental elements are

translated into the relationships among the variables that describe the system.

Relationships between any two elements can be defined functionally, that is in the form

of an equation, or empirically, for example using a table listing an observed set of

relationships.

Within the system dynamics literature, variables that describe the state of the

system are sometimes referred to as "stocks" or "levels" and the relationships between levels are defined in terms of "flows" or "rates." Another concept typically included in

system dynamics models is that of an "auxiliary," which receives input data and converts

or manipulates that input data to provide output data. "Connectors" are often used to

illustrate graphically the flow of information among stocks, flows and auxiliaries. One fundamental aspect of system dynamics is the explicit consideration of time

in the model. Most all of the relationships among variables are time varying, which is a

characteristic of system dynamics modeling that allows its models to represent real world

systems. Simulating a system dynamics model causes the model to advance through a

series of time steps, with many of the variables changing with each time step. Because time is explicitly considered along with the relationships among different variables,

feedback and environmental effects are an important aspect of system dynamics models. Using a system dynamics model allows the impact of changes in a variable to be

observed, whether to evaluate the accuracy of a model or to understand the impact that changes in the system variables have on the system as a whole. Graphs of system

variables allow aspects of the system to be monitored, illustrating both transient behavior

and steady state behavior, if it exists.

System dynamics models present a multivariable view of a system, focusing both

on the constituent elements of the system and the interaction among those elements.

Variables interact with one another due to a variety of feedback mechanisms, causing the

values of the variables, and thus the response of the system as a whole, to change over

time. Instead of focusing on the independent activity of isolated sub-units, system

dynamics attempts to model the structure of the entire system, the interaction among

variables in the structure and the way that this interaction changes the variables over time.

In this way, the behavior of complex systems can be modeled as a function of time to

provide a tool for understanding the system. Further, analysis of structural changes in

part of the system can be observed to determine their effect on the system as a whole.

Conventional model optimization is proscriptive, in that an initial goal is set and

the model is tested under various conditions. The set of conditions that comes closest to

the predetermined goal is deemed to be the "optimal solution." On the other hand,

system dynamics simulations tend to be more descriptive, in that the initial conditions are

set and the computer determines what would happen to the system over a particular time

interval. System dynamics simulations are thus far more often "what-if ' models. This

does not necessarily preclude system dynamics models from being used for forecasting

discrete events. Developing a validated, predictive system dynamics model capable of

such prediction requires a significant level of testing, observations and adjustments to reach accuracy. Once such a model is developed, though, it can be used to predict system

response with good reliability.

A system dynamics model typically represents a set of linear and non-linear

relationships among variables, with many of the relationships mathematically defined as

differential equations or difference equations. These equations are integrated over time to

generate a simulation. Stepping or cycling the model through time conventionally

requires that all of the equations that make up the model be approximated or solved in

each time interval or step. The complexity of these models requires the use of computers

to fully understand the effect of changes to all but the very simplest of systems.

Consequently, system dynamics models are implemented in computer systems, with

complex models testing the limits of conventionally available computer systems.

Construction and simulation of system dynamics models involves: (i) developing

a model structure that is representative of the physical system relevant to the problem,

including defining the variables that are representative of the system, (ii) defining the

behavior of variables in the system, which are essentially a set of decision-making rules,

(iii) setting imtial conditions for the variables of the model, (iv) running the simulation

for a specified time period or number of cycles to determine the overall change in

behavior of the system, (v) testing the model by comparing it to observations, and (vi)

modifying the model, as required. Tests of the model determine its validity or relevance

and hence its usefulness. Tests might include model causal tests and model behavior

tests. For instance, if a simulation of a population model shows a negative living

population level when run for a particular time period, the model needs to be adjusted

because it produced an outcome that is not physically possible. In developing a system dynamics model, the boundaries of the system to be

modeled are established to encompass the identified problem. Defining the boundaries of

the problem is significant, in that the model developer selects structures and functions to

include as being determinative of system behavior and selects other structures and

functions not to include because they are not sufficiently important. The structures and

functions to be modeled are associated with variables and relationships. Because system

dynamics models tend to be computationally intensive, it is preferable to tailor the model

precisely while still leaving sufficient detail to accurately represent the system. The

result of this model conceptualization stage may be a simplified flow or causal loop

diagram representing the variables of a system with their interrelationships.

Next, the diagram is translated into a computer useable form. This is generally

accomplished with a program specifically developed for system dynamics modeling.

When model definition produces a flow diagram, translating the model into a computer

executable model is most easily accomplished through a graphical user interface. There

are presently a few software products for system dynamics model construction and

simulation on the market that provide a graphical user interface in which a flow diagram

can be entered graphically in a workspace so that the flow diagram is reproduced on the

screen of a computer. For instance, "STELLA" (System Thinking Educational Learning

Lab with Animation) available from High Performance Systems, Inc., Powersim

"Constructor" from Powersim, and "VENSLM" from Ventana Software are examples of

icon-driven system dynamics modeling tools. These programs allow a model developer

to define a system dynamics model in terms of a flow diagram entered into the computer

graphically. STELLA, and to a lesser extent, Powersim Constructor, are designed primarily to support the construction and simulation of relatively small system dynamics

models that can be simulated in a reasonable amount of time. As such, they tend to be ill-

suited to storing and executing large models, i.e., those with thousands, or tens of

thousands, of equations and array elements.

Another product, "DYNAMO" is capable of running large models, but lacks the

graphical, model-building capability and other features related to ease of use. Moreover,

while this program has advantages for large model definition, the program's simulation

engine is based on decades-old programming technologies and is therefore slow as

compared to, for example, Vensim, as a platform for running large models. In addition, a

user must have a knowledge of Visual Basic, C++ or a similar programming language to

develop a professional-looking interface with DYNAMO. This restriction limits a user's

ability to design and create decision support and other software applications that can be

used by third parties who do not possess a detailed understanding of how the simulation

software itself functions. This is true of Powersim, Vensim, and STELLA as well. While

these programs do provide rudimentary interface building capabilities, users without

programming capabilities cannot create professional, packaged applications with these

software programs.

There is a growing interest in the use of system dynamics modeling to model

business situations and to inform decision making in complex environments. Tools are

needed to facilitate the creation and rapid simulation of large system dynamics models.

Such tools should require little or no programming knowledge of the user, have a user-

friendly graphical interface, provide user presentation development tools and have a fast

simulation engine for rapid modeling of complex systems. In addition, the results of model development should be available to persons who use the models, without

modification or programming efforts. As such, it is desirable to provide a system

dynamics modeling environment with features for providing end users with a graphically

driven model that is capable of easy adjustment of variables and displays and which does

not require further modeling or skilled interaction.

SUMMARY OF THE PREFERRED EMBODIMENTS

According to one aspect of the present invention, a system dynamics modeling

environment for building a system dynamics model includes a group of model definition

elements. The environment may include means responsive to user selection of a plurality

of model definition elements for the group, means responsive to user selection for defining

the hierarchical structural relationship of the model definition elements in the group,

means responsive to user selection for defining the quantitative relationship of one model

definition element to another model definition element in the group, and means for

copying a model definition element from a first group to a second group.

Another aspect of the invention may provide a computer program in a computer-

readable media for use in a computer to build a complex system dynamics model using a

plurality of discrete, hierarchical system dynamics groups. Each group provides a set of

interactive model definition elements, where the dynamic relationship among the model

definition elements of all groups in the system model defines the structural and

quantitative relationship among the variables that comprise the system model. The

computer program may provide means responsive to user selection of a plurality of

system dynamics groups. Means are provided for hierarchically arranging the groups in a system dynamics model structure and means are provided for copying a variable and its

properties from a first group to a second group. The computer program also provides

means for defining the dynamic relationship among the groups to describe the effect of

changes within the group on the system model and the effect of system changes on the

group.

Still another aspect of the model provides a method of building a complex system

dynamics model using a plurality of discrete, hierarchical system dynamics groups, with

each group having a set of dynamically interactive model definition elements. The

dynamic relationship among the model definition elements of all groups in the system

model defines the structural and quantitative relationship among the variables that

comprise the system model.

The method preferably includes steps such as configuring a system dynamic

structure to be modeled by selecting a set of system dynamics groups and hierarchically

arranging the groups in a structure. The method allows the copying of a variable from a

first group to a second group. The dynamic relationship among the groups is defined to

describe the effect of changes within the group on the system model and the effect of

system changes on the group.

Still other embodiments of the invention provide a system dynamics modeling

tool having a graphical interface for inputting a flow diagram representation of one or

more system dynamics model elements. The tool includes a definition facility, linked to

the graphical interface and accessible from the flow diagram representation, for defining

one or more characteristics of a model element. The graphical interface is adapted to

accept input to define a first group and assign the first group a name, and to define a second group and assign the second group a name. The graphical interface is further

adapted so that a flow diagram display of the first group shows an input from the second

group as an indication of a common variable shared between the first and the second

group. Most preferably, the input is represented in the flow diagram in a manner visibly

different from like relationships entirely within the first group.

A compiler for the tool receives as input the variables and equations within the

model and operates on the variables and equations to ensure that a definition exists for

each of the variables and equations in the model, the compiler generating an error

message if a variable or equation is undefined. A compiler receives as input a plurality of

variables determined by operation of a corresponding plurality of equations, the compiler

operating to identify a first subset of the plurality of variables that do not vary in a given

time and to identify a corresponding first subset of equations. The tool further includes a

simulator to solve equations at each of a plurality of defined time intervals over a length

of a simulation, the simulator calculating a second subset of equations at each of the

plurality of time intervals and calculating the first subset of equations at fewer than the

plurality of time intervals.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a flow diagram view in accordance with an embodiment of the

present invention.

FIG. 2 illustrates a variable properties box in accordance with a preferred

embodiment of the present invention. FIG. 3 illustrates a chart generated in accordance with a preferred embodiment of

the present invention.

FIG. 4 illustrates a view of the navigator screen in accordance with an

embodiment of the present invention.

FIG. 5 provides a view of a dashboard screen in accordance with a preferred

embodiment of the present invention.

FIG. 6 shows an exemplary table of the icons within the application toolbar of an

embodiment of the present invention.

FIG. 7 shows a table of icons for a control toolbar in accordance with an

embodiment of the present invention.

FIG. 8 shows an implementation of aspects of the present invention within a

computer environment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Preferred embodiments of the present invention provide a system dynamics

modeling environment with a graphical user interface that allows a model developer to

define a model through graphical inputs, for example by selecting icons and dragging

them onto a representation of a flow diagram. Most preferably, graphically input data

and other information regarding a particular model is stored within a data structure that

efficiently organizes the data. Such a data structure is preferred for the organization it

provides to model development and because the database organizes and expedites the

compilation and execution of the model. Certain preferred implementations of a system dynamics modeling environment

allow the definition of a plurality of groups, with each group consisting of a data set

representing a complete flow diagram and capable of being coupled to another group

defining a portion of the model. Variables within a group may be defined solely within

the group or may be shared with one or more other groups. Thus, when a model including

at least two groups is compiled, the compiler recognizes the presence of a shared variable

within the two groups and links the two groups together. As with conventional system

dynamics programs, it is possible in the preferred modeling environment that individual

variables on a layer may contain within them one or more layers of sub-functions or

models, with each layer defined by a flow diagram and with variables shared or passed

between the layers. The group structure provided in preferred embodiments of the

present invention is in addition to such a multilayered structure.

The present invention may be embodied as a computer program product including

some or all of the preferred methods that facilitate the construction and simulation of

large system dynamics models that might include thousands of equations and array

elements. A fast, efficient simulation engine enables certain particularly preferred

embodiments of the present invention to combine the ease of use of graphical interfaces

with the computational power to simulate large, complex system dynamics models. This

is believed to provide a significant advantage to the application of system dynamics

methodology to increasingly complex systems while also allowing the end products of

modeling to be cost-effectively delivered with familiar and easy to use interfaces.

Preferred implementations of the present invention provide a graphical editor to

facilitate the entry of data sets, relationships and structures for very large system dynamics models. Thus, as is illustrated in FIG. 1 , a computer display may show a

representation of a flow diagram. Structures on the flow diagram can be relocated using

typical graphical editing tools, including cut and paste functions and drag and drop

functions. Such a graphical editor is greatly preferred as allowing the rapid definition of

the relational aspects of a system dynamics model. Variables, relationships and

interconnections can be easily defined using familiar graphical editing techniques and a

natural representation of a flow diagram.

Variable definitions can be directly entered from variable definition dialog boxes

accessible from the graphical user interface. For example, a first and a second level

variable might be placed on a flow diagram using the graphical editor. Rate variables

could then be defined and connectors could be placed between any of the level variables

and the rate variables. Characteristics of the level variables and the rate variables could

be entered directly within the graphical editing environment by clicking or otherwise

selecting each variable in turn to access the variable definition dialog box associated with

each of the variables. Placement and definition of the variables in this way, including the

definition of the relationships among the variables, allows for a natural and interactive

modeling environment that facilitates the easier development of models.

Consequently, preferred embodiments of the present invention incorporate a text

editor that operates in conjunction with the graphical model definition editor. The text

editor provides a mechanism for creating a model without the use of graphical icons.

When writing equations or otherwise defining aspects of a model in the text editor, a user

specifies the relationships among variables or otherwise characterizes the model using

only text. Thus, the graphical user interface can be used to define the model in ways best suited to graphical manipulation, such as overall structural layout, and the text-based

variable definition editor can be used to define aspects of the model most appropriate to a

textual or equation processing interface. A user in the modeling environment preferably

automatically creates the variables in graphical form and displays the variables in a

separate flow diagram window. Any variables or functional relationships created

graphically will show up in the text editor. Once the variables and equations are created,

the user has a choice of editing aspects of them and their relationships directly in either

the graphical or text editor.

A distinct aspect of certain preferred embodiments of the invention is a model

builder "navigator" interface that is most preferably distinct from and in addition to the

graphical interface with graphical and text editor capabilities. The "navigator" interface

is complementary to the graphical and text editors and provides a model developer with

model elements in a hierarchical, tabular or chart-like display so that the developer can

easily store, locate, and retrieve major model components, such as groups, variables,

plots, equations and macros. The navigator feature allows a developer the ability to view

and edit a substantial quantity of data in an organized format. For example, the model

developer might use the navigator to view the relationships among a number of variables

and access the equation variable dialog boxes that define the relationships among the

variables. Such editing can be difficult using a standard, single window graphical

interface, and is greatly facilitated using the navigator function. It is particularly

preferred that the system dynamics modeling environment provides a navigator interface

in addition to the text and graphical editing capabilities. Certain particularly preferred embodiments of the present invention provide

advanced compiler and simulator functions that significantly reduce the time it takes to

simulate large models. The use of advanced compiler and simulator functions reduce the

time it takes to develop and test models and allow a greater number of tests and model

variations, also known as scenarios, to be considered in a practical manner. Another

preferred aspect, which is in some regards synergistic with the faster compilation and

simulation aspects of some embodiments of the invention, allows the precise

identification of scenarios to allow for many scenarios to be run and accurately tracked.

Scenario management capabilities of certain preferred embodiments of the invention

enable the specification, storage, and retrieval of a virtually unlimited number of

alternative model scenarios.

Other preferred aspects of a system dynamics modeling environment in accordance

with the present invention provide a facility for developing user interfaces and a separate

facility for defining informative and flexible charts and graphs. A preferred user interface

facility provides a "dashboard builder" that enables users without any programming

experience to create professional-looking graphical user interfaces for their models.

Advanced charting features enable users to create a wide range of two-dimensional and

three-dimensional charts with "drill-down" capability. Such charts are, of course,

significant to explaining and illustrating the results of simulations.

A number of other design features are worth noting. Preferably, the system

provides an "open-enough" architecture so that other languages or applications can be

coupled to models or the modeling environment itself to extend the application. For

example, one embodiment of the modeling environment directed to this objective provides a complete implementation of some or all of the aspects of the present invention

as a stand-alone ActiveX component. Other applications of the present invention may be

coupled to or operated in conjunction with programs written in Visual Basic, Visual C++,

Excel or Word Macros, or the Windows (98) Scripting Host. Those of ordinary skill will

recognize that the intended outputs and interfaces of the present invention will vary over

time and that this list of functionality is representative only.

In conjunction with or distinct from these "usability" interface functions, the

design of preferred embodiments of the present invention allows models produced by the

modeling environment to be modular so that the environment supports component-based

model assembly and distribution. Also in keeping with high quality software design

principles, preferred implementations of the present invention support the clear

documentation of all model components and their evolution. This allows for the ready

modification and distribution of new or replacement component parts of a model as the

model is refined or further developed.

The term "model" as used herein refers to several related aspects, including the

equations and the overall project that is the subject of the model. The definitions in the

following list clarify a number of other terms used in the present discussion:

Model The entire set of information that is used in a modeling project,

including simulation specifications, parameter sets, plot

instructions, and dashboard layouts.

SDMDB A System Dynamics Model Database contains some or all of the

information for a modeling project. It may also contain all or parts of multiple models, model versions, and model variants. An

SDMDB may be distributed as a single entity.

Model Structure The equations and associated flow diagrams that define a model.

Model Version A specific set of model structure equations that is different from

other "versions".

Group A collection of model definition elements including equations and

associated flow diagram representations.

Scenario A scenario is a specific model simulation that is based on a

particular version of the model and a particular set of parameter

values.

Parameter An input variable that is used in model calculations and whose

value helps determine system behavior.

Parameter Set A collection of parameters that can be invoked or referenced by

parameter set name.

Model Data Static information, typically actual system behavior, about

modeled system behavior which is used as a point of comparison

and is generally not involved in calculating model behavior.

Building and simulating system dynamics models within a modeling

environment provided by the present invention preferably involves an iterative process.

First, a model is built by defining individual model elements such as variables and the

relationships among the variables. This may be done using the graphical editor, a textual

editor or, more preferably, both types of editors both sequentially and in cooperation. Simulation of the model proceeds by defining initial variable states and the length of the

simulation time period. The simulation function preferably includes a compilation

function to expedite the processing of the model. At the end of the simulation interval,

the simulation results can be viewed. A number of tests might be performed on the model

at this time. For example, it will often be appropriate to review the values of variables

through the system to determine if they are taking meaningless or void values. Also at

this point, it is preferred that the simulation results be compared to model data to evaluate

the accuracy of the model and the parameters provided to the model. Based on the results

of the simulation, the user can then re-specify model variables to modify the results. The

process of running a simulation and testing the simulation results against model data is

repeated until an appropriate model definition and parameter set is found.

After a model is completely defined, it can be packaged in a form for distribution

to end users who will execute the model for different sets of input data to examine the or

predict results on the basis of the data sets. The scenario or model is preferably combined

with an appropriate set of user interface controls by using the dashboard functionality of

preferred aspects of the present invention. In addition, the scenario or model is preferably

combined with a desired selection of graphical output displays, adapted to the particular

data to be displayed, before the scenario or model is distributed to end users.

System Dynamics Model Databases

Most preferably, data and other information related to a model are stored within

system dynamics model databases (SDMDB 's) within the modeling environment. The

database structure is a fundamental characteristic of the modeling environment and provides a structure for the data both during data editing and during compilation and

simulation. The database structure also simplifies the tracking of various pieces of work

as the model is revised and used. An SDMDB contains some or all of the system

dynamics model definition elements and other model components. An SDMDB may also

reference some or all of other SDMDB 's and may contain a portion of a separately

maintained and distributed model. These SDMDB 's are stored as physical files that may

be distributed, copied, or deleted. Access to the contents of an SDMDB is achieved by

using the system dynamics model definition facilities, such as the navigator interface.

Items preferably stored in the SDMDB are:

• Model definition elements;

Parameters and links to external data;

Scenarios and scenario definition elements;

Simulation results, which may also be stored separately and referenced;

Analysis definition elements; and

• User interface definition elements.

Some SDMDB embodiments may contain entire models or sectors of models. Other

embodiments may simply contain macros or tables, as described more fully below.

Model definition and model analysis is performed in the context of an active

SDMDB. That is, whenever a model developer uses the modeling environment, the

developer preferably has access to at least one SDMDB and defines the model within that

database, whether through the graphical editor or through a textual editor, by describing

the various elements of the model. Upon startup, the developer may select a current model or create a new model, which in turn preferably selects the associated SDMDB or

SDMDB's to access. In other embodiments, the modeling environment prompts the

developer to identify the initial SDMDB for a session. The developer may open two or

more SDMDB's at one time. Scenarios, groups, or elements may be copied or moved

between SDMDB's. Some embodiments of standard SDMDB's are write protected and

may be used only as the source, and not as the destination, of a file transfer.

In some embodiments of the present invention, provision is made so that an

SDMDB may be a library of reusable and independently testable model elements.

Preferably, such a database is read-only to the typical user or to users defined below a

certain level of access priority. Thus, a modeling environment may include or have

access to SDMDB's that are read-only and cannot be altered in a typical modeling

session. Preferably, facilities are provided within the modeling environment so that an

SDMDB can be generated and made read-only ("locked") to future users or to users that

receive a distribution version of the SDMDB. For convenience, if the user or developer

closes the modeling environment from within a model, the screen is restored to the

condition as of the time of the shutdown. This facilitates resumption of work with

minimal delays, which is well appreciated when working on a complex system.

Groups and System Dynamics Models

To aid the model building process, developers can place collections of variables

and other model elements inside model groups. The concept of the group is a particularly

preferred aspect of the present invention that assists the user in more quickly constructing

models, as well as assisting the compiler in more quickly running scenarios. The group approach is especially useful when constructing large models that consist of many model

sectors, each representing a different business focus or useful output of the model. For

example, a model may contain a financial sector, manufacturing sector, purchasing sector,

inventory sector, etc., and each would be contained within a single group. Unlike system

dynamics computer program products in the related art that force the user to place all

variables on one or more layers of a single flow diagram, users of a preferred

embodiment of the modeling environment can place various model sectors into defined

model groups. A model then is a collection of individual but tightly interrelated groups

of variables and other model definition elements. When a model is defined within a

plurality of groups, each group preferably has defined within it an interface to one or

more other groups.

By way of illustration, FIG. 1 might define a single immune system group within

a model of disease within the human body. For this embodiment, the screen of FIG. 1

may be a group definition screen and each group within the model would have a

corresponding screen that could be called up into the graphical interface by accessing the

group for display and or editing. Each of the groups with their associated screens has a

name unique within a given model. The group can be accessed, for editing or otherwise,

by referencing the name associated with the group in the group definition process

facilitated through the screen of FIG. 1. The group definition screen of FIG. 1 shows

what might be a substantially complete model of the interaction between the immune

system and a pathogen. More complicated or simpler models might be contemplated but

are not shown here. Other groups within the larger disease model might include, for

example, a group modeling the circulatory system that interacts with the illustrated immune system group to inform a rate variable for pathogen transport within the immune

system group. The complexity of the immune system group shown in FIG. 1 illustrates

in part why it is difficult to define a large model within a single flow diagram.

Different groups within a larger model are defined so as to communicate peer to

peer with other groups. This group definition is distinct from another defined and

conventionally available capability to define models having layers of complexity

incorporate within a give variable or model element.

An embodiment of the present invention provides a computer program product in

a computer-readable media for use in a computer to build complex system dynamics

models using a plurality of discrete hierarchical system dynamics groups. Each group is

a set of interactive model definition elements, and the dynamic relationship among the

model definition elements of all groups in the system model defines the structural and

quantitative relationship among the variables that comprise the system model. This

embodiment preferably includes a means responsive to user selection of a plurality of

system dynamics groups, a means for hierarchically arranging the groups in a system

dynamics model structure, a means for copying a variable from a first group to a second

group, and a means for defining the dynamic relationship among the groups to describe

the effect of changes within the group on the system model and the effect of system

changes on the group. In a preferred implementation, the computer program product

simulates the performance of the complex system dynamics model. This preferred

implementation preferably includes a means for enabling the groups to dynamically

interact during initialization of the system model and as the system model is exercised in

a simulation. Another embodiment of the present invention is a computer program product in a

computer-readable media for use in a computer to build a system dynamics group for use

in constructing a complex system dynamics model. The group, which has a unique name,

includes model definition elements and may have both equation and graphical

representations. If the model includes multiple groups, it is preferred that each group

includes at least one interface to another group, including at least one reference to a

variable in another group.

Preferred embodiments may include a means responsive to user selection of a

plurality of model defimtion elements for a group. A first group might include model

defimtion elements that are selected from the following:

• Variable type;

• A second group;

• A variable from a second group; and

• A flow diagram.

The group can also include a list of SDMDB's and models to search for additional groups

and can further contain simulation specifications.

The variable types that might be defined include:

• Level;

• Rate;

• Auxiliary; and

• Constant. Of course, this list of variables is not specific to an embodiment in which multiple groups

are used to define a given model. These are the variables that might be used in any

model, egardless of complexity . Groups provide several benefits, such as:

Modularization and organization of model defimtion elements;

Support of rapid navigation to reach specific functional areas of the model;

Support for views of related information; Access to reusable equations;

Automatic flow diagram preparation and maintenance;

Flow diagram modularization;

Easy means for the user to change a group definition for one or more

alternative structures;

Support for distribution of a standard library of Macros;

Reusable data structures that may be replicated many times within one or

more models; and

A natural structure for component by component model testing.

Bezier curves are supported for information links and general sketching. These information links and flow links move intelligently when objects are moved. The user

may control the shape and path of the curve by using mouse-based drawing tools. In

addition to group objects and links, the user may place text (labels, titles, documentation),

boxes, lines, and pictures on the flow diagram. Display options for each object, link, and optional display elements are controlled

using a properties box. These properties include shape, color, style, size, font, and

visibility. The user may change the default characteristics for new objects, by object

type. The user may also change characteristics for any individual element or selected set

of elements. The user may customize the view by including or excluding ghosts,

parameters, and constants.

Free- form flow diagrams contain any combination of variables, parameters, or

groups and may be constructed by copying all or part of group diagrams. To the extent

possible, free-flow diagrams are automatically updated when a variable or link is deleted

or when a variable or link is added to a group or variable that is already in the diagram.

Causal tracing can be started from a free-form diagram.

Using the Modeling Environment

Aspects of the present invention might be practiced for the described embodiment

of a multiple group model or might be implemented in a different embodiment.

Regardless, implementation of a system dynamics model in accordance with the

invention may continue after initial database selection by utilizing means responsive to

user selection for defining the hierarchical structural relationship of the model definition

elements in a group. In practice, this is preferably accomplished in a graphical editor of a

type that is familiar and readily implemented by those of ordinary skill in this art.

Referring to FIG. 1, a developer builds a model using the graphics editor 1 by selecting a

variable type (level, rate, auxiliary, or constant) from a tool bar 2 and places it on the

main flow diagram 3. A preferred embodiment further includes a means responsive to user selection for

defining the quantitative relationship of a model definition element to another model

defimtion element in the group. This might be accomplished in an editing environment

that is accessed as part of the graphical editor or it might be accomplished using the text

editor. Referring to FIG. 2, once a model variable type is selected and placed on the flow

diagram of the graphical editor, the user opens the properties box 50 for that variable.

The properties box might have an appearance and functionality like that shown in FIG. 2

and can be used to further define and specify the exact form of the variable. Each

variable type has a slightly different properties box as appropriate to how the variable

relates to other variables. In most cases, the user specifies an equation 51, or refers to a

table or function, describing the relationship between the selected variable and one or

more other variables on the flow diagram. The resultant definition is stored within the

active SDMDB and is incorporated into the overall system of differential equations that

describe the behavior of the system constructed within the modeling environment.

Preferred embodiments might further include means for copying a model

definition element from a first group to a second group. This might be accomplished

using conventional "cut and paste" graphical editing techniques between two group

display windows each like that illustrated in FIG. 1. Alternately, this might be

accomplished using the navigator functionality described below. In a still other

alternative, a form of model definition copying is accomplished by copying an SDMDB

and editing within that copy of the SDMDB.

This preferred aspect of the present invention allows models to be constructed

much faster than by conventional methods. In a preferred embodiment, the computer program product can simulate the performance of the model consisting of at least one

group. Once all variables have been specified, the user simulates the model by selecting

the simulate command from the menu or toolbar. As will be described below,

segmenting the system dynamics model into groups of related elements enhances the

ability of the compiler to run system dynamics programs efficiently and quickly. When a

simulation is initiated, the compiler examines all the variables and equations and

performs checks to ensure that they are properly specified. Once the equation checking is

complete, the simulator solves the equations for each time period until the simulator

reaches the specified end of simulation. Both the simulation time period (or DT) and the

length of the simulation are set by the user. For example, a user may specify a simulation

time period of one day, and simulate a model for 365 time periods.

When a simulation run is complete, a developer or user has several options for

viewing results. Simulation output can be viewed in either graphical or tabular form.

The computer product of the present invention preferably possesses advanced charting

capabilities that allow the user to view simulation results in a variety of formats. Users

may chose from a range of two-dimensional and three-dimensional bar, column, pie, line

and area charts. An example of one form of graphical output is shown in FIG. 3.

Preferred embodiments of the modeling environment include a means of

generating a graphical user interface (GUI) responsive to user commands input through a

graphical editing tool such as a mouse or other implement that interacts with the

graphical editing features of the interface. This GUI can include a means of navigating

through the model to a particular group and displaying a view of the state of the group.

The GUI, aspects of which are illustrated for example in FIGS. 1-4, includes a screen displaying the hierarchical structure of the model, a means for selecting a group from the

hierarchical structure of the model, and a means for presenting a plurality of views of the

selected group's attributes.

For creating and editing the flow diagrams and models, the program preferably

provides some standard shapes, such as boxes for levels and valves for rates, shown on

the left sidebar of the FIG. 1 display. Additional shapes are provided to offer additional

flexibility to the user in developing representations as required. Every variable calculated

in a group is preferably placed in the group flow diagram. The user drags and drops to

position these objects. Inputs from other groups may be optionally displayed as ghosts.

Output to other groups may also be optionally displayed. The user may add or delete

links using a group flow diagram such as that illustrated in FIG. 1. Further changes as

appropriate might then be made through the variable dialog box. Some changes require

that the user review and modify the underlying equation or equations and the interface

preferably prompts the user or model developer when such a change is made. The

equation may be modified in the text editor or in the variable dialog box that can be

accessed by clicking on the element in the flow diagram.

Macros and Molecules: Reusable Groups

Groups may also be used as macros or as molecules, which are groups specifically

designated as reusable and distributable. Groups designated as macros or molecules

contain equation structures that can be used (i) by more than one model, (ii) more than

once within a model, or (iii) both. Macros within the modeling environment of the present invention are fully

compatible with existing "DYNAMO" macros. A version of DYNAMO is described in

the book by Richardson and Pugh, Introduction to System Dynamics Modeling with

Dynamo (Productivity Press) 1981, which is hereby incorporated by reference. Macros

are specified by setting the group property for "type of group" to macro. With this

specification, the group definition screen lists the calling arguments for the macro in

order and indicates whether they are input or output arguments. A macro may contain

internal variables not included in the argument list. Macros are invoked in equation mode

by using their group name.

"Molecules" are extensions of the macro construction. Any thoroughly developed

group is suitable for reuse as a molecule. If a group is used as a molecule, it is refeπed to

as a molecule; otherwise, it is simply called a group. Molecules most preferably contain

all of the information necessary to make them reusable and commercially distributable.

Thus, a molecule contains not only equations and flow diagrams, but also appropriate

macros, exogenous data, and parameters. Particularly preferred implementations of the

molecule function provide help information that assists the user in using the molecule

part of a model.

Molecules connect to the rest of a model by connecting variable names defined

within the molecule to variable names defined within the model and the SDMDB for the

model. A molecule may be used many times within a model. To function, however, the

model must either map every output variable from the molecule to a variable externally

defined in the group or use the extended name for all references. A molecule might also

be used as an array: VARNAME[ RANGE1, RANGE2,...] = MOLECULE.

This usage will essentially make every output variable in a molecule function as an array.

The reference statement may then be:

VARNAME [RANGE or ELEMENT] .MVARIABLE.

If the molecule contains array elements, each array is preferably assigned one or more additional dimensions:

VARNAME[RANGE or ELEMENT] .MVARIABLE [RANGE or ELEMENT]

Molecule arrays may be used to construct models with predefined model subsets having

dimensions varying according to the model or model version. If a model input variable is

an array that uses the same range as a molecule equation, the appropriate element of that

input array is preferably used for each affected molecule calculation.

Macro and Molecule Libraries

To facilitate the use of macro and molecule functions, the modeling environment

allows the user to specify a list of external SDMDBs to be searched to find macros and

molecules that are not found in the current model. This definitional function within the

modeling environment most preferably also allows a user to define an explicit source for

each macro or molecule. To the extent possible, the modeling environment functions

effectively the same way in all views of the model. The user may select any group in the

navigator or flow diagram by clicking on the group name. A right click opens the Group

Actions menu with the selections:

Open flow diagram - Opens the primary flow diagram window for the selected

group. Open text editor which opens the text editor view for the group.

Properties Window, describes group properties and other comments.

Insert New Group Before/ After, where new groups may be added at any time.

The user is able to create a new group within the model definition of the SDMDB by

entering its name and position. The user may also select a group from the current model

or from any available SDMDB.

Delete Group, which the user may use to "ungroup" the selected group and to

assign all of its components to the next higher group.

Replace Version, which the user may use to change the source or version of an

included group. Old versions of groups may be included in the current version.

Compiler Functionality

Most preferably, the modeling environment provides the ability to build and

execute simulations of system dynamics models and to make the results available for

review and analysis. This is facilitated in particularly preferred embodiments by

advantageous aspects of a prefeπed implementation of the environment's simulator. For

instance, in a preferred aspect of the present invention, the simulator is an integral part of

the modeling environment, not a separate program. When a simulation is requested, the

modeling environment preferably recodes the model equations into tables and structures

that are used during the simulation execution phase. When appropriate, these structures

are maintained over the life of one or more simulations and preferably support multiple

executions with minimal overhead. The core of the simulation engine most preferably is

implemented in performance-coded assembly language to provide high execution speed. Unlike a traditionally programmed model, a system dynamics model does not

contain a sequenced list of instructions. Users are free to type in equations in any order

they wish and, by the very nature of the graphical model definition process, equations and

variable references will exist within the model (actually, within one or more SDMDB's)

in arbitrary order. To generate a simulation, the simulator generally determines a correct

sequence of calculations based on the equations existing within the defimtion of the

model. This is a process that is conventionally required of system dynamics software

programs in initiating a simulation. Preferred implementations of the present invention,

however, provide improved simulator performance by more efficiently performing this

process and, most preferably, producing a structure that is itself more conducive to

efficient further processing.

The integrated design of a simulator in accordance with the present invention also

provides a more flexible simulation environment. "DYNAMO," which is perhaps the

most powerful of the conventional system dynamics modeling programs now available,

determines a correct sequence of execution during a "compiler" step that precedes

simulation. The "DYNAMO" compiler does not support the execution of potentially

correct models that involve references within arrays or conditional dependencies.

Simulators in accordance with the present invention, on the other hand, support such

constructions by providing run-time re-sequencing of equations and variables. Although

this technique is commonly used in spreadsheet software, it has previously been thought

to provide inadequate performance for large system dynamics models. Particularly

preferred embodiments of the present invention address the difficulties of run-time

sequencing through the use of individual instruction pointers for each element of each array as well as the use of relative addressing within the instruction tables through p-code.

The simulator preferably also produces sequenced lists of variables that are to be

calculated at a particular time, which can further reduce the overhead of the simulator

checking to see if a particular variable has been calculated.

Structuring model elements into groups is a particularly advantageous feature of

the present invention's modeling environment for enhancing the speed at which

simulations can be run. Essentially, by so grouping model elements, certain of the groups

can be processed less frequently or even removed from the processing sequence until

variables within the group are altered. A system dynamics model typically requires the

execution of a number of equations for a specified number of time periods. A large

model might include major segments of equations, or groups, that are not executed during

significant portions of the simulation period. "DYNAMO," as an example of a system

dynamics modeling system capable of processing large models, simulates all of these

equations whether the simulations alter the variables within those groupings or not.

To reduce simulation times, the compiler of the present invention is designed to

identify the sets of equations that preferably are executed during any given simulation

run. In this way, particularly prefeπed embodiments of a simulator reduce simulation

execution time by identifying groups of equations that are 'frozen" during detectable

intervals, and therefore need not be executed. In these embodiments, the simulator keeps

track of which variables are active and which are frozen, thereby ensuring the accuracy of

simulation calculations while significantly reducing the execution time. Further to these

aspects, the modeling environment preferably maintains a list of variables that are known

to be uniquely required by a group, which variables are uniquely produced by a group, and which variables are shared with other groups. The program builds lists of those

calculations that take place whenever the sub-model is active and uses these lists to avoid

checking the availability of those variables when referenced elsewhere. This

identification process results in significantly reduced simulation times, especially for

large models (e.g., those with more than 1,000 equations).

Implementations of the modeling environment within a computer program

product preferably also utilize a variety of code optimization techniques such as branch

pruning and equation merging. These techniques enable the software to determine the

minimum feedback system to simulate for generating accurate model results. By

optimizing the simulation process in this way, the simulator and overall modeling

environment runs faster, which is a significant advantage when performing sensitivity and

stochastic testing procedures that focus on the outputs of only one or a limited number of

variables at a time.

Conventional system dynamics models typically use "table functions" to represent

non-linear relationships among model variables. Table functions might, for example, be

represented as a series of points on a graph. Prefeπed implementations of the present

invention can achieve further performance improvement by preprocessing each table into

a series of line segments of the form [y = ax + b], using well known and understood cubic

spline interpolation techniques. The simulator remembers the line segment most recently

used, enabling it to replace a complicated lookup function with two simple comparisons.

This algorithm eliminates several steps in the final computation, and provides efficient

support for variably spaced table functions and for boundary detection. Any system dynamics model requires that the model be and evaluated for

accuracy. Because system dynamics models often produce non-linear systems of coupled

equations, models are actually run to determine if the model will reach a steady state or if

the model will oscillate in a meaningless manner. Simulating the performance of a

modeling system accurately and quickly leads to reduced development time and

improved design quality. That is, when the model is simulated more quickly, it is

possible to run more simulations and it is easier to achieve an accurate model.

Language Syntax and Features

The following describes some of the language syntax and features of a prefeπed

implementation of certain aspects of the present invention.

Duplicate Variable Definitions: Duplicate variable definitions are treated as errors

to model execution.

Standard DYNAMO features: A version of DYNAMO is described in the book by

Richardson and Pugh, Introduction to System Dynamics Modeling with Dynamo

(Productivity Press) 1981, which is hereby incorporated by reference. The standard

DYNAMO features are supported and implemented in preferred implementations of the

present invention.

Simulation specification group: This is a special group that contains the

specifications for running a model, including time, DT, and the like. This group must

appear at least once in the model specification and is accessed from memory at least once

during initiation of a simulation. Arrays: Support is provided for arrays, which are matrices of elements of the same

type and unit of measure that represent multiple instances of a variable. Any variable

may be declared an aπay by designating dimensions in the variable dialog box.

The Group Navigator

The definition of a model includes the structural and quantitative relationships

among the variables and other elements that comprise the system being studied. These

relationships are explicitly defined by equations and may be located, reviewed, and their

variable dialog box accessed through the navigator functionality. In some prefeπed

embodiments the navigator functionality is represented as a tabbed display chart. This

prefeπed aspect of the present invention is referenced here as a navigator because it

provides an easily navigated overview through which variables can be identified and

accessed efficiently. Most preferably, the navigator functionality is in addition to the

graphical interface preferably provided to define flow diagrams and variables through the

prefeπed variable definition dialog boxes preferably integrated with the graphical

interface. The navigator functionality is well suited to the definition of groups and for

working with groups in the model, since groups can be called by entering or clicking the

group name and the entirety of the group can be viewed.

FIG. 4 shows a particularly prefeπed implementation of a navigator window. The

navigator allows users to easily store and display major elements of a model. A navigator

only shows the contents of one model, but can be 'pointed' to a different model at any

time by selecting the model identification through model name, version number or

scenario. The navigator shows the model structure as an arrangement of model groups. Tabs can be selected by the user to show various attributes of the group, for example

diagrams, variables, and output. In the embodiment illustrated in FIG. 4, the model

structure of the navigator appears in a left pane view that is always shown. The attribute

of the selected tab appears in a right pane that can be shown or hidden as desired. Each

pane has tabs to show different information about the contents of the specific model that

the navigator is showing. For example, FIG. 4 shows the "variables" tab selected for a

particular group. Within the "variables" view are the name of the variables, the variable

type, the legend, the equations and whether the variables are saved.

The navigator tree provides a rapid way for the user to review model structure and

to work with groups. When a group is included from the navigator tree or belongs to a

group in the navigator tree, its equations and declarations are used directly in the model

execution. The primary branches of the navigator tree are those groups that directly

determine the current version of the model. The top level view is presented as a tree

structure and provides several options for the labeling of each node:

• Group Name Only;

• Group Version Number;

• Group Description; and

• Date Created.

The navigator view options are controlled through a menu choice. Groups are marked

with a distinct icon. The user may select the level of detail to display in the tree:

• Top level groups only;

• All groups; or • User-controlled tree view, which is an expansion and compression of

model definition components.

The user may choose views that display only selected types of elements. For instance,

the user may decide to view only levels. The user may also choose to view a group by

selecting the group from the navigator. A right mouse click is used to access properties,

or other well known accessing techniques might alternately be implemented.

A group may be moved to another location in the tree, by using "cut" and "paste"

commands from the edit menu or by using the "drag and drop" technique. If a sub-group

is moved from one parent group to another or to a top level group, the user is asked to

verify the move and is warned that the flow diagrams for the parents may need to be

manually adjusted. In order to directly access group elements, the user simply expands

the tree and selects the desired elements directly.

Displays and Output

There are different recognized users for various embodiments of the present

invention. Embodiments may be used in: 1) system dynamics simulation software, 2)

more general simulation technology and model building tools, and 3) business decision

support tools. Various embodiments are adapted to each of the users, without limitation:

1) a "model builder' for system dynamics simulation high-end users, 2) "application

builder" including the dashboard builder and packaged molecules, for broader simulation

technologies users, such as consultants and other business analysts with technical

backgrounds, and 3) packaged software models with customized user interfaces built with the dashboard builder that can be linked to corporate industrial enterprise application

systems to assist higher-level strategic decision-making processes. The tools that support

the second and third uses are presented below.

Dashboards

Embodiments of the present invention may also provide users with the ability to

create customized user interfaces, or "dashboards," for their models without requiring

programming experience. This capability allows a broad array of users to develop

professional-looking system dynamics model-based applications. This powerful feature

enables users to transform their models into applications that can be used by others (end-

users) in a simpler and more practical manner. Once a model is built, users may generate

and view the results of alternative model scenarios by accessing dashboard controls

provided in the packaging of the model. Users may also create a custom user interface

for a model that makes it easier for third party end-users without simulation modeling

experience to generate and view model scenarios.

The dashboard builder is a standard multiple document application contained

within software embodiments of the present invention. In one prefeπed embodiment, the

computer program product includes a means of designing a customized graphical user

interface (GUI) for running a predetermined set of model defimtion elements. In certain

prefeπed embodiments, the means of designing the customized GUI further includes a

means responsive to user selection of customized simulator controls and means for

displaying them, a means responsive to user selection of functional linkages of each

simulator control to a model definition element, and a means responsive to user entry of an initial state of each variable in the model defimtion element and for displaying the

result of the custom simulation.

The application has several menus and toolbars that provide the means for a user

to design a dashboard. FIG. 5 shows the dashboard builder application with two open

dashboard files. From this interface of the dashboard builder, a model developer can

build an interface specific to a model. For example, if there are model characteristics that

an end user is expected to vary in using a distribution version of a model, then

appropriate data input controls are provided. Other user interface features are readily

provided to a distribution version of a model using the dashboard builder functionality.

The active window "Dashboard One" of the dashboard builder interface contains four

controls with the "simulate" control active. The active control is highlighted with a bold

box and contains handles for resizing.

The tables in FIG. 5, 6 and 7 describe the icons in the two tool bars on the

dashboard builder interface. In FIG. 6, the "application" toolbar contains icons for many

of the common user actions in the dashboard builder. In FIG. 7 the "control" toolbar

contains icons for controls that can be dragged out on a dashboard. The user may add

controls to this toolbar in the "Toolbar Add-ins" dialog. Those of ordinary skill will

recognize the use and functionality of the illustrated controls, which are implemented like

similar tools in visual programming environments.

Use of the dashboard functionality allows a model developer to customize the

program environment for use by end-users or for use in interactive presentations such as

screen driven presentations. The end-user environment may have a very different look

and feel than the standard analysis screens. The customized environment interface developed through the dashboard builder may be used to restrict the end user's choices or

to automatically provide graphics for presentation. The functions accessible on a

distribution ready user interface may include any of the standard functions from the

program, such as:

• Model Definition;

Change Parameters;

Automatic Sequence of Actions;

Simulate;

Presentation; and

• Report/Document Output.

The dashboard builder interface preferably provides controls-adapted "Help" messages

may also be constructed and attached to specific variables, input screens, or displays.

The help messages provided may address navigator issues, for example how to use the

interface, and model content issues.

Dashboards may be designed that provide input controls and information displays

customized for use by a specific type of end user or group of end-users. Each dashboard

may have a number of "views" that may be selected by the end-user or that appear or

disappear based on certain input or result values. A dashboard can present a control panel

view that may automatically change based on model conditions or that the end user may

change through various requests. Dashboard design is a menu-driven process. The user

designing the dashboard may modify an existing dashboard or create a new dashboard.

The design area preferably has the format of a familiar WYSIWYG ("what you see is what you get") area surrounded by various buttons and controls. The design may place as

many objects into the area as will fit.

When using a dashboard-equipped model in analysis mode, the end-user may

select cuπent, active, and base scenarios. The end user may also select one or more

cuπent variables. Some of the components of the dashboard display may be defined in

terms of cuπent scenarios or variables. These displays preferably change automatically

when the end-user changes the cuπent status of scenarios or variables. Other displays

may be fixed in either situation. Various portions of the dashboard may provide the end-

user with the ability to change parameters and other input information. Parameter

selection trees are available to the designer and provide access to parameters and dialog

screens that the designer wishes to provide to the end user. These trees are defined as a

multi-leveled hierarchy.

Plots and charts may be positioned as display windows. The end-user is able to

select objects, such as the type of display, size of display, text labels, and data

specification. The procedure, similar to Visual BASIC, is to drag the appropriate object

into the large display area and to position and size it as desired. The "properties" of this

object are entered through a separate definition window accessed through the mouse or a

pull-down menu. Each display may include an optional border, background color and

pattern, and other characteristics. Any plot may have associated analysis equations that

are applied prior to the display. Tabular output and other text based reports are

configured in a manner similar to the plots and charts referenced here.

Text boxes and labels may be used to explain what the input represents. Radio

buttons may be used to provide the end-user with an easy method of selecting a particular parameter set or group of parameter settings. Thus, the dashboard designer may present

decisions in the end-user's language and combine a set of related parameters into a single,

non- technical choice. Moreover, a clustered entry dialog can be configured to provide

access to two or more parameters within a single display area. These dialogs are

preferably accessed through the parameter selection tree.

The dashboard designer may provide a sheltered view, or a sub-set of the

program's full capabilities, by limiting the controls available within that view. Controls

typically made available to the end-user include the ability to change inputs, execute the

model, and review simulation results. If desired, the dashboard may also provide access

to models and multiiteration modeling capabilities.

In a prefeπed embodiment, the computer program product further includes a

means for selecting a model definition element and executing a "drill down". The user

designing the dashboard may define analysis progressions that provide the end-user with

the ability to "drill down" during an online analysis session. Having accessed the drill

down mode, the user may click on any line, bar, slice or row in a chart or tabular output

to see a second graphical output display. Thus, a user presented with the graphical output

of the FIG. 3 chart might click on the chart to view the functionality that defines the

graphical output.

Model Version Control

System dynamics model development is a complex task, generally performed by

persons with extensive training in modeling. Even with high levels of expertise,

development of a model is a time-consuming and imprecise task. Consequently, it is desirable to provide a system dynamics modeling environment in which a model

developer can accurately track versions of models and differences between versions.

Prefeπed embodiments provide basic support for allowing several users to make changes

to a single model. The software preferably keeps a record of groups that were changed,

allows comparisons of files on a group-by-group basis, and lets the user drag or copy and

paste between two (or more) model files to create an updated master version.

A Date/Time/ Author Stamp contains the date, time and author that applied when a

specified change was made. The model has a DTA stamp when it was originally created,

and has a latest change DTA stamp, set when the user saves the file. The user's identity

preferably is set to the Windows user name as a default, but may be changed in the

Preferences dialog box. Each group has a latest change DTA stamp, known as the Group

Modification DTA Stamp. This is set immediately whenever the contents of the group

are changed.

A menu command preferably allows the user to select two model files to compare.

A standard 'Open' dialog allows the user to pick the target data files and then the source

data file. All changes made via the model comparison dialogs preferably are made to the

target file. Thus, the usual procedure is for the user to create a new copy of one of the

two files to be compared, then use that copy as the target. When a file is compared with

another, the Modification DTA stamps for the two files are checked first. If they are the

same, the files are reported as identical, with no further action taken.

The models will be opened (if not open already) and contents of the models will

be compared, group by group, to see if each group exists in the other model, and if their

Modification DTA stamps are the same. Groups are compared on a name basis. Although each group and variable has a unique identifying serial number, this number is not

preserved when copying from one model to another, and thus is of limited usefulness.

Therefore, names are used to determine whether the groups are the same. This generally

results in two groups being identified as different if either one has had its name changed.

Also, if two unrelated groups happen to have the same name in the two models, they will

be compared, and their differences shown, just as if they were two versions of the same

original group. If any differences are found, a Model Comparison window is shown.

This window is a regular application window, not a dialog, allowing it to be moved and

resized. This allows the user the flexibility to make changes manually to either model

while the Comparison window is open.

A group comparison allows the user to compare the contents of a group that exists

in both models. It is similar to the Model Comparison dialog, but compares the variables

in the two groups. As with groups, names are used to determine whether the variables are

the same. Therefore, a variable that has been renamed will show up as both a variable in

the source file that doesn't exist in the target file and a variable in the target file that does

not exist in the source file.

• The contents of the groups are compared, variable by variable, to see if each

variable exists in the other model, and if contents are the same.

• The variables are defined to be different if any of the following are different:

0 The number of equations;

0 The contents of any equation, either regular or Init. This includes

different subscripts; 0 The Units, Legend or Comments;

0 The Saved checkbox; and

0 Inside a Macro, the Macro Argument checkbox.

• If any differences are found, a Model Differences window is shown. This

window is a regular application window, not a dialog, allowing it to be moved

and resized.

Generating Scenarios

The scenario can be a useful tool in analyzing model behavior. Typical modeling

analysis involves examination of a number of scenarios. A scenario is a specific set of

parameters and a specific model version that produces a certain set of results. For a

useful model, a scenario should produce the same results each time it is run. Variable

changes that can alter the results constitute a new scenario. A scenario always relates to a

specific version of a model and to a specific set of parameter values. The user may create

a new scenario by changing the model or the parameters values. Conveniently, the

scenario number is assigned in numerical sequence within the SDMDB.

Users have access to features that make it easy to create and save scenarios and

models. Using the scenario specification grid, users can easily retrieve model parameters,

change parameter values, store parameter sets, and execute and save new scenarios.

Model parameters are accessible in a tree, similar to file folder trees conventionally found

in "Windows" applications. Multiple parameters can be selected and changed at once,

and these changes can be grouped into parameter sets that can be saved for later use.

Model simulation runs, i.e., scenarios, that are executed based on these parameter changes can be named and are automatically saved by the program. Users can also view a

complete listing of saved simulations in the scenario roster. The scenario roster shows all

the saved scenarios, a list of parameters that have been changed, and summary output

results for each.

The user may save the results of a simulation run. The "save" command closes

the scenario and freezes all of the inputs required to generate the result. The user may

also explicitly discard the results. If the results of a simulation have not been explicitly

saved or discarded, the user is preferably forced to choose one of the above prior to

exiting or to making changes that would prevent a "save" command from being

successful. The specifications, version, and results are saved by default unless the user or

end-user makes an explicit decision not to save the scenario. If the user decides not to

save the results or to freeze a specific set of definitions as a scenario, then the scenario

definition is not saved.

The scenario list is used to select which scenario to use as a base for other

scenarios. In browse mode, the user can quickly scan the assumptions that distinguish

among the various scenarios. The list format may also be used to select scenarios to

review. A grid is used to review and select scenarios. The scenario list box may also be

used to make a scenario active, which makes it available for comparative analysis with

the current scenario. If a user wishes to make an already executed scenario the current

scenario, any work in process must first be discarded.

Scenario numbers are unique within an SDMDB and are assigned starting with

the number 1. The default name for a scenario consists of the model name and an ordinal number sequentially designating the scenario. Alternate names and aliases may be

supplied by the user. Scenario numbers are not re-used within a given model, even if

certain scenarios are deleted.

The user may change any parameter used by the model. The user may construct

organized sets of parameters to simplify the search for a desired parameter for change. A

list of parameters that have been changed during a scenario is always available. A similar

list is also available for any past scenario. Parameter sets may be defined independent of

a particular scenario. These sets are intended for use when a single group of parameter

values is run several times in conjunction either with other groups of parameter values or

with several model variations. Parameter sets are assigned names that identify a

particular list of parameters. The user may create multiple versions of a parameter set

and specify that a model be executed using each set of values.

Parameter sets are created at the model level. In other words, the parameter set

name is unique within an entire SDMDB. Each parameter set contains a set of

parameters and values for those parameters. Parameter set membership, meamng the list

of parameter names, may not be changed once the parameter set has been used for a

specific scenario. This restriction may be removed if the detail for each parameter is

stored for each scenario. Every time a value is changed in a parameter set, a different

version of that parameter set is preferably stored under this variation. The version

number is simply the number of the scenario that first used that set of values. A specific

parameter set is saved for each scenario. This parameter set contains the names of any

explicitly used parameter sets, and their versions, as well as any parameter values that

were changed for the scenario but that were not explicitly part of a named parameter set. The results of each scenario are stored in a results area that contains variables

and time periods designated for retention. Most interactive results analysis consists of

either examining the results of one scenario or of comparing values between several

scenarios. By default, the most recently executed scenario is available for review. The

user may change the scenario being analyzed and build lists of scenarios to be analyzed.

Output Charts for Scenarios

Many of the output charts and tables include the results from more than one

scenario. For analysis purposes, the user may select any scenario as the cuπent scenario.

Any other scenario may be designated as the base scenario. In addition, other scenarios

may be designated as active scenarios. The impact of these selections will vary according

to the output display method selected.

The user may select a variable to display by clicking on it anywhere within the

model structure (navigator, flow diagram, or text editor). By right clicking within the

model structure, several options appear including the display of the default plot.

The program includes a number of standard plot capabilities, including line plots,

scatter diagrams, pie charts, and bar charts, both vertical and horizontal. A default plot

method is always available for graphical display of any variable. The initial default type

is a line chart that shows the values of that variable for the current scenario compared to

values for any other scenarios that may exist and that have been activated for this

purpose. If the user wishes to see an alternate presentation of the information, a right-

click within the plot window will allow the user to change to an alternate format or to a customized chart. The user may also change the defimtion of the "default" plot. The plot

window remains active until the user explicitly closes it.

Thus, the user may have many plots on the screen at one time. The user may

further specify that all actions are to be interpreted as analysis. In such a case, the left-

click of the mouse on any variable causes the default plot to be displayed immediately.

Tabular output may be viewed in much the same way as charts. The tables may

be selected from standard comparative displays or from custom tables. The user can

specify chart or tabular output by using the "define output" features. Each plot produces

an output window that can be configured, sized, and placed using a standard Windows

interface. The user may also specify algebraic expressions whose results are displayed.

Once a plot, chart, or tabular report has been configured, the user may elect to

save the definition for that report. The specification may include the option to use the

variable current as of the run-time or to use the original variable value set at the time the

model was built. Once a custom plot is defined, it is available through a list box when

the user right clicks on an appropriate item. These plot definitions may be associated

with a specific group and are displayed in the navigator tree. The plot specifications

preferably include:

• Line chart specification;

• Bar chart specification;

• Pie chart specification;

• Scatter diagram; and

• Table output specification. Users also have the option of saving groups of plots, or "plot sets." A single plot

set that contains multiple plots can be created, saved and retrieved by the user. The

"click-to-trace" command combines aspects of the click-to-plot, rapid mode, and tree

diagrams. Click-to-trace allows the user to trace chains of cause-and-effect, or drivers,

very quickly. With click-to-trace mode selected, every click on a variable will result in a

plot of that variable and its inputs (the drivers). Clicking on one of the drivers will result

in a further trace. With click-to-trace mode set, the user may also view a text box that

displays the coπesponding equations. This box is cumulative; it includes the starting

point and any number of levels.

Any chart or report may be moved to "POWERPOINT" or "WORD" or many

other Windows products by either copying and pasting or by the drag-and-drop

technique. Scenario results may be directly output in spreadsheet form, for instance into

a format compatible with "EXCEL". These results will use each saved variable as a row

and each "save per" as a column. Output properties may be used to control labels and

formats.

Variable Dialog Boxes

Equation Syntax: The equations specified for levels, flows, and auxiliary variables

use the following syntax:

• The calculated variable (element, array, or vector) is identified in the name

box.

• Time references are not included. • White space and parentheses may be used to the definer's content.

Level: The variable definition box for a level provides a very structured format for

changes in level. Most preferably, every input and output is required to be assigned a

name. Flow equations may be modified in this window. Alternately, the user can double

click to move to a detailed flow screen. Changes in the flow screen automatically update

the equation view in this window. Levels are specified with in and out flows, by name.

Model variables are created for each flow referenced, unless the variable already exists.

If the level is an array, the initial value specification may switch to another screen. The

variables used by section will provide an initial view into model structure.

Flow: Flow equations may be associated with specific source and destination

levels.

Tables: Table variables may be specified using the graphical table changer or they

may be displayed in a matrix format.

Variable subscripts will use a graphical tree control for specifying and displaying

subscript families (i.e., arrays) and elements to which the subscripts are applied. When

the user wishes to apply a subscript, the user selects the subscript using the variable

dialog box extension pad. Once applied, the family display will show the subscript in the

graphical tree box for the family. It will be assumed that both sides of the equation have

this subscript. If the user wishes to specify a different equation for one or more elements

of the subscript families that apply to the variable, the user selects a new equation (using

the index control), selects which elements the new equation will apply to using the

graphical tree control, and enter the equation to be applied. Numerous equations may be specified in this fashion. If the user wishes to specify equations that have different

subscripts on the left and right side of the equation, the explicit method must be used.

Automated Simulation Control

Automated simulation control refers to various analysis activities that consist of

running a number of simulations and analyzing the results. Each of these analysis

sessions begins with a definition of the simulations to run and of the reports or outputs to

produce. Special analysis calculations may be specified for each run and for comparisons

between runs. The setup information for each automated session is saved for future

review and for possible reuse. The major types of automated sessions are:

• Sensitivity Analysis (also refeπed to as "grid search");

• Goal Seeking / Optimization;

• Monte Carlo (Stochastic);

• Driver and Potentiator Identification; and

• Confidence Analysis.

Sensitivity Analysis

Sensitivity analysis provides the ability to execute the model a number of times in

order to evaluate the impact of changing one or more decisions or assumptions.

Sensitivity analysis begins with a dialog box that prompts for definition of what actions

to perform. The initial screen includes the model version(s) to use and the input

variable(s) to be applied. Each selected version or variable is applied independently of

other versions or variables. Therefore, if two model versions are selected and run against variables with three alternate values, the automated simulation controller will run six

simulations. The user may specify up to eight variables and up to ten values per variable.

For each variable selected for sensitivity analysis, the user may specify a starting

value, ending value, and increment. The user may also specify values or percent changes.

For table functions or for time series data, the user may specify values or time series data.

In each case, the user may enter a description for each selection. Results of the sensitivity

runs may be compared by displaying the values for one or more outputs presented with

the assumptions and decisions that caused those results. These tables may be sorted in

ascending or descending order by results. A number of standard graphs are available to

provide a visual comparison of the sensitivity scenarios. Any saved variable may be

selected for BEST- WORST-MEAN-MEDIAN output. This type of analysis may also be

used between any "slice" of the output.

Goal Seeking and Optimization

Automated goal seeking and optimization (maximize or minimize) functions are

supported by means of a multiple iteration controller. The analyst is able to select an

output variable and to designate one or more input variables or parameters that will be

changed methodically in order to reach a solution, or at least an approximation. The

analyst may specify ranges for each input, and acceptable ranges for additional output

variables (i.e., "Maximize year profits but maintain existing staff levels"). The setup

screen for this type of iterative processing allows the user to limit the total number of

iterations or the total amount of clock time. The best results are saved during the process. Following each iteration, the best

fit iteration display is updated. A running count of total attempts is also displayed, as is

the average run time. A variety of algorithms are provided that allows for optional

"pruning" or identification of optimal results.

Monte Carlo Simulation

Monte Carlo simulation allows the user to specify one or more inputs that vary

"randomly" according to an assumed probability distribution. The program preferably

supports several commonly used distributions. The model can then be run many times to

assess the distribution of results given the assumed distribution of inputs. This can

provide useful information for risk assessment. In order to use Monte Carlo simulation,

the user preferably specifies the input variable(s) to use, what distributions to apply, and

which output variables to track. A detailed log of the results of each simulation may be

reviewed in tabular form. Selected output variables may be viewed with mean, median,

maximum, minimum, standard deviation, and other statistical measures.

Driver and Potentiator Identification

Embodiments of the present invention provide algorithms that seek to identify

important non-obvious relationships. For any given variable, the inputs that generate

changes in behavior are identified and ranked. "Potentiators" are defined as multiple

factors that, when changed in conjimction with each other, generate a much larger impact

than the same level of changes in individual parameters. The program provides the

ability to search for potentiators among the input parameters. The user specifies the output variable that is being tracked, and the program will automatically execute the

model many times with variations of parameter values. The output of this search is a

table listing of the changes in output and coπesponding inputs.

System Architecture

FIG. 8 illustrates a further aspect of the present invention in which either the

modeling environment or a model, whether in development or in a finished form after

distribution, may be provided within a computer system 200. The illustrated computer

system 200 includes a main system 202 including a first long term memory 204 that

might include a hard disk drive, optical storage, solid state storage or any practical

memory for storing the programming environment and various versions of models and

other data sets related to the use of the environment or models. The main system includes

a processor 206, which in some embodiments is a single processor and in other

embodiments may be an aπay of processors configured to process models, equations and

other model elements in parallel. It should be appreciated that the illustrated embodiment

of the main system may not be a single computer system but might also be a number of

computer systems distributed over a network or in other fashion.

The main system includes a second memory 210, which functions as a

workspace either for the modeling environment or a model such as when a distributed

model is being simulated by an end user. The second memory may include a RAM or

other solid state storage workspace and portions of hard disks, as appropriate to include

the proper amount, speed and accessibility of memory for the environment, programs and

models. During operation of the modeling environment, some or all of an SDMDB 212 is preferably stored in the second memory as the active SDMDB for the modeling

session. Shown in the SDMDB 212 are two groups that are defined within the SDMDB,

one of which might be the simulation definition group. As is prefeπed in many

embodiments of the present invention, the simulator 214 and integrated compiler 216 are

present in or accessible from the second memory 210 because these program elements are

integrated parts of the modeling environment.

Attached to the main system 202 is at least one display 220 that might be used in

either developing a model or in running a simulation. Depending on the particular

functions accessed, an appropriate one of the interfaces 222 discussed above is provided

on the display 220. Of course, the interface elements 222 shown on the display 220 may

only be aspects of the overall interface, some of which may include functionality that is

defined, stored and operated within one or more portions of the main system 202. Also

attached to the main system 202 is an I/O facility that may include a wide range of input

devices, such as a mouse or other pointing device, a keyboard, a network connection and

one or more external data storage devices, and a wide range of output devices, including a

colored printer appropriate to generating hardcopy output from the graphical output

facilities of the modeling environment.

Although the present invention has been described in detail with reference only

to the presently-prefeπed embodiments, those of ordinary skill will appreciate that

various modifications can be made without departing from the invention. Accordingly,

the invention is defined by the following claims.

Claims

What is claimed:

1. A computer program product in a computer-readable media for use in a computer

to build a system dynamics group within a complex system dynamics model, the group

including model definition elements, the computer program product comprising:

means responsive to user selection of a plurality of model defimtion elements for

the group;

means responsive to user selection for defining the hierarchical structural

relationship of the model definition elements in the group;

means responsive to user selection for defining the quantitative relationship of a

model defimtion element to another model defimtion element in the group; and

means for copying a model definition element from a first group to a second

group.

2. The computer program product of claim 1, wherein the group is a first group and

the model definition elements are selected from the group consisting of: variable type, a

second group, variable from the second group, parameters, exogenous variables, plots,

dashboards, and flow diagram.

3. The computer program product of claim 2, wherein the variable type is selected

from the group consisting of: level, rate, auxiliary and constant.

4. The computer program product of claim 1, wherein the program product simulates

the performance of the group, the computer program product further comprising means

for enabling the model definition elements of the groups to dynamically interact during

initialization of the group and as the group is exercised in a simulation.

5. A computer program product in a computer-readable media for use in a computer

to build a complex system dynamics model using a plurality of discrete, hierarchical

system dynamics groups, each group a set of interactive model defimtion elements,

wherein the dynamic relationship among the model defimtion elements of all groups in

the system model defines the structural and quantitative relationship among the variables

that comprise the system model, the computer program product comprising:

means responsive to user selection of a plurality of system dynamics groups;

means for hierarchically arranging the groups in a system dynamics model

structure group; and

means for copying a variable and its properties from a first group to a second

means for defining the dynamic relationship among the groups to describe the effect of

changes within the group on the system model and the effect of system changes on the

group.

6. The computer program product of claim 5, wherein the program product simulates

the performance of the complex system dynamics model, the computer program product

further comprising means for enabling the groups to dynamically interact during

initialization of the system model and as the system model is exercised in a simulation.

7. The computer program product of claim 5, further comprising means for

generating a graphical user interface responsive to at least one user command.

8. The computer program product of claim 7, further comprising means of

navigating through the model to a particular group and displaying synchronized views of the state of the group, wherein the means for navigating include means for displaying the

state of the group in response to commands received from the graphical user interface

means; and the graphical user interface means comprises:

a user viewing screen displaying a hierarchical structure of the model;

means for selecting a group from the hierarchical structure of the model; viewing tracing drivers and "where used" drivers, and

means for presenting a plurality of views of the selected group's attributes.

9. The computer program product of claim 8, wherein the group attribute views are

selected from the group consisting of: variables, diagrams, dates and outputs.

10. The computer program product of claim 8, further comprising a means for

selecting a model defimtion element and displaying all of the occurrences of the element

in the model.

11. The computer program product of claim 7, further comprising a means of

designing a customized graphical user interface for simulating a model in accordance

with a first predetermined set of model definition elements, the set of model defimtion

elements having at least two variables that dynamically interact.

12. The computer program product of claim 11 , wherein the means of designing the

customized interface further comprises

means responsive to user selection of customized simulator controls and for

displaying them;

means responsive to user selection of functional linkages of each simulator

control to a model defimtion element; and

means responsive to user entry of an initial state of each variable in the model

definition element and for displaying a result of the custom simulation.

13. The computer program product of claim 11 , wherein the customized simulator is a

first customized simulator and the set of model definition elements is a first set of model

definition elements, the program product further comprising means of designing a second

customized interface for simulating a model in accordance with a second predetermined

set of model definition elements, the second set of model definition elements having at

least two variables that dynamically interact, where the model definition elements of the

second customized interface include a variable that is not present in the model definition

elements of the first customized interface.

14. The computer program product of claim 6, wherein the dynamic result of the

interaction of the groups can be stored on and retrieved from a readable writeable storage

device.

15. The computer program product of claim 6, wherein the complex system dynamics

model can be stored on and retrieved from a readable and writeable storage device.

16. A method of building a complex system dynamics model using a plurality of

discrete, hierarchical system dynamics groups, each group having a set of dynamically

interactive model defimtion elements, wherein the dynamic relationship among the model

definition elements of all groups in the system model defines the structural and

quantitative relationship among the variables that comprise the system model, the method

comprising:

configuring a system dynamic structure to be modeled by selecting a set of system

dynamics groups;

hierarchically arranging the groups in a structure;

copying a variable from a first group to a second group; and

defining the dynamic relationship among the groups to describe the effect of

changes within the group on the system model and the effect of system changes on the

group.

17. The method of claim 16, wherein the step of selecting includes assigning a first

group a name and assigning a second group a name, and wherein a graphical first flow

diagram display shows the first group and does not show the second group.

18. A method for identifying model potentiators and defeators defined as multiple

factors that, when changed in conjunction with each other, have a comparatively larger

impact than the same level of changes in individual ones of the multiple factors, the

method including steps of varying the multiple factors.

19. A system dynamics modeling tool, including:

a graphical interface for inputting a flow diagram representation of one or more

system dynamics model elements;

a definition facility, linked to the graphical interface and accessible from the flow

diagram representation, for defining one or more characteristics of a model element; and

a navigator interface, distinct from the graphical interface, adapted to display a

first plurality of model elements in at least one view of the interface and allowing editing

of one or more characteristics of each of the first plurality of model elements.

20. The tool of claim 19, wherein the definition facility is accessed from the graphical

interface using a pointing device in conjunction with a displayed flow diagram.

21. The tool of claim 19, further comprising an end user interface development

facility capable of providing graphically operable tools for adjusting a value of at least one parameter and for selecting a type of display illustrating time variations in at least

one model element.

22. The tool of claim 19, further comprising an end user interface development

facility capable of providing an end user display illustrating time variations in at least one

model element, the end user display automatically provided with a drill down function

allowing an end user to display an underlying definition of the model element by

selecting an aspect of the end user display.

23. The tool of claim 19, wherein the graphical interface further comprises a group

definition screen, the graphical interface accepting input through the group definition

screen to define a first group and assign the first group a name, the graphical interface

accepting input through the group definition screen to define a second group and assign

the second group a name.

24. The tool of claim 19, wherein the graphical interface is adapted to accept input to

define a first group and assign the first group a name, and to define a second group and

assign the second group a name.

25. The tool of claim 24, wherein the graphical interface is adapted so that a flow

diagram display of the first group shows an input from the second group as an indication

of a common variable shared between the first and the second group.

26. The tool of claim 25, wherein the input is represented in the flow diagram in a

manner visibly different from like relationships entirely within the first group.

27. The tool of claim 19, wherein the tool is stored on computer readable media.

28. The tool of claim 19, wherein the first plurality of model elements and the one or more characteristics of the first plurality of model elements are stored in a system dynamics model database.

29. The tool of claim 19, wherein the first plurality of model elements and the one or

more characteristics of the first plurality of model elements represents a first group and

wherein the navigator interface is adapted to display characteristics of a second plurality

of model elements for a second group in at least a second view of the navigator interface.

30. The tool of claim 29, wherein the first group and the second group are identified

by distinct flow diagrams in the graphical interface.

31. A system dynamics modeling tool, including:

a graphical interface for inputting a flow diagram representation of one or more

system dynamics model elements; and

a definition facility, linked to the graphical interface and accessible from the flow

diagram representation, for defining one or more characteristics of a model element,

wherein the graphical interface is adapted to accept input to define a first group

and assign the first group a name, and to define a second group and assign the second

group a name,

wherein the graphical interface is adapted so that a flow diagram display of the

first group shows an input from the second group as an indication of a common variable

shared between the first and the second group, and

wherein the input is represented in the flow diagram in a manner visibly different

from like relationships entirely within the first group.

32. A system dynamics modeling tool, including:

a graphical interface for inputting a flow diagram representation of one or more

system dynamics model elements; and

a definition facility, linked to the graphical interface and accessible from the flow

diagram representation, for defining one or more characteristics of a model element,

wherein the graphical interface is adapted to accept input to define a first group

and assign the first group a name, and to define a second group and assign the second

group a name, and

wherein the graphical interface is adapted to show a first flow diagram display for

the first group and to show a second flow diagram display for the second group.

33. The tool of claim 32, further comprising a system dynamics model compiler, the

compiler comparing variables in the first group to variables in the second group to

identify common variables between the first group and the second group.

34. The tool of claim 33, wherein the compiler links the first group to the second

group so that a change in the common variable within the first group is communicated to

the second group.

35. A system dynamics modeling tool, including:

a graphical interface for inputting a definition of a system dynamics model, the

interface adapted to receive variable definitions and equation definitions that define the

model; and a compiler receiving as input a plurality of variables and a plurality of equations within the model and operating on the variables and the equations to ensure that a defimtion exists for each of the variables and equations in the model, the compiler

generating an error message if a variable or equation is undefined.

36. The tool of claim 35, further comprising a simulator to solve equations at each of

a plurality of defined time intervals.

37. The tool of claim 36, wherein the simulator solves selected equations at fewer

than the plurality of defined time intervals.

38. The tool of claim 36, wherein a time interval and a length of simulation are stored

in a memory and wherein the simulator retrieves the time interval and the length of the

simulation from memory and simulates the model at the plurality of defined intervals for

the length of the simulation.

39. The tool of claim 35, wherein the compiler examines the variables to identify an

occurrence of a duplicate variable definition and to generate an error message in response

to the occurrence of a duplicate variable definition.

40. The tool of claim 39, further comprising a variable reordering facility receiving as

input a list of equations operating on variables and reordering at least one of the listed

equations to cause a first equation that is solved to generate a value of a variable to be

executed before a second equation that uses the variable in a calculation, where the first

equation followed the second equation in the list.

41. The tool of claim 40, wherein the graphical interface generates a flow diagram

representation of the model, the graphical interface further comprising a definition facility

accessible from the flow diagram representation, the definition facility adapted to receive

at least some of the variable definitions and equation definitions.

42. The tool of claim 35, wherein the compiler searches for a functional relationship

between a first and second variable defined as a table function mapping first variable

values onto second variable values and, when such a table function is found, the compiler

generates a segmented linear approximation of the table function relating the first values

to the second values.

43. The tool of claim 42, further comprising a simulator to solve equations at each of

a plurality of time intervals, the simulator adapted so that, when a segmented linear

approximation is present, the simulator calculates the segmented linear approximation at

one or more time intervals.

44. The tool of claim 42, wherein the compiler generates segmented linear

approximations by cubic spline interpolation.

45. A system dynamics modeling tool, including:

an interface for inputting a representation of one or more system dynamics model

elements;

a definition facility, linked to the interface, for defining one or more

characteristics of the model elements, the definition facility adapted to receive variable

definitions and equation definitions relating variables to other variables;

a compiler receiving as input a plurality of variables determined by operation of a

coπesponding plurality of equations, the compiler operating to identify a first subset of

the plurality of variables that do not vary in a given time and to identify a coπesponding

first subset of equations

a simulator to solve equations at each of a plurality of defined time intervals over

a length of a simulation, the simulator calculating a second subset of equations at each of

the plurality of time intervals and calculating the first subset of equations at fewer than

the plurality of time intervals.

46. The tool of claim 45, wherein the graphical interface is adapted to accept input to

define a first group and assign the first group a name, and to define a second group and

assign the second group a name, and wherein the graphical interface is adapted to show a

first flow diagram display for the first group and to show a second flow diagram display

for the second group.

47. The tool of claim 46, wherein the first subset of equations are the equations of the

first group and the second subset of equations are the equations of the second group.