December 1996 Volume 23 Number 6
One-stop modeling, simulation and analysis
By Anthony R. VanchieriDuring World War II, British military leaders asked scientists and engineers to analyze several military problems such as the deployment and distribution of radar sites, management of logistics, bombing, antisubmarine and mining operations. The application of mathematics and the "scientific method" to military operations was called "operations research ."
The problem with early uses of operations research was that it was just too hard. Even simple systems involved complex relationships that required extensive numerical computation. Analysts were often discouraged from addressing pressing, real-world issues because it was difficult, or even impossible, to carry out the calculations.
As operations research matured it naturally found a companion in another new field: simulation. Simulation began as a means to solve very difficult problems in studying random neutron diffusion in connection with development of the atomic bomb. Since this particular simulation process dealt with random events it was given the name "Monte Carlo"  methods in honor of the famous gaming casino.
Simulation now can be divided into two camps. Monte Carlo methods refer to simulation that deals with random numbers or random (stochastic) processes. System simulation refers to more pragmatic analytical techniques. System simulation models can be iconic like a globe of the earth, analogic in the sense that they resemble a physical system such as the flow of water through pipes, or logical (symbolic) like mathematical theorems . The single most important contribution to the union of operations research and simulation is the high speed digital computer  and the software to support simulation, modeling and analysis.
Today when we think of operations research (or "management science") we think of a scientific approach to decision-making. Typically we want to provide management with the ability to make decisions under conditions of uncertainty and to impose structure on a problem so that decisions are supportable. Simulation and modeling can be extremely complex and theoretical fields, and it is not possible for every analyst to become an "expert" in simulation theory or the mathematics of operations research. What we need today is a structure within which a competent analyst, with a broad knowledge of modeling and analytical techniques, can apply the methodology of operations research, simulation and modeling theory to get results. The focus  of the analyst is then to:
Simulation and modeling
All simulation models have a static and a dynamic structure. The static structure defines the possible states of the physical system, while the dynamic structure defines how the system changes over time. The static structure usually describes a collection of data objects and their possible states. The dynamic structure, on the other hand, may be described by various approaches. These approaches are called World Views. World Views are important because they define the approach that a simulation modeler will take when trying to address the dynamic and static aspects of a simulation. Two common types of World Views are event scheduling and process interaction.
In event scheduling the modeler defines a series of events and the interactions between and among them. Events can cause other events to occur, or cancel previously scheduled events. The modeler's strategy is to repeatedly select the earliest scheduled event, advance the simulation clock to the time of that event, and then to carry out the event. An example of this World View is that of tug boats that service ships as they off-load oil. The tug boats would operate with given times to service the oil tankers. The modeler would scan a list of tug boat service times, continually seeking the earliest time to schedule another tug boat. An event scheduling simulation model is driven by the simulation clock.
In process interaction the modeler does not explicitly define the types of events that can occur, but rather a set of processes. These processes are a series of activities that generally operate in sequential order. The activities must be completed in an established order with later activities having to wait until earlier activities have completed their process. A simple example may be that of a one-chair barbershop. Customers enter the barbershop and, if the barber is busy, wait for service. Customers are served in order, with later customers waiting for earlier customers to complete service. Another common name for this type of model is mechanistic as it describes the mechanics by which a system and its components operate.
What is ModelMaker?
ModelMaker is a process interaction, or mechanistic, model and can be characterized as:
The primary objective of ModelMaker is to provide the user an intuitive, easy-to-use software environment wherein the user simply enters equations or formulae and runs the program without the need for programming or coding. ModelMaker has as its advantages:
System requirements are quite modest. All one needs is an IBM-compatible personal computer running Windows 3.x or higher, and a minimum of 2Mb RAM, a mouse, or other pointing device. ModelMaker occupies just under 800K of disk space. We evaluated ModelMaker version 2.0c on a mid-level personal computer: an IBM PS/1 (486/50mhz) with 12Mb RAM.
ModelMaker is a Windows product, and installation is accomplished in the usual Windows fashion. ModelMaker comes on one 3.5-inch, 1.44Mb floppy diskette. One inserts ModelMaker into the A drive, selects "Run" from the Program Manager, and then types a:\setup.exe. Before ModelMaker begins installation, the installation routine asks the user to enter his name and organization. This information is later displayed as part of the ModelMaker startup window when the program is launched. ModelMaker installs itself quite nicely into the c: drive. The default installation directory is c:\mm; the user may elect to change the default directory during the installation process. ModelMaker does not modify any system files (autoexec.bat, command.com, config.sys, or win.ini) during the installation procedure. ModelMaker is not copy protected but the user's name and organization, previously entered, is permanently written to the install disk.
Building a Model with ModelMaker
The mechanistic nature of ModelMaker is seen in the philosophy that, to model a complex system, one must first break down the system into "components." One inserts these various model components into the "diagram window," defines the rules by which these components operate, show how these components relate to each other, and then run the model. ModelMaker uses an interesting mix of analog and symbolic modeling philosophies tied together through Window's powerful graphics capabilities. Instead of coding the model, as one might code a FORTRAN or C++ model, the user accesses ModelMaker's library of modeling components and builds the model using a set of graphics symbols and icons. These graphical symbols form a diagram, and the diagram provides the visual guide to the structure of the model. By looking at the diagram one can get a feel for how the various components relate to one another from a network of "influences."
ModelMaker gives the user a leg-up by offering 10 different types of model components from which to select. Each model component serves a specific function. The user builds the model by selecting the component that best represents the analytical function for the piece of the system that one is modeling. A basic ModelMaker model consists of several elements:
The best way to understand ModelMaker and to see how these elements combine in a model is to look at a simple example. What if we wanted to model a system of two lakes. One lake empties into the other lake and the water level of this lake is dependent upon the first lake's runoff. As with any modeling effort we begin with steps 1-5 of our eight modeling steps.
We may assume that 100,000 cubic meters of water flow into Lake 1 each day and that the flow out of Lake 1 is about 5 percent of the volume of the water. This would typically be represented by the differential equation:
--------- = 100,000 - 0.05(Lake 1)
Now we ask the question, "what is the water level of Lake 2 per unit time?" To many this may seem a daunting task, but it is quite easily achieved in ModelMaker. We begin by "inserting" the compartment into the empty diagram window.
Inserting a compartment into a diagram window entails three steps:
The result of the three inserting steps outlined above is Figure 1. We inserted two compartments, Lake1 and Lake2, into the diagram window and showed the relationship between these two lakes with the influence symbol. One can literally read this pictogram as "Lake 1 influences Lake 2." This is what we intend to model, and we can see the relationship of the system quite nicely. Now we need to define the rules by which these systems operate.
We define the compartment's properties through the Compartment Definition dialog box. An easy way to invoke this dialog box is by double clicking on the compartment in the diagram. If we double click on Lake1, ModelMaker offers us the Compartment Definition dialog box seen in Figure 2.
In Figure 2 we define the water level of Lake1 through a differential equation. The differential equation is simply entered into the "Equation" line of the dialog box. The other items in the Compartment Definition, such as the Xed boxes, are default values. The user can modify these values depending upon need; this is easily explained in the user's manual. ModelMaker performs error-checking tasks on the entered equation, such as looking for "undefined variables," and warns if any are found. This gives the user the opportunity to recheck the equation for errors at the time the equation is written.
After we define Lake 1 we use the same procedure to define Lake 2. When done, we are back to Figure 1 and we see two components, Lake 1 and Lake 2. Restrictions imposed by the Windows operating system limits the modeler to 5,000 components (imagine Figure 1 with 5,000 Lakes!). The practical limit is about 1,000 components before your PC grinds to a halt. We found that about 100 components was manageable before the Diagram Window was too visually saturated for our taste.
All we need to do now is run the model.
Running the Model, Interpreting Results
To run this model one need simply select "Run" from ModelMaker's menu. ModelMaker checks for errors and, if none are found, executes the model according to the relationships defined by the user. Once the model is run, the user can access two types of output: Graphs and Tables. Graphs and Tables are accessible from either the "View" menu item or may be selected individually from ModelMaker's Toolbar. Both the Graph and Table options follow the same format. One selects a desired output type and is presented with a Graph (or Table) Selection dialog box. ModelMaker automatically offers the user those components of the model that are available as output, and the user simply selects them. In the case of our two-lake system we select time as the X-axis value, both Lake1 and Lake2 for the Y-axis value and voilá! a graph.
Figure 3 is typical of ModelMaker's graphic capabilities. As usual, with either graphs or tables, the user has a host of options to customize the output to meet specific needs. Here we see the graph with the addition of axis labels. ModelMaker's Graph and Table options are very simple and intuitive. Indeed one need not even consult the user's manual to generate a graph or table. All one need do is explore the Graph and Table menu options -- simplicity itself.
More Complex Models
Our two-lake system serves to illustrate the basics of ModelMaker, but does not fully capture the ability to model sophisticated or complex systems under ModelMaker. If we consider the two-lake model on the simple end of the spectrum, then we might consider stochastic models on the complex end. ModelMaker can handle both ends of the modeling spectrum.
Stochastic models simulate systems that contain random events. The largest class of these models is the traditional discreet event, dynamic system (DEDS). Such systems are driven by a random input stream and produce a random output. Since any particular realization (output) from a DEDS is itself random, the DEDS modeler must run the model many times and average the output of the many runs. This average obeys certain statistical properties. If the analyst runs the model a sufficient number of times, the average of all the individual model runs eventually converges to the "true" average . Consider the example of modeling some infectious disease. Passing the disease from an infected person to a healthy person is essentially a random process . To model this system we must make some assumptions, the most important being the probabilistic distribution that governs the infection process. We proceed this way:
A Note on Documentation
We have worked through a small example to show the basic structure of ModelMaker. It is important to note, though, that any modeling software is only as good as the accompanying user's manual. One would expect there to be somewhat of a "learning curve" with any new tool. The "teaching package" that comes with the software must get the analyst up to speed fast.
ModelMaker comes with plenty of excellent, easy-to-use tutorials that closely follow the instructional material in the user's manual. The first nine chapters offer detailed tutorials supported by examples the user can load into the model and run while reading the manual. The remaining 18 chapters offer detailed explanations of the technical aspects of ModelMaker, from an explanation of the different optimization methods, to how ModelMaker calculates Goodness-of-Fit statistics. Many of ModelMaker's technical sections could stand on their own as primers for those who may have forgotten the difference, say, between the Mid-Point and Runge-Kutta method of solving differential equations. ModelMaker's on-line help is quite good and follows the printed text. In fact, one could work through the tutorials using nothing but the on-line help. One may also find some good on-line information through the Internet and Cherwell's home page (see Product Information).
In the truly nit-picking category, the occasional European spelling catches one's eye. We might expect "minimise" for minimize, but "sceptical" for skeptical stopped me in my tracks.
If I Had Three Wishes...
ModelMaker is a good well-rounded modeling package, but if I had three wishes for product improvement, what would they be?
My first wish: focus. ModelMaker seems a bit focused toward the physical sciences. One could quite easily model a physical process such as plant growth. I am not certain one would be able to easily model a system composed of entities with each entity having its own attributes like a multiple rail subway system, a traffic flow at a highway tollbooth, or an assembly line.
ModelMaker is not designed to handle queueing models without considerable effort. I was able to write a module to accommodate a very simple single-server queue. This would be the "one-chair barbershop" example cited earlier, otherwise known as an M/M/1 queueing system. I do not think ModelMaker can handle queues of any sophistication above the simple M/M/1 and its measures of effectiveness. Since queueing models pop up in the most routine places (anytime there is a contention for resources you have a queue), it would be nice if ModelMaker directly supported queueing applications in future versions.
In addition to queueing, I do not think ModelMaker is designed for certain business applications. ModelMaker was able to accommodate a deterministic economic order quantity (EOQ) model with relative ease. Things became rather difficult when trying to model uncertainty as in (r, q) or (s, S) EOQ models. Similarly, it was difficult to model periodic cash flow or investment decisions.
My second wish: simulation. ModelMaker offers good, basic simulation methods that conform to accepted simulation practices and standards. For those who do not particularly care to become "expert" in stochastic simulation theory, ModelMaker offers the traditional simulation "black box": the user selects a distribution, enters a few operating parameters, and runs the simulation. Even so, ModelMaker is a bit light on distributions. While it is true that the normal, exponential and uniform distributions have broad applicability they tend to be limiting. I would not choose any of these distributions to model human performance, such as the time it takes a person to complete some task. For this model I would want a Weibull distribution.
Another note is that ModelMaker's exponential distribution (rande) does not allow the user to select a mean. The exponential distribution, XXX, is really an infinite family of distributions whose shape, or decay rate, is governed by the parameter XXX (alpha). The user should get to pick the value for alpha to specify which of the many exponential functions one wants to model. ModelMaker gives the user no facility for picking alpha so the question arises, which exponential function are we using when we specify rande? I think ModelMaker fixes (XXX = 1; the user must be aware of this when using the rande function as it limits its usefulness.
One more consideration is the need to perform multiple runs of a simulation model, and to average the individual runs to find the true system average. ModelMaker offers the user the opportunity to see the individual runs by selecting "Retained Series" from the Graph or Table menu. Thus, if one has 30 model runs, there will be 30 retained series. I am ambivalent about seeing any one of the particular series (since it is just one realization of a random process), but I would like to see the average and variance of all of the retained series. The user could write a routine to do this in ModelMaker, but it is tedious. The user could also create a table, copy it to the clipboard or to a file, and import that into a statistical package. This is not a show-stopper, but why can't ModelMaker have a simple menu option for the mean and variance of retained series?
My third wish: lower level control. One of the things one must consider in devising a model is how to mathematically represent the physical world (modeling step 3). ModelMaker has a nice, easy way to facilitate this process through its compartment and variable components. At times this ease of use restrains one from taking more control over model formulation, specially when the needed mathematical representations are not part of ModelMaker library. As noted earlier, one can easy solve complicated differential equations because ModelMaker facilitates this specifically.
It would be nice if, in future versions, ModelMaker added the facility for user specific iterative calculations, or even a linking module where the user could code specific formulae in another programming language, and then link that code externally to ModelMaker.
In a survey of operations research/management science departments in corporate organizations, simulation ranked second of 14  techniques (between statistical analysis and linear programming) as a means to address their analytical concerns. ModelMaker is the all-in-one package that gives the analyst the ability to perform simulation, statistical analysis of output and optimization of results.
ModelMaker needs to continue to work on its Monte Carlo simulation. Nevertheless, ModelMaker is a technically sound and simple modeling package with great application for OR/MS use.
The hallmark of any good modeling package is whether the analyst can use it now, get results fast, and change the scenario for what-if decision-making. The analyst wants to spend time working the problem, not figuring out the software. ModelMaker fits this nicely.
Anthony R. Vanchieri is a senior operations research analyst with the Program Analysis and Operations Branch, Federal Aviation Administration, Washington, D.C. He can be reached at: email@example.com or visit http://www.orlab.faa.gov
ModelMaker is distributed by Cherwell Scientific Publishing Inc., 744 San Antonio Road, Palo Alto, CA 94303.
ModelMaker is available in the U.S. for $499 plus $20 shipping and handling. Discounts are available for purchases of five or more packages, or "lab packs" for education. Call Cherwell for details. For orders and more information in the U.S.: Phone: (415) 852-0720; Fax: (415) 852-0723; E-mail: firstname.lastname@example.org; Home Page: http://www.cherwell.com/cherwell
Cherwell also has offices in Oxford, England and Frankfurt, Germany. Customers outside North and South America should contact the U.K. office at: Phone: +44 1 865 784 800; Fax: +44 1 865 784
Editor's Note: It is the policy of OR/MS Today to allow developers of software an opportunity to clarify and/or comment on the review article. Following are comments from Catriona Galbraith, development manager of Cherwell Scientific Publishing.
We have been busy with the development of the new version of ModelMaker and expect to launch version 3.0 in the first quarter of 1997. Interested beta testers should contact: email@example.com. Version 3.0 will have the facility to build in user-defined code in the form of Windows DLL functions. Other features such as sub-models and arrays will aid the design of more complex models. Simplex model optimization as well as Marquardt will also be available in version 3.0.
Correspondence regarding the software reviews should be sent to OR/MS Today software review editor, Saba Bahouth. Individuals interested in reviewing software for OR/MS Today or companies looking to have their products reviewed in the magazine should contact Bahouth directly at the University of Central Oklahoma. College of Business Administration, Edmond, OK 73034-5209; Phone: (405) 341-2980, ext. 2163; Fax: (405) 330-3821; e-mail: firstname.lastname@example.org
OR/MS Today copyright © 1997, 1998 by the Institute for Operations Research and the Management Sciences. All rights reserved.