The time scale regarding when to use system dynamics

["Jay W. Forrester"]

Two recent communications on this email list have suggested that
system dynamics is useful when the time scale of interest in months
or years, but that discrete simulation should be used if the time
scale of interest is in the range of hours or days.

I believe that the time scale of interest is not a guide to the use
of system dynamics.

Indeed, if one is operating the accounting department and shipping
procedures, one needs to work with specific discrete customer orders.
But if one moves back one or two steps to the questions of number of
employees and the nature of the facilities, and is interested in the
validity of the policies being followed in managing the flow of
orders, then one is in the realm of policy design and system dynamics.

To illustrate a short time scale for system dynamics modeling, two
doctoral students in our MIT Computer Science department created a
system dynamics model of what was happening in the electron cloud at
a transistor contact. Afterward they said it was the first time they
really understood what was happening. The time scale was in the
fractional micro-second range.

I have observed a tendency for beginners to believe that they should
deal with discrete items in a system when, for their purposes, they
would do much better to think of the stream of activity rather than
the items within the stream.
--
---------------------------------------------------------
Jay W. Forrester
Professor of Management
Sloan School
Massachusetts Institute of Technology
Room E60-389
Cambridge, MA 02139
From: "Jay W. Forrester" <jforestr@MIT.EDU>

[Jay Forrest]

As a "futurist" who works almost exclusively in longer term models I
strongly agree that systems thinking (in general) and system dynamics
(specifically) can be very valuable in longer term models as suggested by
Jay Forrester

My work supports the concept (as Bill Harris implies) that the feedback
loops needed for an insightful model shift as the time frame of the model
is extended. Significant feedback loops with longer periods should be
recognized and incorporated as the time frame for the model lengthens.
Experience also indicates that short period feedback loops may be
simplified or omitted as time frame is extended (though it should be done
with care).

Slow feedback loops and long time frames introduce serious challenges to
the modeler in the form of recongising and characterising the nature of the
loop. Long time frame models are also inherently more susceptible to
wildcard events and shifting loop dominance related to unrecognized or
newly formed positive feedback loops. These combine to increase uncertainty
and decrease confidence in the precision of the output and behaviour of SD
models. I would join Geoff Coyle in suggesting that greater uncertainty can
increase the value of unquantified systems models relative to quantified
models. The rigor and lessons of rigorous SD thinking and modeling applied
to unquantified models can contribute substantial value to the thinking
unlying the unquantified model. I would also suggest that decreasing the
uncertainty underlying an SD model through stronger model development
methodolgoy should result in stronger SD models.

My experience suggests that applying some of the concepts and methods from
futures studies to the system dynamic model development process can enhance
the value of longer term SD models. I submitted a very crude -- barely more
than an abstract -- paper for presentation at this summers conference in
Atlanta that outlines some of the sources of error that I see creeping into
longer term SD models and provides suggestions for circumventing the
problems. I am continuing to work on this paper and hope it will be
accepted for presentation.

Thanks!
Jay Forrest
From: Jay Forrest <jayforrest@earthlink.net>

[Bill Braun]

In our desire to extend the utility of SD is it possible we are trying to
combine the hammer, the saw and the screwdriver into a single tool? When
the tool is finally designed, will it be so cumbersome that it wont be
used for much of anything?

If analysis and synthesis are different ways of viewing the same thing, are
different tools actually an advantage?

Bill Braun
From: Bill Braun <medprac@hlthsys.com>

["Jim Hines"]

I like Roland Shiefers idea system dynamics is still developing, but Im
afraid I disagree when he writes that different modeling traditions are
"only different flavours of the same thing".

I think of system dynamics as a viewpoint: A viewpoint that all patterns of
behavior are generated by feedback and accumulation structures. I dont
think that the majority of discrete event-, agent based-, econometric- or
what-have-you- modelers would characerize themselves as taking this
viewpoint.

Of course, its possible that some of the tools or software routines used by
discrete event-, agent based- or econometric- folks could be used by a
**system dynamicist** to gain fresh insight into how feedback and
accumulation produce systematic behavior. But, I dont think that a
discrete event, agent-based, or econometric approach per se is a "flavor" of
system dynamics.

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

["Saunders, John"]

Geoff, I didnt get the impression that this discussion was about DT but
rather about what sort of challenges/problems are better modeled (or
modelled if youre British) using SD versus DES.

I agree with Jays Forresters statement "I believe that the time scale of
interest is not a guide to the use
of system dynamics." in some respects. Great models can be created in SD
irrespective of the time scale. One of beter models I have seen was the SD
simulation of a runners blood chemistry during a marathon - typical time
range around 3 hours. It was an excellent use of the methodology and would
have been almost impossible to model using discrete events.

I also had a student who created a model of a packet switching network using
system dynamics. When she proposed the application my intuition told me it
was a reasonable fit. My intuition was wrong. Ultimately the type of
information she sought to derive was dependent upon gathering information
with respect to discrete events and statistical analysis (built into most
DES tools). This wasnt apparent to either of us until after the model was
complete. Given enough time and effort a system dynamics modeling tool could
have produced the results she desired. One can also haul hay in a Rolls
Royce.

I havent been convinced that precluding the use of the "time scale of
interest" as a general attribute is a mistake. Open up any ISDC proceedings
and one will find that the majority of the modeling efforts utilize time
scales in the weeks, months, and years time frames. Why is this true? Open
up any Discrete Event simulation proceedings and you will find the majority
of models utilizing time scales in minutes, hours, and days. Why is this
true?

I liken it to seeing a short (only 6 ft tall )player in the NBA (US
professional basketball league). He is a thrill to watch because he can
manuever so deftly among the giants. But, gosh why are most of the players
so tall? I think it is because they are closer to the goal.

While as a factor the time scale may not be the dominant factor to consider,
I believe it is another piece of information that may aid a decision maker
in selecting a better modeling approach for their challenge.

From: "Saunders, John" <Saunders@ndu.edu>

[Niall Palfreyman]

"Jay W. Forrester" schrieb:

> I believe that the time scale of interest is not a guide to the use
> of system dynamics.

As I understand what Bill is saying, no one time scale itself is
important. What is more important is the _relationship_ between the time
scale of feedback loops compared with the time scale of the simulation.
If Im modelling feedback loops in electron clouds then I have no hope
of extending this model to cover radio-frequency loops in the same
circuit, since the disparity in time scale is too high. On the other
hand, if Im modelling RF loops then the electron clouds are probably
best treated as non-feedback variables.

However this criterion really only relates to the issue of feedback, and
doesnt touch on the question of discrete event handling. This is
opening up a whole can of worms for me that arose recently when I wanted
to model a finite automaton. In that model I constantly came across
things Id like to have in SD which arent currently there (or at least,
not conveniently). The following is a list of the things which have
occured to me:

Discrete events (or message-passing):
As I see it, a discrete event in this context is probably an event which
might occur only once, does not necessarily accumulate, and which
changes the state of its receiver by means of _meaning_ rather than
accumulation. Im thinking of the kind of messages passed in an
object-oriented model, where the signal relies on the receiving object
assigning a meaning to it. In SD models a stock can receive only one
kind of message: a flow of the quantity it accumulates. Might it not
also be possible to send discrete messages between stocks, so that they
become in essence "agents"?

Encapsulation:
It would be nice to bottle a group of stocks into a single object and
then treat that object as a variable (stock? object? agent?) in its own
right. I dont see much support for encapsulation in SD so far. It
could, for example lead to composite stocks which simultaneously
accumulate energy _and_ momentum in physics SD models. In building
dynamical models like the 3-body problem, itd be nice to refer not to
the six variables of position and momentum of a body, but rather to the
body itself, which is then a composite entity.

Symmetries and constraints:
In SD we are forced to model symmetries between variables as causes, but
this is not always the case. Im thinking in particular of the symmetry
between two electrons in the EPR experiment in physics. Here we know
that the spins of the two electrons point in opposite directions, but we
dont know which is pointing up and which is pointing down. There is no
causal connection between the two, but we _do_ know that they are
opposite, so if at some moment we know that one is up, then the other
becomes down. This also applies to modelling movement in an oblique
plane in 3 dimensions: we can choose any two coordinates to have any
value we like, but the third is then fixed by the equation of the plane.
This is not a causal relationship, but a constraint on the system.

Spatial dynamics and PDEs:
Ive twice asked a question on this list about modelling partial
differential equations, and I am still floundering in that area. Andy
Ford and Matthias Ruth have developed some excellent spatial models, but
they are still building with a tool which wasnt really designed for it:
they are forced to model on a grid of about 10x10 spatial divisions.
Compare this with the 1000 or so time steps in a typical simulation. The
techniques which are used in SD to model the (looping) flow of causality
in time _must_ be also applicable to the flow of causality in space. And
just think how wonderful it would be for the teachers among us if we
could visually demonstrate to students not only the time-dependency of
chemical or epidemic diffusion, but also the spatial mechanics. A 10x10
grid does not really do justice to such beautiful spatial effects!

Well, those are my gripes at present. Id be over the moon if someone
now writes in and says: This-or-that SD tool already does these things.
Im keeping my fingers crossed!

All the best,
Niall Palfreyman.
From: Niall Palfreyman <niall.palfreyman@fh-weihenstephan.de>

[schiefer]

Niall Palfreyman wrote:

“...I constantly came across things that I’d like to have in SD which are
not currently there (or at least not conveniently)”

The well-chosen wish list thereafter includes discrete events and message
passing, encapsulation of simulation objects, logical constraints and
spatial dynamics. There where several recent contributions concerned with
modelling time frames and the correct choice of modelling tools. They seem
to reflect two approaches to SD. One sees SD as a given, well-defined method
and the question is: When to use SD as it is, and when to use something
else? The other (like Niall’s) treats SD as a general approach to
understanding systems and suggests extensions to the SD tools to make them
more useful for practical work.

I think the second approach would benefit the modelling community more, as
SD has become a “brand” that is recognised by big consulting companies and
academic institutions. It will be easier to sell ”Extended SD” to managers
and administrators than to propose new methods or to offer a wide array of
confusing options.

Much of the present divisions into seemingly different approaches to
modelling depend only on the point of view. Seen in a different way these
approaches are only different flavours of the same thing. “Extended SD”
might lead to clearer thinking and the corresponding tools would reduce the
time wasted on developing projects-specific modelling tools.

Most of Niall’s suggestions involve a combination of SD tools and
object-oriented programming tools, which both were around in the Sixties
(Dynamo and Simula 67). The fact that since then a lot of people thought
that a combination of them would be very handy did not produce results.
Change has to be implemented by pushing, and this contribution shall gauge
the support for such a push. If the key people in the SD field feel that
“Extended SD” would “muddle” a clean and mature method, then “Extended SD”
is dead. If the reaction is mainly positive, some agreement has to be
reached about the basics of “Extended SD”.

Below are a few suggestions concerning “Extended SD”.

* The modelling interface can be similar to the present SD tools. One
determines a time frame, an integration method, drags modelling objects onto
a plane and links them up. The main differences are: there are more types of
objects, the objects can generate new objects and much of the linking is
done automatically, according to the object properties.

* The most basic objects are levels, flows and constants, with or without
unit checking, so “Basic SD” is a special case of “Extended SD”.

* Objects can also be entities that might change their properties with a
certain probability or that can create new entities. This would allow
modelling of a prey-predator system either by using levels for the number of
foxes and rabbits, or by creating fox and rabbit objects, which multiply or
die with a certain probability. The power lies in the mixing of the
approaches. An insurer might think of policies as sets of rules that are
best described as entities. Converting them into flows might look
“contrived” to him. He might think of cash flow and budget allocations in
flow terms. A mixed approach would allow models closer to the customer’s
perception, increasing credibility and reducing effort and potential errors.

* Imagine an SD simulation of an economy with the resulting energy demand.
If a user can define a “coal power plant object” that updates according to
its load automatically at every time step the “coal requirement counter”,
the “CO2 emission counter”, the “depreciation account” and the “running cost
account”, modelling of whole energy supply chains in their economic
environment and with assessment of their environmental impact would indeed
be easy. If the “coal power plant object” would generate automatically all
“reporting objects” such as the “CO2 emission counter”, and establish the
appropriate links automatically without a link tool, work would even be
easier.

* It will not be possible to provide suitable object prototypes for every
occasion. It should therefore be made easy to add used-defined objects that
can utilise the services available for internal objects (e.g. automatic
creation and maintenance of associated reporting objects). This way the
number of generic object types that have to be supplied in a simulation tool
can be kept small without limiting the power of the tool.

Quite some time ago the mathematician Allan Turing proved that any algorithm
that can be executed at all, can be executed by a simple basic machine, that
was named “Turing Machine” in his honour. Any programming language can
implement a Turing Machine, so “everything can be implemented with anything”
. An argument that all of the above is possible in conventional SD might
therefore miss the point. It has to be determined if the potential increase
in work efficiency, modelling reliability and acceptance of modelling
results by laymen is worth the effort of extending the definition of SD?


Roland Schiefer
Technical Consultant
schiefer@iafrica.com

["geoff coyle"]

Folks,

Ive been away in Australia for a month so Ive missed much of this
correspondence but, as usual, Jay has got it right. The unit in which TIME
is measured has nothing at all to do with whether or not SD is a suitable
modelling method. Ive heard somewhere that someone is modelling geological
processes (anyone know about that?) where the time unit is perhaps a million
years and DT might be 25000 years. In many of my military models, time is
measured in hours.

It seems from my observations that many SD modellers really do not
understand time at all and Ive even heard a consultant say that he had
"arbitrarily set DT (aka TIMESTEP) to 1 week because thats how often
managers make decisions" (quote). He had no idea why this was gibberish!
Ive now produced a lengthy note on the correct use of time in SD models to
get my students on the right lines.

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

[Yaman Barlas]

Important, subtle point. I agree that there is a real danger in "extending" sd
too far. In a 98 Presidents address, I said something like this: One of the
most critical ingredients of a high quality sd study is a "high quality sd
problem." A well chosen problem is of course not sufficient for a good sd
study, but it is certainly necessary. Conversely, a poorly chosen problem will
guarantee a poor sd study. If I take a highly static, open-loop and micro
level issue and "handle" it using sd, my study will be awkward, inadequate and
non-interesting. The solution to this situation is NOT to "extend" sd so that
we can deal with all sorts of problems. This is not the proper direction of
extension. SD must be extended further so that we can deal better with policy
issues of long-term, dynamic and sufficiently closed-loop nature. We still
have A LOT of extension to do in this confined direction. And since the world
offers an endless variety of important dynamic closed-loop problems, there is
no danger of running out of problems! It is just a matter of being careful
about the problem nature. Faced with a static, open-loop, tactical problem, we
have two choices: If we have the luxury, we would say "thanks but no thanks"
and look for a more interesting problem. Else, if we have no luxury, we should
address this problem with some appropriate tool (such as mathematical
programming or discrete simulation).
Yaman Barlas

Bill Braun wrote:
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
-----------------------------------------------------------------------------