Modelling traditions - flavours of the same thing?

["Jim Hines"]

I liked Roland Shiefers approach of translating models into different
formats. And efforts along those lines can help us all to understand how
different ways of modeling either are or arent useful **tools** for
understanding system dynamics. I think that Rolands main point is that
having a single interface for all of these tools would be helpful. I dont
have much of an opinion on that.

But I would like to clarify a couple of Rolands side points. These little
clarifications are the three "hammer/house postulates":

First, a tool for SD (e.g. computer simulation modeling) is **not** the
field of SD. A hammer is used to build a house, but a hammer is not a
house.

Second, to say that discrete event modeling and system dynamics are flavors
of some larger thing, is as useful as saying that hammers and houses are
flavors of the same thing. Well, they are both nouns, but beyond that ... .

Third, just because someone uses computer simulation modeling, does not mean
he or she is pursuing (some superset of) system dynamics. Not everyone who
uses a hammer is building a house.

Regards,
Jim
From: "Jim Hines" <jhines@MIT.EDU>

["Jim Hines"]

Alexander Lubyansky says he disagrees a bit with point 2. And I think he
may be referring to an email of mine where I said, "Second, to say that
discrete event modeling and system dynamics are flavors of some larger
thing, is as useful as saying that hammers and houses are flavors of the
same thing. Well, they are both nouns, but beyond that ... . "

Lubyansky suggests that all sorts of modelling appraoches are trying to
model complex systems and so system dynamics is part of a larger whole.

What I meant was that there are a huge number of things that have something
in common with system dynamics for one reason or another and so system
dynamics is part of a huge number of larger wholes. Discrete event modeling
is a computer-based tool, system dynamics people sometimes use
computer-based tools. Agent based people use the term "complexity" and so
do system dynamics people (though they probably mean different things).
Control theory is concerned with feedback and so is system dynamics.
Economies can be seen as being composed of "sectors"; and some people
consider their system dynamcis models to have "sectors". Many group
processes bring participants to a consensus and so does much good practice
in system dynamics. A good novel, evolves naturally and almost
deterministically from its initial conditions and so do good system dynamics
models. The list is endless.

Regarding Alex. Lubyanskys point that you dont build houses with hammers
only.

Yes. Definitely. A number of tools are widely, almost universally,
accepted by folks on this list to help them understand how feedback and
accumulation produce behavior. These tools include
continuous-time/continuous-function computer simulation, causal loop
diagrams, stock and flow diagrams and reference modes.

I think that most folks on the list are open to the idea that other tools
could also help and a number do use additional tools. Discrete Event
modeling might help (although we havent heard anyone explain yet how it
helps us understand how feedback and accumulation produces behavior), agent
based modeling might help, psychological experiements definitely can help
(and and have helped), statistical tools definitely can help (and have
helped), eigen-analysis definitely can help (and has helped). The Ventana
folks have invented a new tool called reality checks.

So, there are lots of tools. But the tools are not the same thing as system
dynamics.


Regards,
Jim
From: "Jim Hines" <jhines@MIT.EDU>

["Jim Hines"]

Geoff McDonnel asks for pointers to any work combinging CAS(agent-based)
modeling with Stock-and-flow type modeling. Weve taken a couple of baby
steps in this direction to look at the evolution of policies. See
http://web.mit.edu/org-ev/www/.

Regards,
Jim Hines
jhines@mit.edu

-----Original Message-----
From: system-dynamics-approval@world.std.com
[mailto:system-dynamics-approval@world.std.com]On Behalf Of Geoff
McDonnell
Sent: Thursday, March 08, 2001 5:40 PM
To: system-dynamics@world.std.com
Subject: REPLY Modelling traditions - flavours of the same thing?
(SD3119)


I believe that discussion of the relationship between SD (stock and flow)
and CAS Complex Adaptive Systems (object or agent interactions) modelling
would be a fruitful area. I see the SD approach based on the machine
metaphor and CAS approach based on the living system metaphor. It seems very
attractive to reduce complex systems behaviour to a few rules of engagement
rather than representing the complexity as a wiring diagram for a 747. Any
pointers to work in the CAS/SD modelling area would be most helpful.

From: "Geoff McDonnell" <gmcdonne@bigpond.net.au>

[Alexander Lubyansky]

Um, now I may have missed what this Roland Shiefer said, but on your point
2, I disagree a bit.

SD is about understanding how systems work, right? Discrete event modelling
and all sorts of other modelling approaches are also trying to specifically
model complex systems. So, are they not all part of some larger system
science approach (even though it does not exist as an organized discipline)?
You do not build houses with only hammers. Sometimes other tools are good.
There are systems where agent-based modelling is much better than SD
modelling, even though you still are trying to represent and understand the
dynamics of systems. I think that things which you learn from making or
using some SWARM-like model can be directly useful in making a System
Dynamics model and vice versa.

From: Alexander Lubyansky <driedcow@email.com>

["Geoff McDonnell"]

I believe that discussion of the relationship between SD (stock and flow)
and CAS Complex Adaptive Systems (object or agent interactions) modelling
would be a fruitful area. I see the SD approach based on the machine
metaphor and CAS approach based on the living system metaphor. It seems very
attractive to reduce complex systems behaviour to a few rules of engagement
rather than representing the complexity as a wiring diagram for a 747. Any
pointers to work in the CAS/SD modelling area would be most helpful.

From: "Geoff McDonnell" <gmcdonne@bigpond.net.au>

[Yaman Barlas]

Several emails recently on "SD and other tools" made me think on an important
distinction between the following two statements:
1- "SD is a specialized methodology specifically equipped (philosophically and
technically) to deal with certain types of problems and would lose meaning and
value if combined with hammers etc. into a larger comprehensive tool. It is
dangerous to dilute the system dynamics method, the unique tool for a system
dynamicist for doing what she does best"
2- "SD simulation models are sufficient by themselves in order to complete any
given SD study. Therefore, we do not need to make use of any other tools"

I advocate (1) above, but I argue against (2). The two sentences are not the
same. (1) says that we should use linear regression when needed in estimating
the parameters of a model, but this does NOT imply at all that some system
dynamics problems can be solved by linear regression. (2) says that we would
never need linear regression not even in estimating the parameters of a model.
Using again a "construction" analogy, say that we are a civil engineer. (1)
says: "our unique job is to design and construct structures using the civil
engineering methodology. It is thus wrong to claim that if there is some
electrical wiring need, we can/should also handle it, once we have the proper
tools. May be we can, but it is not our unique specialty". (2), on the other
hand says: "a civil engineer has a standard method and does not need to utilize
any other tools from other disciplines, in sub-steps of construction". I
believe that (1) is correct and critical for the field, but (2) is wrong.

Yaman Barlas
From: yaman barlas <ybarlas@boun.edu.tr>
---------------------------------------------------------------------------
Yaman Barlas, Ph.D.
Prof. of Industrial Engineering
Bogazici University,
80815 Bebek, Istanbul
Turkey. Fax. +90-212-265 1800. Tel. 90-212-263 1540; ext.2073
http://www.ie.boun.edu.tr/~barlas
SESDYN Group: http://www.ie.boun.edu.tr/sesdyn
-----------------------------------------------------------------------------

["geoff coyle"]

Yaman has hit the point exactly. To say that all we need is SD tools is
absurd; the object of the whole exercise is to help problem-owners
understand and solve their problems, it is not to do SD. We sometimes go
even further and suggest that SD is the only analytical methodology. It
isnt. There are other approaches, such as linear programming (and a whole
lot of others), which is also very powerful for certain types of problem.
Maybe all SD students should also be required to do at least one course in
basics of operational research.

Regards,

Geoff

Professor R G Coyle,
Consultant in System Dynamics and Strategic Modelling,
Telephone +44 (0) 1793 782817, Fax ... 783188
email geoff.coyle@btinternet.com

[schiefer]

There was some discussion about my statement that SD and discrete simulation
can be seen as two flavours of the same thing. I would like to illustrate my
point with an example.

Assume we want to simulate a simple prey-predator system that can be
described by the differential equations of Lottke and Volterra. These are
given here as difference equations. “t” identifies the time step. We work
with rabbits and foxes.

(fox, t+1) = (fox, t) * (rabbit, t) * (fox birth constant) – (fox, t) * (fox
death constant)
(rabbit, t+1) = (rabbit, t) * (rabbit birth constant) – (rabbit, t) * (fox,
t) * (fox efficiency constant)

We generate two levels (fox) and (rabbit) and define the appropriate flows.
Assuming that

(rabbit, t=0) = 100
(fox, t=0) = 100
(fox birth constant) = 0.002
(fox death constant) = 0.2
(rabbit birth constant) = 0.5
(fox efficiency constant) = 0.006

The resulting model shows an oscillation with a frequency of about 20 years.
A simple, classic SD model. We want to study the effect of diseases and
treatment, so we need more detail. Young rabbits do not have offspring, and
different ages have different fertility, so we split our rabbit level into
ten levels, one for each age group, with the appropriate flows in between.
In each age group we have some rabbits that have myxomatosis (a disease), so
we have to double our number of levels. We do not see our rabbits as pests,
so we treat those we can get hold of. Of the treated some get better, some
not, and that depends on age as well, so we need more levels. During our
trial we find that there is another factor such as food, so we have to
change all our “plumbing” again. Even with arrays that can be quite a
bother, so lets try a discrete model.

We start with 100 fox objects and 100 rabbit objects. At each time step all
foxes still alive report to a counter object that is accessible by all
objects. The rabbits do the same. At each time step each fox object deletes
itself with a probability of 20%, which is equal to (fox death constant). At
each time step each fox object generates a new fox object with a probability
of ((rabbit, t) * fox birth constant)). The rabbit objects behave
correspondingly. The resulting simulation will look quite similar to the SD
simulation, as long as the number of objects in either category does not get
too small.

We can now introduce probability profiles that determine how rabbits at
different ages multiply, how likely they are to contract myxomatosis at
different ages, how likely they are to be exposed to our treatment, etc.
This can all be done without changing any links. The objects move through
the simulation and report to the reporting objects, which are our urw
determinemine theequivalent of SD levels.

If there are many levels, we have to increase the number of objects to get
good accuracy. However, it would be computationally quite clumsy to do the
same thing for all objects of the same state. Instead of changing 1000
“diseased” rabbit objects one by one, with probability of 2% to healthy
rabbit objects, we can split our population of 1000 into 20 healthy ones and
980 still diseased ones in one computation process. To make admin even
easier, we keep only one representative object of each type and attach a
weight to it. If we generate an 18-month-old rabbit with disease, and there
is no such object yet, we create it. If there is one with a weight of 10,
for example, we change this weight to 11.

We do not have to stick to integers for weights. If we use real numbers, we
do not need to increase the number of objects for accuracy, and get now
exactly the same results as in an equivalent SD simulation. Weights
correspond to levels. As the changes in the real weights can be expressed
with differential equations, even numerical methods such as RK4 can be
applied. The remaining difference between the methods is now a more suitable
user interface for data input (for this specific application) and the
convenience that all our plumbing (creating levels, links, flow definitions)
is done automatically.

We can see the different methods now along a “grain” axis as follows:
* Classic SD: levels or real-number weights. Shows effects such as chaos
easily. Randomness is handled via Monte Carlo changes of controlling
constants.
* “Grainy SD”: levels or weights are restricted to integer numbers (whole
objects only). Maybe use numerical methods such as RK4 first, then round
values. Effects such as oscillation or chaotic behaviour might change, which
might in some cases indicate that they were an artefact of classic SD and
would not occur in real life.
* “Very grainy SD” or discrete objects with small weights: the number of
objects in the same state becomes small, so a few more or less might make a
difference to the system behaviour. Classic discrete simulation might here
work as good or better.
* “Classic discrete simulation”: individual objects change according to
rules with defined probabilities. Randomness is handled at the object level.

A simulation of a complex system such as a company or an economy might
require sub-system from several of the above categories. I can also see no
reason why the above differentiation should not be handled on object level,
allowing for different “methods” in a single system.

We can further see models along a “feedback” axis, ranging from powerful
feedback (classic SD) via moderate effects of feedback to negligible
feedback. There is no reason why these models should be handled with
different tools, involving the learning of different user interfaces, the
payment of additional license fees and artificial problems in communicating
with colleagues. Using the same tool for all types of such models will also
lead to smarter results, as it will be easier to introduce feedback in a
model where it was initially ignored.

I would like to add a comment on the philosophy of SD. To understand a
domain, people have to sort the relevant things in their minds. Some people
focus on the rules and properties that make those things different (e.g. a
spider has eight legs, an insect has six, a cow has four). Others feel the
need to look first what these things have in common (e.g. all made of cells,
with a core, protein synthesis controlled by DNA), and then try to describe
them as “different flavours of the same thing”. Both ways are OK. Lawyers
might get more use out of the first way. Engineers might prefer the second.
SD postulates that very different things such as galaxies, cells, biotopes,
economies etc. are all systems that behave according to universal systems
laws and can therefore be described using the universal systems dynamics
method. SD people are saying that all objects in the universe are in some
way “different flavours of the whole thing”. Would it not be very peculiar
if the only thing in the universe exempt from this way of thinking is their
pet modelling tool?

Roland Schiefer
Technical Consultant
schiefer@iafrica.com