Making Connections

Karim Chichakly Modeling Tips

I generally do not use modules to build very small models (only a couple of stocks and flows), which may then lead me to use sectors as the model grows because they are very convenient.  By the time I have three sectors, though, it starts to become clear that I should have used modules.  I will then need to convert my sector-based model into a module-based model.  Historically, I also have a number of sector-based models that are crying to be module-based.

Converting from sectors to modules is not very difficult:

1. Make sure there are no connections or flows between sectors.  Replace any of these with ghosts in the target sector.
2. In a new model, create one module for every sector.
3. Copy and paste the structure from each sector into its corresponding module.
4. Connect the modules:  At this point, the model structure has been rearranged into modules, but none of the modules are connected.  The ghosts that were in the sectors became real entities when they were pasted into the modules.  Go back to identify all of these connections and reconnect them in the module-based model.

Stepping Through a Sample Model

Let’s walk through an example.  A small sector-based model is shown below (and is available by clicking here).

This model violates what I would call good sector etiquette:  there are connectors that run between the sectors.  This is often useful in a small model such as this because it makes the feedback loops visible.  However, in a larger model, this can lead to problems such as crossed connections and difficulty in maintaining the model because sectors cannot be easily moved.

Read more…

iThink/STELLA, modules, sectors, Version 9.1.2

Karim Chichakly Modeling Tips

This is an update to post published on August 31, 2009.  The attached model was updated to find negative means and an alternate method was included at the end.

I am frequently asked which built-in function gives either the running mean or running standard deviation of a model variable.  Unfortunately, there is no such built-in at this time (no, that is not what MEAN() does).

Luckily, however, we can replicate the behavior we desire from built-in functions by creating a reusable module.  I can create a module that calculates a running average and a running standard deviation from any model variable.

When building a reusable module component, it is important to carefully define what the input to the module will be (i.e., what are the parameters to the built-in function) and what the output of the module will be (i.e., what is the result or return value of the built-in function).  In this particular case, the input will be the variable whose running average or running standard deviation we wish to find.  There are two outputs:  the running average and the running standard deviation.  Note we do not have to use both outputs all the time.

Thus, our new module can be used as shown below:

Note the name of the module was chosen to give a meaningful context to the running mean and standard deviation variables, which have fixed names defined inside the reusable module.  As in this example, it is always a good idea to give the module outputs general names that make sense when qualified by a context (the module name).

The reusable module itself was built and tested in iThink, and can also be used in STELLA.  The input parameter was given an equation to allow the model to be completely tested and debugged before being reused.  The model appears below and can be downloaded by clicking here.

Note the input to the module is named value.  After importing the module, this will need to be assigned to the variable in question, Cash in the above example.  This can be done from outside the module by right-clicking on Cash and choosing “Module->Assign to”, or right-clicking on value and choosing “Module->Assign Input to”.  The outputs can be assigned in a similar way, or the Ghost tool can be used.

This method, while relatively easy to understand, does accurately compute the standard deviation when the mean of the running sum of squares is close in magnitude to the running mean squared.  An alternate method that does not suffer this problem was developed by Welford in 1962 and is implemented in the model that can be downloaded by clicking here.

Finally, I am including a simple reusable module that finds the maximum value of a model variable across the entire run of a simulation.  It can be downloaded by clicking here.  It uses a stock to hold the maximum value seen so far, and takes advantage of the fact that uniflows cannot be negative.  It is used the same way as the running mean and standard deviation module, but only has one output called maximum.

For more information about modules, consult the iThink and STELLA help files.  These on-line resources are also available:

Using Modules Webinar

Module FAQs

builtins, iThink/STELLA, modules, Version 9.1.2

Joanne Egner STELLA & iThink

My first introduction to the Systems Archetypes was years ago when I read Peter Senge’s book, The Fifth Discipline.  I remember relating these classic Systems Thinking stories to my own experience in business and thinking how useful it was to understand some of the problems we faced and why solutions didn’t always work out as intended.

What I’ve come to appreciate since then is how the characteristic themes of the Systems Archetypes transform across all sorts of different fields and situations — even our personal lives!

Take, for example, the basic story line of the “Success to the Successful” archetype:

When given the choice, we invest our resources where we expect them to deliver the best results.  By giving more resources to one option over another, we create a self-fulfilling prophesy whereby the favored option is perpetually more successful.

The story of the Success to the Successful archetype applies to all sorts of  situations leading to well-known patterns of behavior:

• rich getting richer and poor getting poorer
• winners being rewarded with the means to win again
• popular brands attracting more popularity
• one species driving another to extinction
• top salespeople being paid higher commissions

Exploring the Model Structure

We recently published a model of the Success to the Successful archetype to the web using isee NetSim. Exploring the model is a great way to understand the underlying structure of the system and think about ways to avoid the problems it creates.

You’ll also get an appreciation of how the decision policy for allocating resources can determine success rather than competence.

Running the Simulation

After you’ve explored the model, try running a simulation.  The base case scenario assumes no one has an advantage over the other.  As you can imagine, everyone is equally successful and it’s a win-win situation.  Try turning on the “Advantage A Switch”  to see how even a modest advantage for A can snowball into a disadvantage for B.  It’s surprising how quickly the gap can widen.

Using Modules to Create Models

In STELLA and iThink version 9.1, we added the ability to build models by linking together modules.  The Success to the Successful model is an example of how you can use modules to create a higher level map of your model.  This map can easily be presented as a causal loop diagram.

The beauty of modules is they simplify the process of transitioning from a CLD to a model that actually simulates.  If you’ve ever tried to convert a causal loop diagram into a stock and flow model, you can appreciate what I’m talking about!  By architecting your model into modules, you’ve got a built-in mechanism for developing your model in manageable chunks and communicating the high level causal relationships.

archetypes, Causal Loop, CLD, modules

Jeremy Merritt Modeling Tips

The version 9.1 release of iThink & STELLA introduced a new approach to modeling complex systems: hierarchical modules.  Modeling with modules can really simplify the way you think about, construct and communicate systems.

Since a lot of customers are now getting their feet wet with modules, we’ve been receiving a steady stream of questions.  We asked our Director of Product Development Karim Chichakly to compile a list of frequently asked questions that he thought would be useful for anyone using modules.  The questions and answers are listed below. If you have any additional questions, post them in the comments and we’ll respond.

What is a module?

A module is a container for lower-level model structure.  It is designed to support a process of top-down model design and development.

What is a module input?

A module input is a variable that can become the ghost of another variable at a different level of the module hierarchy.   It becomes the ghost when you assign it to that other variable.  After it is assigned, it is referred to both as a cross-level ghost and an assigned module input.  All of this is managed transparently if you use the ghost tool.

What is a module output?

When a variable is designated as a module output, you are telling the software that this variable can be ghosted on a different level of the module hierarchy.  While any variable can be a module output, it is important to carefully manage which variables you intend to be shared across modules.

How are modules different from Decision Process Diamonds (DPDs)?

DPDs were designed to collapse one level of structure and hide non-essential details while modules were designed for top-down development of complex models.  Their goals are very different and so is their behavior.  While it is true that modules can be used to replace DPDs, the reverse is not true.

Read more…

Decision Process Diamonds, iThink/STELLA, modules

Karim Chichakly Stories from the Field

I recently had the pleasure of building a very large model of the health care system from many small discrete parts.  I did this in a course on Health Care Dynamics taught by James Thompson at Worcester Polytechnic Institute.  The design of the model is entirely Jim’s.

The most striking thing about this model to me is that it was created completely hierarchically.  I have seen many large models broken into sectors which are conceptually all at the same level.  I have seen other large models that are organized by feedback loops, which can at some times be large and unwieldy.  But I had yet to see an example that is truly hierarchical, with an appropriate dynamic hypothesis at each level.

The model is three-levels deep.  At the lowest level are models with very simple dynamic hypotheses.  At the next level up, groups of these smaller models are tied together to form more complex feedback loops, or loop sets, comprising a higher-level dynamic hypothesis (this is the complexity most of the models I develop have).  At the top-level, they are tied together to form a very high-level dynamic hypothesis.  One of the very nice things about this is that each part of the model, which was built bottom-up, has already been tested in isolation or within its group before the whole model is tied together.  All parts are in steady-state.  In this way, we have built confidence in all of the parts of the model and now are only testing the broadest feedbacks.

Critics of this approach insist that delaying the connection of the broadest feedbacks until this late in the development of the model hides important dynamics that affect all parts.  Not only is this considered risky, but the model does not generate results until the end.  After this experience, I can’t agree with this point-of-view.  There was very little risk in tying the pieces together at the end because they were well-formed pieces already rich in feedback, and (very important!) initialized in steady-state.  While the model did not address some of the overarching issues until the end, careful testing of the pieces of the model added insight at many steps along the way and even gave hints about what might happen when those final feedbacks were put into place.

Read more…

feedback-loops, healthcare, hierarchy, modules, workflow

Nat Pierson Training

One of our recent webinars, What’s New in STELLA and iThink Version 9.1, highlights some of the new features added in last summer’s v9.1 release.  Karim Chichakly, Director of Product Development, guides you though the model building steps to create a supply and demand model that investigates the current housing crisis.

Among other topics, Karim covers how to organize your model with modules, draw causal loop diagrams and import data from multiple spread sheets.  Preview the 40 minute presentation with this 1.5 minute video clip.

>> Download the sample model files used in the presentation.

>> View complete webinar presentation.

CLD, housing, iThink/STELLA, modules, mortgage, video, webinar