REPLY Open Source Simulation Software for SD (SD6803)

[SDMAIL Magne Myrtveit]

Posted by  "Magne Myrtveit" <magne at myrtveit.com>

As a developer of commercial modelling software, I am also interested in
what is going on in the open source community. It seems that successful and
widely used open source software emerges only in areas with an already
established base of successful commercial software. In the case of system
dynamics, we have a few commercial players. But the market segment is
currently too small to generate enough sales to create successful software
companies within the field.

OPEN SOURCE - BAD FOR THE FIELD?
What benefit would one have from open-source players in this field? Well,
one effect would be reduced sales for the existing commercial players,
driving their profits further down, reducing their ability to invest in
product development. But that is hardly a benefit to the field... (Open
source is a benefit to the field only to the extent that it contributes to
the innovation that is so badly needed within the field. See below).

ALL THAT MATTERS: BENEFIT > COST
Any software has several costs attached to it, and the lowest is by far the
purchase price. Driving the price down, even to zero, will not solve any of
the major issues relating to system dynamics software. From a modeller's
point of view, the main cost relates to the time and effort needed to learn
how to use the software and how to apply it in concrete engagements for
paying customers.

>From the customer's point of view, the cost is roughly proportional to the
time needed to reach at a result that can be implemented in the
organization. The software cost is usually negligible compared to the
consulting fees (internal or external) charged by the modeller. Especially,
if the model is applied to strategic questions, and the modelling approach
leads to improved strategic decisions, the value of the solution outweighs
the cost of software a hundred times.

SUBJECT-MATTER EXPERTISE - A LIMITING FACTOR
One way to increase the growth of the system dynamics field is to start
taking customers more seriously. Methodology and software are merely tools.
To be useful, the tools must be handled by a "craftsman" or -woman with the
necessary insights how to apply the tools on concrete problems. This means
that SD practitioners need to tailor their competency and their toolbox to
specific needs in specific markets.

SOFTWARE CAPABILITIES - ANOTHER LIMITING FACTOR
Over the last five years I have worked with a team focusing on creating
flexible software that can be customized to specific problems for specific
customers. We are not really creating a new SD tool, but rather a modelling
software that can do SD in addition to other important things. Why did we do
this instead of using one of the existing SD tools?

In my experience, current SD software has too narrow focus. However powerful
the SD technology might be, it cannot even do what "stupid" spreadsheets can
do! See my blogs on spreadsheets and system dynamics if you want to know
more about my views on this:

http://www.dynaplan.com/blog.php?page=thread&tid=574

INNOVATION IS NEEDED
It would not help much if the various SD tools could talk to each other.
Unless we are open to innovation and new ideas, the field will stagnate. If
the ideas come from an open source initiative, fine! What we do not need, is
yet another "standard" SD software.

MODEL READERS
I agree with Jean-Jacques Laublé when he in a recent posting stresses the
importance of being able to (re-)run models that are posted as part of
academic papers. If each software vendor provides a free model reader, it is
quite easy for others to run models published by others. Do all vendors
provide free readers? If so, how do we get access to them? And how do we
deal with different versions of the same software? (Software upgrades are
often, but not always, 100% backward compatible).

CONVERTING MODELS
As Jean-Jacques and other have mentioned, there is also a possibility of
converting a model into a format that is accepted by the software you are
the most familiar with. For models using only basic system dynamics building
blocks (stocks, flows, and auxiliary variables) the conversion is straight
forward. More advance features, such as array variables, measurement units,
lookup functions, hierarchical models, data import/export, and so on require
more work to be transformed between platforms. The same goes for the
visualization of the model (stock-and-flow diagrams for example) and the
model’s behaviour (charts, tables, etc.) Some of this can be done
automatically, but I am afraid that sometimes models must be reformulated by
humans in order to run correctly on another software platform.

TEXTUAL MODEL INPUT/OUTPUT
Vensim already has a textual format that captures the model and its
visualization.

Powersim has an equations view holding all equations of a model. (I have
converted Powersim models by printing the equations to PDF, converting the
PDF to text, and parsing the result. It works, but it is obviously not
straight forward. And it does not include the visualization of the model). I
am not sure if Powersim can read models back from a textual format.

For Stella/iThink I don’t have any information regarding textual input and
output of models.

Dynaplan’s new product, Smia, can import and export models as text. A nice
feature with Smia is that the exported text is formatted to be easy for
humans to read, and it is customizable through the use of cascading style
sheets (CSS).

OPEN SOURCE?
A potential open source project could be to define and implement translators
between the various model formats. The code could be offered to the vendors,
who would get the opportunity to import models written in any of the other
popular SD packages. The biggest benefit would be to the users, while
keeping the cost of implementation relatively low for the vendors.

A WORD OF CAUTION
It is my experience that sometimes it is better to build a model again from
scratch than it is to try to convert it one variable at the time. There are
two main reasons for this:

1) The manual conversion process is a learning process (albeit an expensive
one).

2) The capabilities of the source and the target modelling languages may be
so different that a different model design is called for in order to create
an elegant and maintainable translation of the model at hand. (As an
example, Vensim aggregates using arrays; Powersim Studio using arrays and
submodels; Dynaplan Smia using arrays, submodels, and re-usable components).

Best regards,
Magne Myrtveit
Dynaplan As
Posted by  "Magne Myrtveit" <magne at myrtveit.com>
posting date  Sun, 9 Mar 2008 16:04:37 +0100