Basic Introduction to STELLA II

Dr. Richard Palmer

Professor of Civil and Environmental Engineering
Box 352700
University of Washington
Seattle, Washington 98195-2700
(206) 685-2658
palmer@u.washington.edu
Table of Contents
1. Object Oriented Programming.....................................................................................................1
1.1 General Modeling Approach..................................................................................................1
1.2 Why Use Object Oriented Programming? .............................................................................1
1.3 Selection of STELLA

II as OOP Environment...................................................................1
2. STELLA

II Modeling................................................................................................................2
2.1 Basic Tools ............................................................................................................................2
2.2 STELLA

II Interface ...........................................................................................................3
2.3 Simple Example of STELLA II Model Construction .........................................................5
2.4 Running a Model ...................................................................................................................9
2.5 Navigating Through a Model...............................................................................................10
2.6 Time Specifications .............................................................................................................11
2.7 Time Steps ...........................................................................................................................11
2.8 Graphs..................................................................................................................................12
2.9 Tables...................................................................................................................................12
2.10 Expanding a Model (Copying and Pasting) .......................................................................12
3. Use of STELLA for Reservoir Operation ..................................................................................15
3.1 Continuity, Some Background.............................................................................................16
3.2 Demand................................................................................................................................17
3.3 Inflows .................................................................................................................................19
3.4 Draft .....................................................................................................................................21
3.5 Spill......................................................................................................................................21
3.6 Operating Rules ...................................................................................................................22
3.7 Run Time Increment (DT) ...................................................................................................22
3.8 Maximum Storage................................................................................................................22
4. Advanced Features.....................................................................................................................22
4.1 Tools for Clarity...................................................................................................................24
4.1.1 Variable Documentation ...............................................................................................24
4.1.2 On-Screen Documentation............................................................................................25
4.1.3 Ghosts ...........................................................................................................................26
4.1.4 Development of Hierarchies .........................................................................................26
4.1.5 Sectors...........................................................................................................................27
4.1.6 Color .............................................................................................................................28
4.2 Sensitivity Analysis..............................................................................................................28
4.3 Model Completeness............................................................................................................29
4.4 Modeling of System Performance........................................................................................30
4.4.1 System Reliability.........................................................................................................30
4.4.2 Biological Impacts ........................................................................................................30
4.4.3 Economic Impacts.........................................................................................................30
4.4.4 Political and Social Impacts..........................................................................................31
4.5 Programming Lessons..........................................................................................................31
4.5.1 General Lessons ............................................................................................................31
4.5.1.1 Good models start with clear study objectives.......................................................31
4.5.1.2 Good models continue with a definition of what is important in the system.........32
4.5.1.3 Time allocation during modeling effort .................................................................32
4.5.1.4 Model Clarity.........................................................................................................32
4.5.1.5 Simplicity vs. Complexity......................................................................................32
4.5.2 STELLA Lessons ..........................................................................................................32
4.5.2.1 Non-negativity requirements..................................................................................32
4.5.2.2 Discrete vs. Continuous data and graphs ...............................................................33
4.5.2.3 Beginning and ending storages vs. end of period values .......................................33
4.5.2.4 Variable Naming Conventions...............................................................................33
4.5.2.5 Limits on Input Data ..............................................................................................33
4.5.2.6 Impacts on Changing Time Steps ..........................................................................34
4.5.2.7 Printing and Pages..................................................................................................34
5. Dynamic Data Exchange............................................................................................................34
5.1 General Rules.......................................................................................................................35
5.2 STELLAII as a client ........................................................................................................35
5.3 STELLAII as a server .......................................................................................................36
List of Figures
FIGURE 2.1. BASIC MODELING ICONS IN STELLA ............................................................................................3
FIGURE 2.2. BASIC STELLA USER INTERFACE...................................................................................................4
FIGURE 2.3. COMPONENTS OF CHECKING ACCOUNT EXAMPLE..................................................................5
FIGURE 2.4. LINKING THE COMPONENTS OF CHECKING ACCOUNT EXAMPLE .......................................6
FIGURE 2.5. DEVELOPING CAUSAL RELATIONSHIPS IN THE CHECKING ACCOUNT
EXAMPLE...........................................................................................................................................................7
FIGURE 2.6. ENTERING VALUE FOR INCOME INTO THE CHECKING ACCOUNT EXAMPLE....................8
FIGURE 2.7. ENTERING FUNCTIONAL RELATIONSHIP FOR ACCOUNT_TRANSFER INTO THE
CHECKING ACCOUNT EXAMPLE .................................................................................................................9
FIGURE 2.8. MAIN MENU IN A STELLA MODEL.................................................................................................9
FIGURE 2.9. OPTIONS FOR RUNNING A MODEL..............................................................................................10
FIGURE 2.10. OPTIONS FOR TIME SPECIFICATIONS.......................................................................................11
FIGURE 2.11. OPTIONS FOR GRAPH FUNCTION...............................................................................................12
FIGURE 2.12. COPYING THE ICONS OF A STELLA DIAGRAM.......................................................................13
FIGURE 2.13. RESULT AFTER COPYING AND PASTING ICONS.....................................................................15
FIGURE 3.1. COMPONENTS OF SIMPLE RESERVOIR MODEL........................................................................16
FIGURE 3.2. DEVELOPING DEMAND ..................................................................................................................17
FIGURE 3.3. DEVELOPING DEMAND ..................................................................................................................18
FIGURE 3.4. DEFINING THE CONVERTER MGD\ACT\MONTH.......................................................................19
FIGURE 3.5. MAKING DATA A FUNCTION OF TIME........................................................................................20
FIGURE 3.6. PREPARING DATA CONVERTER FOR INPUT..............................................................................20
FIGURE 3.7. INPUT OF VALUES TO ICON DATA...............................................................................................21
FIGURE 4.1. WELL-CONSTRUCTED STELLA MODEL OF A SIMPLE RESERVOIR SYSTEM.....................23
FIGURE 4.2. POORLY CONSTRUCTED STELLA MODEL OF A SIMPLE RESERVOIR SYSTEM.................24
FIGURE 4.3. VARIABLE DOCUMENTATION IN STELLA MODEL..................................................................25
FIGURE 4.4. ON-SCREEN DOCUMENTATION IN STELLA MODEL................................................................26
FIGURE 4.5. SECTOR IN STELLA MODEL...........................................................................................................28
FIGURE 4.6. SENSITIVITY SPECIFICATIONS IN STELLA MODEL.................................................................29
1. Object Oriented Programming
The modeling approach taken in this project is significantly different from that typically
taken in the development of water resources planning and management models.
Specifically, the major players in the management of water resources in the region were
identified, interviewed to determine what should be in the model and then encouraged to
be actively involved in the model construction. This involvement was achieved with the
use of workshops and further interviews.
1.1 General Modeling Approach
To allow for the participation of non-programmers in the modeling process, an object-
oriented programming environment was selected. This environment provides a graphical,
object-oriented interface that allows the user to model complex systems without requiring
proficiency in computer programming. An understanding of important system
components and their interactions are the primary prerequisites for model development.
Thus, the start up time for model development in these environments is minimal.
The developer interface for object-oriented models is very different than those for
traditional programming languages such as FORTRAN. Rather than writing instructions
line by line, the user builds a model using a set of object icons. Each object represents a
type of action or process and has specific attributes that define how it interacts with other
objects in the system. To create a model in this environment, the user selects appropriate
icons to emulate important system components. Relations between objects are then
established by graphically drawing appropriate connections. Once these connections are
established, the user specifies the functional relationships between components and initial
values to complete the model. This user interface is more efficient than traditional
programming in terms of time required developing the model.
1.2 Why Use Object Oriented Programming?
There are five primary advantages in using object-oriented programming (OOP) for the
construction of water resources models. They are: 1) the increased speed of model
development, 2) the ease of model modification, 3) the facility with which model results
can be communicated, 4) the possibility of group model development, and 5) the trust
developed in the model. Each of these advantages will become obvious as the description
of model development and implementation is described. We will return to these
advantages in the summary section.
1.3 Selection of STELLA

II as OOP Environment
The OOP environment chosen to develop the models of the WIRM Model of Bull Run
Water Supply for the Portland Water Bureau was STELLA

II. This software is

developed and marketed by High Performance Systems. Throughout the remainder of
this report the term STELLA refers to High Performance System's latest software release,
2
STELLA

II version 5.1.1. STELLA was first sold in 1986 and has been used in
academic, research and consulting environments since that time. It is arguably the most
popular and efficient tool available for constructing graphical simulation models currently
on the market. Product sales have continued to increase in recent years and it has begun
receiving significant attention from the professional water resource management
community.
2. STELLA

II Modeling
As indicated previously, STELLA (Systems Thinking Environment) is an object-oriented,
graphical modeling environment. In this environment a few basic icons (or objects)
simulate processes. This chapter contains a description of the basic icons and a simple
model. Basic features of the STELLA environment are then explored using this example.
2.1 Basic Tools
Model development using object-oriented programming (OOP), such as STELLA is both
similar to and different from typical model development. Like typical development, the
functions the model performs must be defined, the system must be conceptualized and a
model constructed. The relationships of each component to one another must be
established. In some cases, these relationships may be physical relationships. For
instance, the storage behind a dam at a point in time is affected by the storage in the
previous period, the volume of inflow during the ensuing period, the releases and spills
made from the dam, and the dam's capacity. In other cases, these relationships may be
more conceptual in nature.
However, the manner in which these components are incorporated into the programming
environment in OOP is remarkably different from more conventional languages such as
FORTRAN. Using OOP, once a component is identified, it is incorporated into the
model by defining it as a unique object. In this fashion it is assigned a specific label or
name.
It is difficult to illustrate the process of developing models in an OOP environment
without the aid of animation. Initial stages of model development are similar to using
computer drafting or drawing software in which the user simply selects from a series of
existing icons or templates and draws what is desired. When initiating the modeling
process, the model builder is presented with a blank page onto which all of the
components necessary to model the system are placed. There are four basic tools in the
STELLA environment for model diagram development: Stocks Flows, Converters and
Connectors (Figure 2.1).
Stocks are used to represent system components that can accumulate material over time.
Stocks can reflect the system state or condition as it changes over time. In the examples
that follow, reservoirs are always represented as stocks. Stocks often represent other
items as well. For instance, stocks define the cumulative differences between an in-
3
stream fish flow and a release. In STELLA, a rectangular icon represents stocks (as
shown in Figure 2.1).
Figure 2.1. Basic Modeling Icons in STELLA
Flows represent components whose values are measured as rates. These rates may be a
constant, a function of time or a function of some other component in the system. A flow
can supply or drain a stock by flowing into or out of it. For example, inflows, spills and
releases from reservoirs are flows. The flow icon is the directed pipe with a flow
regulator attached (see Figure 2.1). Flows can also be bi-directional, indicating that flow
can go in either direction.
Converters can represent constants, variables, functions, or time series. They also can
transform stocks and flows into other values. Converters can be represented as graphical
functions. This enables the modeler to sketch relationships between model variables
without resorting to complex analytical expressions. A circular icon (Figure 2.1)
represents convertors.
Connectors indicate the cause/effect relationship between diagram components. If a
connector is drawn from one component (circle end) to another (tip of the arrow) then the
first component defines (or influences) the value of the second component. This
graphical indication of interaction helps model users understand STELLA diagrams.
The four basic building blocks of STELLA

are described on pages 4-9 to 4-22 of the
STELLA Tutorial and Technical Documentation Manual.
2.2 STELLA

II Interface
The icons just described are presented in a very simple and intuitive user interface
(
4
Figure 2.2). As shown, the four major icons are presented in a selection palette at the top
of the main menu. The remaining icons on the palette perform other useful functions, all
of which are described in the STELLA Tutorial and Technical Documentation Manual
(pages 5-1 to 6-38). STELLA defines the first four itemsHand, Paint Brush, Dynamite
and Ghostas Tools. STELLA defines the Sector Frame, Text Block, Graph Pad and
Table Pad as objects. Each are briefly described below.
Hand: This icon allows the user to choose, place or move model building blocks within a
model. It also allows selection of other STELLA objects. The Hand is described on
pages 5-2 to 5-12 of the Technical Documentation.
Paint Brush: This icon allows the user to change the color of building blocks and objects
in the STELLA diagram. The Paint Brush is described on pages 5-13 to 5-14 of the
Technical Documentation.
Figure 2.2. Basic STELLA User Interface
Dynamite: This icon is used to delete existing portions of a model. When selected, the
user can delete an object by placing the dynamite on it and clicking the mouse. The
Dynamite tool is described on pages 5-15 to 5-17 of the Technical Documentation.
Ghost: Selection of this icon allows the user to create a replica of an existing building
block for use in another area of the model. Ghosts improve model clarity. Later sections
more fully describe the Ghost. Pages 5-18 to 5-19 of the Technical Documentation
describe the Ghost.
Sector Frame: Selection of this icon allows the creation of a sector in a diagram. Sectors
aid the user in organizing a cluster of building blocks and objects. Sectors are described
on pages 6-31 to 6-38 of the Technical Documentation.
Text Block: This icon allows the user to add on-line documentation in the model. The
Text Block is described on pages 6-2 to 6-3 of the Technical Documentation.
Graph Pad: This icon creates a graph of the behavior of selected model components.
The Graph Pad is described on pages 6-4 to 6-13 of the Technical Documentation.
5
Table Pad: This icon creates a table of values over time for selected model components.
The Table Pad is described on pages 6-14 to 6-28 of the Technical Documentation.
2.3 Simple Example of STELLA II Model Construction
A good example is a simple personal finance model.
Steve receives $3,000 a month in income. This amount is not expected
to change over the next year. His monthly expenses can be divided into
two categories: fixed costs (rent, food, clothing, etc.) and variable costs.
Fixed costs are also a constant value of $1,500. The variable costs are a
function of how rich Steve feels. Steve spends 25% of all the money he
has in his checking account over $2,000. Because he recognizes this
tendency, he often transfers money between his checking account and his
savings account. Currently, he transfers all of the money greater than
$3,000 from his checking account into his savings account.
There are four steps to take in creating a STELLA model
1. define variables in the problem and translate them into STELLA notation;
2. link stocks and flows;
3. define influences between stocks, flows, and converters;
4. create functional relationships between stocks, flows, and converters.
This example requires six components: four flows and two stocks. Figure 2.3 illustrates
these components. Each building block is created by placing the mouse pointer on the
needed icon in the tool bar, clicking the mouse button, dragging the building block onto
the page, and clicking the mouse button at the desired location. When a building block is
created, it remains highlighted until the mouse is clicked in another location. A building
block can be selected by clicking on it. When the building block is highlighted, its name
can be entered or changed by use of the keyboard.
Figure 2.3. Components of Checking Account Example
6
The next step is to define the system by linking the building blocks. These links should
indicate exactly how the flows and stocks are related (what defines inflows and outflows
to stocks). In STELLA, this is accomplished by moving the previously created building
blocks. To do this, place the cursor on the building block, hold the mouse button down,
move the mouse to the desired location, and release the button. When the building block
is located at the appropriate position, the mouse button is released. When a stock is to be
connected to a flow, the stock should be moved over the appropriate end of the flow and
centered on the "cloud" portion of the flow. When STELLA recognizes that the user is
attempting to connect these two icons, the cloud will become "fuzzy." Once connected,
movement of either the flow or the stock will not break this connection. The results of
connecting the flows to the stocks are illustrated in Figure 2.4.
Figure 2.4. Linking the Components of Checking Account Example
The third step is to depict influences between variables. This is accomplished by using
the connector tool to create the appropriate links. To do this, select the connector icon
from the icon palette, click and hold on the influencing icon, move the cursor to the
influenced icon, and release the mouse button. As shown in Figure 2.5,
Variable_Expenses are a function of the balance in the Checking_Account.
Variable_Expenses, in turn, influence the Account_Transfer as do
Fixed_Expenses, Checking_Account Balance, and Income.
7
Figure 2.5. Developing Causal Relationships in the Checking Account Example
The final step is to define functional relationships between variables and establish
constants. In this simple model, Income is a constant rate of $3,000 per month. This
information is incorporated into the model by double clicking on the variable Income,
which activates the menu for that variable (Figure 2.6). Once within the menu for the
variable, the value of 3,000 is entered on the keyboard or by using the number pad on the
screen. A value of $2,500 for Fixed_Expenses is entered similarly.
8
Figure 2.6. Entering Value for Income into the Checking Account Example
The functional relationship for Account_Transfer, must define the amount of
money transferred from the checking account to the savings account. This is
accomplished by double clicking on the Account Transfer flow icon. After double
clicking, the Account_Transfer window appears (Figure 2.7). This window allows
the model builder to write equations for the variable Account_Transfer. As
indicated in the figure, the required inputs for Account_Transfer are
Checking_Account, Fixed_Expenses, Variable_Expenses, and
Income. The equation that defines Account_Transfer as a function of these
variables is illustrated in the box following Account_Transfer =.... In a similar
manner, the appropriate equation for Variable_Expenses is entered.
9
Figure 2.7. Entering Functional Relationship for Account_Transfer into the
Checking Account Example
To enter the equation for Account_Transfer, the modeler starts by clicking in the
equation box and typing the word "IF." Rather than typing the variable name
Checking_Account, the modeler can simply click on that name in the "Required
Inputs" list. The modeler then clicks on the "+" sign on the numeric pad, clicks on the
variable Income in the "Required Inputs" list, and continues until the entire equation is
entered. All of the variables in the "Required Inputs" list must be included in the
equation, else STELLA indicates this as a problem to the modeler. Similarly, if variables
not in the Required Inputs list are used, STELLA will indicate a problem.
2.4 Running a Model
After the building blocks have been defined, links established between stocks and flows,
influences established, and constants and functional relationships between variables
placed in the model, the model can run. This is done by selecting the Run Option located
in the main menu (shown in Figure 2.8).
Figure 2.8. Main Menu in a STELLA Model
10
When the Run Menu is selected, the seven options in the pull down menu appear (Figure
2.9).
Run Executes the model over the prescribed time period.
Pause Causes a running model to pause (stop running). The model can be re-started, if
desired.
Stop Causes a running model to stop executing without the possibility to resume.
Sector Specs Allows the user to run the entire model or one or more specified sectors of
the model.
Sensi Specs Allows the user to determine model sensitivity to a variable.
Time Specs Allows the user to establish the time period for the model, such as
beginning time step, ending time step, and value of DT (see more detailed description
below).
Range Specs Allows the user to set value for variables that will appear in graphs.
Figure 2.9. Options for Running a Model
2.5 Navigating Through a Model
One can navigate (or browse) through a model in two fashions. Scroll bars (located on
the right hand side and bottom of the model) may be used to move through the model.
Clicking on an arrow key in the scroll bar area (up-arrow, down-arrow, right-arrow, or
left arrow) moves the user through the model in small increments. Clicking directly in
the scroll bar moves the model in large increments, the direction depends upon the
location of the cursor with respect to the location of the scroll indicator.
11
One may also "zoom" in and out of a diagram using the Zoom buttons located at the
bottom left of the diagram and shown as "+" and "-" signs. For complex models,
zooming out allows the modeler and model user to obtain an overview of all model
components.
2.6 Time Specifications
The Time Specs option allows the user to define a number of variables that control the
execution of the model. These variables include the beginning time period, the ending
period, and the Integration Method. There are three numerical methods used in STELLA
to numerically solve a differential equation. These are Euler's Method, Runge-Kutta 2 or
Runge-Kutta 4. The integration methods are described on pages 12-1 to 12-13 of the
Technical Documentation.
2.7 Time Steps
Another important feature defined in the Time Specs option is the time step. This time
step allows the user to define the frequency at which the numerical integration is
performed. Stated differently, the time step allows the user to take a model that has been
developed at a specified time step, such as monthly, and evaluate the model at a different
time step, such as weekly. This is accomplished by changing the value of DT in the Time
Specifications (Figure 2.10).
Figure 2.10. Options for Time Specifications
12
2.8 Graphs
Graphs can be easily created in STELLA with the use of the Graph Pad icon in the main
menu. Selection of this icon results in the creation of an empty graph. Double clicking
on the graph icon displays the graph definition window shown in Figure 2.11. Choose a
particular item to be graphed by highlighting the item in the list located in the upper left-
hand portion of the page. This places the item in the list in the upper right-hand portion
of the page. Up to five items can be placed in a single graph. The three types of graphs
are, time series, scatter plots, and comparative graphs. Details on each of these options
are on pages 6-4 to 6-13 of the Technical Documentation.
Figure 2.11. Options for Graph Function
2.9 Tables
The user can create tables of values in a STELLA model by selecting the Table Icon from
the tool bar. Selection of this icon results in the creation of an empty table. Double
clicking on the table displays the table definition window. The user can choose a
particular item to be in the table by highlighting the item in the list located in the upper
left-hand portion of the page, then double clicking the >>. This moves the item to the
active list in the upper right-hand portion of the page. There is no limit on the number of
items placed in the table. Details on these options are on pages 6-14 to 6-28 of the
Technical Documentation.
2.10 Expanding a Model (Copying and Pasting)
There are two ways to expand a model, by selecting individual building blocks from the
tool bar, or by copying and pasting existing blocks. Referring to the finance example, if
the user needed a second income and saving account (perhaps that of a spouse), the user
13
could mark the existing icons with the use of the "Hand" icon, copy the group of icons
(Figure 2.12), and then use the Paste command to place to copied entities.
Figure 2.12. Copying the Icons of a STELLA Diagram
To mark and copy objects, select the hand icon from the tool bar, click and hold the
mouse button, drag the mouse to outline the desired area, and then release the mouse
14
button. This results in a copy of the complete set of icons, including the functional
relationships (
Figure 2.13). Note that the only difference between the original and the copy is that a 2
has been added to each of the duplicates names. STELLA requires each object to have a
unique name, therefore the duplicates names are modified from the original. The new set
of icons are independent objects which can be modified without affecting the originals.
15
Figure 2.13. Result After Copying and Pasting Icons
3. Use of STELLA for Reservoir Operation
The previous sections covered the general process of creating a STELLA model. In
Section 3, a very simple example of modeling a reservoir is presented. The example
includes a general discussion of continuity within the reservoir, inflows, demand,
releases, spills, and operating rules. To make the model somewhat realistic, a simple
setting will be defined and expanded upon later. It is assumed that the "safe yield" of a
reservoir is to be evaluated.
16
The drainage area of the reservoir is 450 square miles. A gauging station
exists on the stream where the drainage area is 350 square miles. A
reservoir capacity of 50,000 acre feet is being evaluated. The safe yield
is to be determined by a trial and error approach.
3.1 Continuity, Some Background
The fundamental concept in reservoir operation is that of continuity. This concept
requires that the difference between storage in one period and another be defined by what
has entered the reservoir during that period minus what has been removed. Stream flow
and rainfall are examples of potential additions to the reservoir. Evaporation, seepage,
spills, and releases are examples of debits from the reservoir. The concept of continuity
is also one of the fundamental modeling characteristics of STELLA. Typically, a stock is
used to represent a reservoir. STELLA automatically creates continuity equations for
stocks when flows are directed into or out of a stock.
Suppose the simple system shown in Figure 3.1 is created using the basic icons of
STELLA.
Figure 3.1. Components of Simple Reservoir Model
The equations created by STELLA for the reservoir are:
Reservoir(t) = Reservoir(t - dt) + (Inflow - Release) * dt
INIT Reservoir = { Place initial value here }
INFLOWS:
Inflow = { Place right hand side of equation here }
OUTFLOWS:
Release = { Place right hand side of equation here }
17
The first equation in the set is the continuity equation for the reservoir. At this stage in
the development of the model, the continuity equation states that the variable
Reservoir, is a function of its value at the previous time (t-dt) plus the difference
between the Inflow and Release rate, times the time step (dt). As indicated by the
equations, there is no initial value for storage and the inflows and outflows are not yet
defined.
3.2 Demand
Water demand typically exhibits monthly variations. For simplicity, it is assumed that
demand is constant during the winter, ramps-up to a maximum value during the summer
and then ramps-down to the winter demand during the fall. Five variables will be used in
modeling demand: Month, Monthly_Demand, Demand, Growth_Factor, and
MGD/CFS (shown in Figure 3.2).
Figure 3.2. Developing Demand
The variable Month is an index describing the month's number. The data in this model is
organized in water years, so when Month = 1 it is October, when Month = 2 it is
November, and so on until when Month = 12 it is September. This index is created by
use of the MOD function, one of the many mathematical functions found in STELLA.
The equation defining Month is written as:
Month =
IF Mod(time, 12)= 0 then 12
ELSE Mod(time, 12)
18
The variable Monthly_Demand is defined by making it a function of Month (Figure
3.3). The graphical function results from selecting the lower left-hand button on the
Monthly_Demand menu, Become Graph. The data points can be selected by
clicking on the graph itself or by inputting the proper numbers in the Edit Input box. In
this case, the units of Monthly_Demand are in million gallons per day, the most
common unit used to define municipal water demand.
Figure 3.3. Developing Demand
The unit used for the variables Reservoir and Capacity is acre-ft/month. For the
model to have consistency, the Inflow and Release from the Reservoir must also
be in acre-ft/month. Therefore, the variable Monthly_Demand must be multiplied by a
conversion factor to obtain the units of acre-ft/month. The variable MGD\ACFT\Month
accomplishes this (Figure 3.4).
A fourth variable, is Growth_Factor. This variable allows the base Demand to be
multiplied by a growth constant. Finally Demand is defined as a multiplicative function
of Monthly_Demand, MGD\ACFT\Month, and Growth_Factor.
19
Figure 3.4. Defining the Converter MGD\ACT\Month
3.3 Inflows
This example uses thirty years of monthly streamflow data, placed in the variable Data.
This is accomplished as follows:
First, have STELLA and EXCEL both operating, with EXCEL active and STELLA in the
background. Copy thirty years of data (360 data points) from the EXCEL spreadsheet
file. While this data is in memory (on the clipboard), return to the STELLA model and
open the variable Data by double clicking on it. The variable Data is made a function
of time by typing "time" into the equation line, as shown in Figure 3.5.
Next, select the option "Become Graph" and a new window appears (Figure 3.6).
Indicate that there are 361 data points (the first data slot is blank) by typing this into the
Data Points box. Finally, highlight the Output column by clicking once on the
Output. Use the Paste Command to insert the data into the column. The final result
should appear as in Figure 3.7.
20
Figure 3.5. Making Data a Function of Time
Figure 3.6. Preparing Data Converter for Input
21
Figure 3.7. Input of Values to Icon Data
3.4 Draft
There are two releases from the reservoir. The first is a controlled release, defined as
Draft. The second is a release made when the reservoir cannot store all the inflows that
occur during a period, and is defined as Spill. Draft is defined in the model as:
Draft =
IF Reservoir/DT + Inflow >= Demand THEN Demand
ELSE Reservoir/DT + Inflow
This implies that if the volume of water in the reservoir divided by the time step and the
inflow is sufficient to meet the demand, then the demand is released. If it is not, the
reservoir's volume and the inflow are released.
3.5 Spill
Once the variable Draft is calculated, Spill can be determined. Spill is defined in
the model as:
Spill =
IF Reservoir + Inflow * dt - Draft * dt >= Capacity THEN
Reservoir/DT + Inflow - Draft- Capacity/DT
22
ELSE 0
This equation states that if the Reservoir volume plus the Inflow volume during the
period (Inflow * dt) minus the Draft volume during the period (Draft * dt) is
greater than the Capacity, then a Spill is to be calculated. If it is not, the Spill is
set equal to zero.
3.6 Operating Rules
The definitions for Draft and Spill stated above imply a very simple reservoir
operating policy. More complex policies can be developed in STELLA. Such rules
might make the draft a function of time of year, the storage volume as a percent of
capacity, or longer-term streamflow forecasts. One may wish to incorporate hedging
rules based upon the storage level of reservoirs or the total number of days of demand left
in storage.
3.7 Run Time Increment (DT)
The value of DT defines the time step of the model. In the example, monthly streamflow
values are entered as the driving data, and the basic time step is one month. This implies
that when DT is set equal to 1, a monthly time step is being used. However, the value of
DT can be changed to a smaller value if desired. For instance, it may become necessary
to model the system at a weekly time step, and this can be accomplished by simply
changing the value of DT in the "Time Specs" Menu to 0.25. Values in the model are
then updated at a quarterly monthly rate. Details on DT are on pages 24-26 of the
Technical Documentation.
3.8 Maximum Storage
It is often necessary to define the maximum storage in a reservoir as a function of the
time of year. This is accomplished in the same fashion as illustrated with Demand.
However, it is important to note precisely what STELLA does. If capacity is a time
variable, it indicates the maximum value of storage at the end of the period. It therefore
corresponds to the initial storage level at the beginning of the next time period. If the
user wishes the maximum storage value to control the storage level at the beginning of
the period, the values of maximum storage should be shifted by one time period.
4. Advanced Features
Although it is very easy to use the STELLA simulation environment, the development of
complex models requires discipline and experience. For knowledgeable programmers,
STELLA offers a wide range of productivity tools and other advantages over more
conventional programming environments. For novice modelers, STELLA offers the
opportunity to develop simulation models with an ease not previously available. A
23
variety of features in STELLA aid both the experienced programmer and the novice.
Some of these tools are discussed below.
Two examples are used for contrast and are presented in Figure 4.1 and Figure 4.2.
Figure 4.1. Well-Constructed STELLA Model of a Simple Reservoir System
24
Figure 4.2. Poorly Constructed STELLA Model of a Simple Reservoir System
4.1 Tools for Clarity
A major advantage of STELLA is its graphical interface and the ability of a model
developer to clearly define and organize system components. This feature adds greatly to
the clarity of the models that are developed. Six other features of STELLA also aid in
model clarity: 1) Variable Documentation, 2) On-Screen Documentation, 3) Use of
Ghosts, 4) Use of Hierarchies, 5) Use of Sectors, and 6) Use of Color. Each of these
features is documented in the following sections and demonstrated using the models
shown in Figures 5.1 and 5.2.
4.1.1 Variable Documentation
The STELLA programming environment provides the user with a convenient means of
developing documentation for variables. When any variable is opened, one of the options
is "Document." Choosing this option produces a new window (Figure 4.3). In the area
for documentation, the modeler can include all the information deemed necessary to
describe the variable (one example is shown below). This information might include
when the variable was first incorporated into the model, who placed it in the model, the
25
author and time of any changes to the variable, and citations related to the variable.
When a variable has been documented, the "Document" cell in the menu contains an
asterisk.
Figure 4.3. Variable Documentation in STELLA Model
4.1.2 On-Screen Documentation
In addition to variable documentation, it is also often useful to document components of
models using on-screen text blocks. This allows the modeler to highlight portions of the
model or to provide comments to other users. On-screen documentation is added using
the "Text" icon located on the tool bar adjacent to the "Graph" option. When selected,
this icon can be placed anywhere on the STELLA diagram creating a text field. When the
upper border of the icon is "double-clicked," the options available to the modeler are
displayed (Figure 4.4). These include the type of text border and the style, alignment, and
font of the text.
26
Figure 4.4. On-Screen Documentation in STELLA Model
4.1.3 Ghosts
Perhaps the most useful tool in improving the clarity of a STELLA diagram is the use of
Ghosts. As can be seen in poorly constructed model (Figure 4.2), even simple models
can look rather complex. This results from the requirement that all variables influencing
another variable be connected to it. Although this is always required in STELLA, Ghosts
allow the model developer to decrease the level of visual complexity.
As shown in the poorly constructed model, the number of connectors used to relate
Draft, Spill, and Reservoir results in needless visual complexity which can be
confusing to someone attempting to understand the model. This problem can be
minimized by defining Draft and Spill with the use of Ghosts that allow for the
definition of each variable clearly. The well constructed model (Figure 4.1) illustrates the
use of ghosts to minimize visual complexity.
Ghosts of a variable are created by selecting the Ghost tool in the Main Menu and then
clicking onto the variable for which the replicate or Ghost is desired. The process creates
a "copy" of the variable that can be used in every instance as the original variable with
one exception. Connectors can not be drawn "into" a Ghost. This implies that the
original variable can not be re-defined by changing one of its Ghosts. Ghosts of a
variable can be used to define other variables. This capability eliminates the need for
long connectors in STELLA diagrams. The contrast between the models shown above
illustrates this feature. Ghosts for Reservoir, Inflow, Demand, and Draft are
used to simplify the diagram.
4.1.4 Development of Hierarchies
While Ghosts can greatly improve the clarity of the STELLA diagram, another technique,
hierarchies, can be used as well. If a systematic approach is taken to view this problem,
27
the model can be considered to perform three basic functions. First, demand is calculated
as a function of the appropriate variables. Next, Draft and Spill are calculated
similarly and combined into a single term. Finally, the variables Data and Demand and
Spill are used to determine Inflow into the Reservoir, Reservoir_Storage,
and total Release from the system.
Several features should be noted in the development of this hierarchy. In general, the
diagram "flows" from the top to the bottom. In each "level" of this model, a different
activity occurs. First, demand is calculated, then Draft and Spill, and finally the
Reservoir system is modeled. In this process, a number of initial variables are used to
calculate intermediate variables and then , finally, the most important variables. The
variables of most interest, the Inflow, Release, and the Reservoir, are clearly
presented in the final level of the hierarchy without the clutter shown in the poorly
constructed model. Anyone familiar with the notation of STELLA can easily follow the
logic of the model. The activities in the model also flow from left to right. Draft must
be calculated before Spill, thus the cluster of variables defining Draft lie to the left of
the cluster defining Spill.
The suggestions on developing hierarchies described above can greatly improve the
clarity of a STELLA diagram. However, they are merely stylistic suggestions, not rules.
With experience, a modeler using STELLA may develop other hierarchical protocol that
is equally clear. Whatever protocol is developed should be used consistently in the
model.
4.1.5 Sectors
Sectors within STELLA are a natural extension of hierarchies. In the previous section, it
was noted that "clusters" of variables form naturally in defining larger concepts in a
model. In more traditional programming languages such as FORTRAN, these clusters of
variables might be located within a subroutine. When desirable, clusters can be formally
grouped into a collection using the Sector tool in the main menu. To make a Sector,
select the Sector tool and place it on the diagram by clicking the mouse. Use the corners
to expand, contract, and/or move the sector to cover all of the desired variables.
Once a Sector is placed on a diagram, activate its options by double-clicking on its Title
block located at the top of the Sector. When activated, the window presented in Figure
4.5 is displayed. If the modeler selects the "Lock to Structure" option, every variable that
lies within the Sector block is locked to the block. While Sectors can be used for a
variety of purposes, including the importing of pictures or movies, discussion here is
limited to creating groupings of variables.
28
Figure 4.5. Sector in STELLA Model
This process provides two helpful features. First, the variables within the Sector are
moved as a unit with the Sector, which greatly increases modeling efficiency when
working with a large model. Second, Sectors can be run individually. This allows the
"debugging" of a model sector by sector if desired, thus eliminating the need to complete
the entire model before evaluating portions of the model. Details on Sectors are on pages
6-31 to 6-38 of the Technical Documentation.
Note: If a sector relies on the value of a variable defined in another sector, and not all
sectors are running, the results may be inaccurate and unexpected.
4.1.6 Color
To improve model clarity, variable icons can be "painted" one of 256 different colors.
Color can be used to define similar variables (for instance, painting all Inflows the same
color) or to distinguish between different Sectors.
4.2 Sensitivity Analysis
Models are developed to answer questions related to relatively uncertain conditions. This
is especially true in water resources modeling. For instance, the question of how demand
for water will change over time and how it will impact system performance arises often.
STELLA provides the very convenient and powerful option of allowing a modeler or user
to explore how changes in variables impact other variables. The user is able to select a
variable for which a sensitivity analysis is desired, specify the number of runs of the
model, and the range of values the variable is to assume.
29
The Sensitivity Analysis Option resides in the Run Menu and is denoted as Sensi Specs.
Figure 4.6 shows the Sensi Specs window.
Select the variables for the sensitivity analysis from the list in the upper left hand portion
of the window. Only independent variables (those not defined by other variables) are
candidates for sensitivity analysis. Once a variable is selected from this window, it must
be highlighted by clicking on that variable in the "Selected Variable" listing. When this is
done, specify the number of runs and the beginning and ending values. Then select the
Graph or Table option from this window to create sensitivity graphs and tables.
In the simple model that has been developed, one potential sensitivity run would be to
investigate the impact of varying value of Growth_Factor on the Reservoir's storage.
This type of analysis can be used to determine the yield of the system and to select the
most extreme streamflow sequences in the hydrologic record.
Figure 4.6. Sensitivity Specifications in STELLA Model
4.3 Model Completeness
The question of model completeness arises in the development of any simulation model:
"Is the model sufficiently accurate and complete to provide useful information?" The
answer to this question is not always obvious. Sometimes very complex models are not
sufficiently complete to aid in the decision making process, and in other instances very
simple models may prove to be of high value.
Those individuals most likely to be able to answer this question are those who will use
the model. They can determine whether elements of the system under investigation have
been modeled to their satisfaction and whether the model contains the components most
important in capturing the essence of the system being modeled. In the modeling efforts
30
for the Portland Water Bureau, extensive efforts were made to ensure the models would
be useful to units of the Bureau and the various stakeholders interested in water resources
and reservoir management.
4.4 Modeling of System Performance
The water resources models developed in this study were designed to aid in selecting the
best management strategies for the region. This can be accomplished by evaluating
system performance under the status quo and then investigating performance under a
variety of alternatives. Selection of the proper measures of system performance is a
function of who will use the models and how they will be used. Common measures of
system performance can be categorized into four areas: 1) System reliability, 2)
Biological impacts, 3) Economic impacts, and 4) Political impacts.
4.4.1 System Reliability
Three common measures are used to evaluate system reliability. Typically reliability is
simply considered the frequency with which a goal is met. For water supply, reliability
might be defined as the number of months in which demand is met divided by the number
of months of investigation. Two other measures are also important. One is system
resilience, defined here as the average length of time required for the system to return to
an acceptable state of performance. The final measure is vulnerability, defined here as
the maximum deviation of performance measures from target values.
Although these three measures are often used to describe the performance of a system
relative to meeting municipal and industrial water demand, they can also be used to
measure the performance in meeting in-stream flow requirements or other target flows.
4.4.2 Biological Impacts
It is quite feasible to model biological impacts in the STELLA environment. However, it
is difficult to include biological impacts in the models discussed here because biological
impacts of interest in this problem are not well understood; also, no functional
relationships exist between the flow in a river and fish production and the true quality of
fish habitat. Instead of directly modeling biological impacts, surrogates for biological
impacts have been chosen. These surrogates are the flow in the river during the year at
certain points throughout the system. Although it is recognized that flow is only a
surrogate for the biological health of a river and the fish population that inhabit it, this
approach was used due to the limited amount of data available.
4.4.3 Economic Impacts
The shortfall of water creates many impacts. These impacts include lost revenue by
municipalities, the loss of consumer surplus on the part of water purchasers, the negative
impacts of outdoor vegetation, decreased fish production in streams, and a host of others.
However, quantification of these impacts is extremely difficult, due to regional and
31
temporal variations in the impacts. For some items, such as fish production, the
assignment of an economic loss term is complicated due to the loss of many non
quantified impacts, such as those on culture and religion. In the models developed, some
non-monetary impacts will be tracked but no attempt was made to convert them to dollar
values. This does not imply that economic impacts can not be estimated or that this is not
important.
4.4.4 Political and Social Impacts
The environment in which decisions are made relating to water supply is influenced as
often by political concerns as it is by engineering analysis. Because water supply projects
are typically large in scope and impact many people in the community, the acceptance of
the project by the public is extremely important.
The robustness of a water supply system and its ability to deliver low priced, high quality,
and reliable water also reflects well on those whom the public perceive as responsible for
the system. If a water system can not meet water contracts, or if the reliability of the
water supply is called into question, public officials may be the target of extreme
criticism and their positions may be placed in jeopardy.
There is little science or experience in modeling the political and social impacts of water
supply shortages. This does not imply, however, that such impacts are unimportant or
that decisions related to water supply may not be made on this basis. It is not anticipated
that political indices will be developed in the STELLA models for the Bull Run River
basin. Measures such as the number, length, magnitude, and timing of shortfalls could, in
a cursory sense have been made to reflect political impacts.
4.5 Programming Lessons
In the development of the STELLA models for this and other similar projects, a number
of lessons have been learned. Some of these lessons are of a general nature and others
relate specifically to STELLA. Some of these lessons are specified below.
4.5.1 General Lessons
4.5.1.1 Good models start with clear study objectives
When initiating a water resources model using STELLA, there is a great temptation to
begin the modeling process early and devote a great deal of attention to the model.
Perhaps the best advice is to not begin modeling until clear planning objectives have been
established. Although this advice seems obvious, it is surprising how difficult it is to
develop clear and concise planning objectives and then develop a model that addresses
those objectives. All to often the planning objectives play second chair to the model, and
thus the model may prove unable to answer them definitively.
32
4.5.1.2 Good models continue with a definition of what is important in the
system
When good planning models are developed, it is much easier to see what is actually
important in a system. Without planning objectives, one may be forced to model every
detail in a system since they may not know what is and isn't important. With good
planning objectives, components in a model and their impact on the planning objectives
can be estimated and measured. Greater emphasis can be placed on those components of
most importance.
4.5.1.3 Time allocation during modeling effort
A common error in the development of a model is to devote too much time to the
development of a model and too little to the calibration and verification of the model and
the generation of meaningful analysis. This may require that the model is not as complex
as if all the effort was devoted to model development, but the value of the model will be
greatly increased if time is apportioned to these other tasks.
4.5.1.4 Model Clarity
It is very important for those constructing models to remember they are likely the least
important person who will use the model from a decision-making context. The ultimate
users of the model should always be in the forefront of the modeler's consciousness and
every attempt should be made to create a model that they will find clear and easy to use.
The use of Ghosts, Hierarchies, Sectors, and Color are just four of the techniques
mentioned in this report that aid in model clarity.
4.5.1.5 Simplicity vs. Complexity
There appears to be a tendency among modelers toward complexity rather than simplicity.
This is not surprising, given the educational background of most modelers and the
common desire to make a model as complete as possible. Complex models should
always develop from simple models. Components should, in general, be left out of
models unless it is clear that their inclusion improves the ultimate value of the model.
Simple models have the tendency to become complex with little encouragement.
Modelers should always start simple, and make complex only those components wherein
there lies a clear value to do so.
4.5.2 STELLA Lessons
4.5.2.1 Non-negativity requirements
STELLA offers the option of preventing a stock from going negative. This option is a
default option of a newly created stock. Although this concept seems quite reasonable, it
is important in developing water resource models that the non-negativity option never
33
be used. Use of this option modifies the normal calculation of stocks and their outflows
and can create surprising results that are difficult to track.
4.5.2.2 Discrete vs. Continuous data and graphs
STELLA offers the option of representing data as either continuous or discrete. When the
"Become Graph" option is selected, continuous data is shown as connected points and
discrete data as bar lines. When the continuous data option is chosen, STELLA linearly
extrapolates between the points to find their value when a DT of less than one is used.
This feature may or may not be appropriate for a given setting. For instance, if monthly
data is being used in a model and the value of DT is set to 0.25, should continuous (in
which linear extrapolations will be made between points) or discrete (in which the same
flow is assumed to occur during the entire period) be chosen? This must be answered by
a modeler who is aware of the implications.
4.5.2.3 Beginning and ending storages vs. end of period values
When creating tables in STELLA, the modeler has the option to store either the value of a
stock at either the beginning or the end of a period. When developing continuity
equations for system components and "verifying" that a model is working properly, it is
important to know which value (beginning or ending) is being reported.
4.5.2.4 Variable Naming Conventions
As has been emphasized, clarity is an important feature in any large or complex STELLA
diagram. One technique not previously mentioned to aid in model clarity is in the
convention chosen for naming variables. Variable names should be concise, intuitive,
and descriptive. Avoid generic names like Reservoir and Flow. This permits the user
to locate all information pertaining to a specific location without extensive searching.
However, if the place identifier is too long, the type of data will not show in all lists of
variables provided by STELLA.
An alternative (and equally valid) naming convention could place the type of data first,
followed by the place identifier. For instance, rather than naming the building blocks for
release from Dam1 and Dam 2, Dam1Release and Dam2Release, it may prove
effective to name them ReleaseDam1 and ReleaseDam2. In this way, anywhere in
which variables are listed alphabetically, all flow icons would appear together, and could
be located quickly in a table or graph menu. This convention could be applied to all
variable types that are repeated in a model such as flows, reservoirs, releases, spills, and
draft.
4.5.2.5 Limits on Input Data
A flow or converter in STELLA can only contain 1500 values. This does not mean that a
historic streamflow record with more than 1500 values can not be used. One approach to
this problem is to divide the historic data into several flow icons, each containing the
34
maximum number of values. A separate icon, linked to each of these data icons, can then
be used to select the appropriate flows based on the current time period.
4.5.2.6 Impacts on Changing Time Steps
The numerical analysis techniques incorporated into STELLA solve differential equations
approximately. The quality of the approximation is a function of the technique chosen
and the time step. Users should be aware that if large time steps are chosen, results will
be less accurate. There is a trade-off between the speed at which the model runs and the
accuracy of the results.
Changing the time step (the value of DT) defines the accuracy of the results. It is good
practice to run a model at various values of DT to determine if changes in DT results in
significantly large changes in the results to cause concern. It should be remembered, as
noted in the STELLA Technical Documentation that the value of DT should be a value of
(1/2)
n
(that is: .5, .25, .125, .0625, .03125).
4.5.2.7 Printing and Pages
Printing the STELLA diagrams is often necessary. This is accomplished by simply
selecting the Print Option in the File Menu in the main STELLA window. The user can
alter the printout in two ways. Under the File Menu, the user can select the PAGE
SETUP option. This allows the diagram to be printed in either the Portrait or Landscape
mode, with percentage reductions or enlargements. These modifications will not affect
the operations of the STELLA model but will change the manner in which it is paginated.
To preview the pagination of a diagram before printing, the user should select the "Show
Pages" option found in the Diagram Preferences dialogue box under the EDIT Menu.
"Zooming out" (see section 3.5 of this guide) allows the user to see as much of the
diagram on the computer screen as is desired.
5. Dynamic Data Exchange
A new feature in STELLAII called Dynamic Data Exchange (DDE). DDE allows the
STELLAII program to access data stored in another application program. These other
application programs include databases and spreadsheet programs such as Microsoft
EXCEL that support DDE and are a more appropriate in a tool for storing large qualities
of data. This tool is useful when scenarios are run in STELLA which require only a small
portion of the data that exist in a spreadsheet or data base. The DDE can also be used to
export data from a STELLA run into a spreadsheet where more advance statistical
analysis can be performed.
The information outline below comes High Performance Technical Documentation
Supplement for Dynamic Data Exchange (DD), Help Files and Import Sensitivity Setup
and is supplemented with notes.
35
5.1 General Rules
Creating links between Stella and a spreadsheet or database is relatively simple process
although some general rules apply. These apply anytime you establish a DDE link.
Each link will consist of a server, the file that generates the data, and a client, the
file that will receive the data.
Save both the STELLAII file and the file in the other application before creating
a DDE link. The link will use the file names to describe the connection. Any
changes to the names of the files after the link is forged will prevent the re-
establishment of the link when the files are subsequently opened.
Creating links from the STELLAII file to a V file is not possible (all links must
go through another application).
Both the server (data originator) and the client (data recipient) files must be open
for a change in the server to be registered by the client. The update occurs at the
time of a change and not when the files are opened, so make should that both are
open before making any changes, Note that when a change is made to a large
spreadsheet, time may be required to update the calculations. The link will take
place after the calculations in the spreadsheet are complete. If an EXCEL
spreadsheet does not appear to be updating press F9 and then wait for the
calculations to be completed. At this time the link will update.
The number of links will be limited by the amount of RAM you have on your
machine. High performance does not recommend more than 250-300 links. For
large models and spreadsheets at lest 24 MG Ram is needed.
5.2 STELLA II as a client
To create a link that brings data into a STELLAII model the following rules apply:
Graphical functions, converters with no inputs or builtins, flows with no inputs or
builtins, Reservoir initial values, and Queues can act as clients for DDE
interchange. (Graphical functions are limited to 1500 data points and other
equation dialogs are limited to 2000 characters)
TO establish the link, youll need to first copy the data from the other application.
Then open the appropriate dialog in STELLAII. (If you are using a graphical
function, click on the Output column header to highlight the entire column.)
Next, use the key command control-V to paste the data set into STELLAII (the
Edit menu is not available within a dialog). Once you paste, you will get a
secondary dialog in which you can choose to paste either the data or the link.
Choose Paste Link and click OK.
Whenever youre in a dialog that has a DDE link, be sure to exit the dialog with
OK. Exiting via cancel will cause you to cancel (i.e. Break) the DDE link.
If you subsequently open a model which contains links, the software will help you
reestablish links and open the server. Note if the server is not in the correct path
STELLAII will not be able to find the server.
Note whenever opening a STELLA II to which you wish to reestablish
links, you should always open the server (spreadsheet or data base) before
36
opening STELLA II. Failure to do so may cause your system to lock up. If
you are not going to reestablish links you do not need to have the server
open.
5.3 STELLA II as a server
To create a link which exports data from a STELLAII model the following rules apply:
Output data from Tables acts as a server for DDE interchange.
To establish the link, copy the data you are interested in linking by clicking on the
column or row header and choosing Copy under the Edit menu.
Navigate to the other application and choose Paste Special or Paste Link (usually
from the Edit menu).
If you subsequently open a file which contains links to a STELLAII model you
must open the model first.
Note very large DDE transfers from STELLA II to EXCEL have caused
errors in which all of the data is not correctly transferred. An alternative to
using DDE is to save a STELLA II Table as text (.txt) and then opening
and saving that file from within EXCEL.