Ventana software support forum

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