QUERY Open Source Simulation Software for SD

[Stefano Armenia - Ateneo <ste]

Posted by Stefano Armenia - Ateneo <stefano.armenia@uniroma2.it>

Dear all,

it's quite a long time since i'm looking out for some software for
System Dynamics Modelling which may be Open Source in a strict sens of
the word. I do not know if anyone has ever had the chance to cover this
issue or at least if this is an issue to the community. Actually, in my
work, I also deal with open Source software, especially connected to
Public Administration, and so I'm quite into the issue of open
standards, open formats and open source software. I know this issue
might be not so popular among the SD software producers, but I think
that, referring also the discussion on the quality of models which was
going on on this mailing list, the free availability of software for
research reasons might be an issue, especially for institutions which
cannot allow themselves even the low cost of an academic version (and i
can ensure you that it happens in many countries - italy first) or for
young researchers who do research on their own or who are not connected
or affiliated to some research institutions. I believe that the
unavailability of a free software for SD might also be a reason for the
scarce submission of models or for the submission of poorly documented
models to the ISDC. How many times we have found ourselves complaining
about having a demo version of a certain software or for the fact of
being unable to import a different software model file in our licensed
modelling software environment? In this sense, the availability at least
of open formats for models (XML may help in this, and also the
experience of opening file formats, like the Microsoft Office one may be
of some interest also for the various existing simulation software)
could be in my opinion a first step for an ""opening"" of the SD
simulation techniques towards other simulation communities, thus also
allowing to disseminate the SD methodology itself.

Regards, Stefano Armenia
Stefano Armenia, Eng, MBA, PhD
@ ""Tor Vergata"" University of Rome, Italy
Posted by Stefano Armenia - Ateneo <stefano.armenia@uniroma2.it>
posting date Tue, 4 Mar 2008 19:26:29 +0100
_______________________________________________

[""Berchi Roberto"" <r.berchi@]

Posted by ""Berchi Roberto"" <r.berchi@tiscali.it>

I completely agree with the arguments that Stefano wrote in his message.
The question is simple : what can we do ?
One of the solutions could be to look at open source environment that
can host easily a SD package (I am thinking of NetLogo for example)
it would minimize the cost for developing good software, good
presentation environment at low development cost.

Roberto Berchi
Posted by ""Berchi Roberto"" <r.berchi@tiscali.it>
posting date Tue, 4 Mar 2008 20:20:33 +0100
_______________________________________________

[Bill Harris <bill_harris@faci]

Posted by Bill Harris <bill_harris@facilitatedsystems.com>

Stefano,

I think I've mentioned it here before, but, in case I haven't, I've been
using MCSim, a GPL'd simulator, for I think about (actually, almost
exactly) 3 years now. It comes from the PBPK (physiologically-based
pharmacokinetic) world, so it may look a bit different, but it does the
same thing. You can find some information at
http://facilitatedsystems.com/links.html#sd; you can also find MCSim on
Savannah.

It doesn't solve all the problems you mention. For example, few would
probably call its files universal exchange formats (Anastassios
Perdicoulis was once driving an XML effort; I don't know its current
status), but they are in easy-to-read text. MCSim doesn't sort
equations into the proper order, but I've found that less of a problem
than I imagined. It doesn't really have any discrete functions,
although you can program pretty much whatever you can figure out how to
program.

Is it a good solution? I think so. I find it helps me think better
about problems, for reasons I documented in a talk I gave on it in 2006,
and I have the impression that it helps me go faster overall. While we
know Euler integration is usually good enough, at least if you set DT or
TIME STEP appropriately, I find it nice not to have to worry about that
anymore except in quite rare instances (then again, I like driving cars
with manual transmission -- go figure).

Perhaps the biggest benefit is that it separates the processes of
problem definition, problem modeling, design of experiments, analysis,
and communication more than the other tools I've used. I find that
helps me, for I find that those phases require different types of
thinking, and I find benefit in being able to concentrate on one or the
other at a time.

http://www.facilitatedsystems.com/weblo ... n-way.html
explains further the ""Aha!"" that made me think more seriously about
MCSim. I think I did a factorial experiment with my very first MCSim
model without even thinking about it, and then I sat back in amazement:
why hadn't I been doing that all along in cases where it was
appropriate?

You can see a simple example of a model done with MCSim at
http://www.adaptistration.com/adaptistr ... -co-5.html.

Is it for everybody? Probably not. When I use MCSim, I create the
models (which look a bit like C code) in my favorite text editor (Emacs,
if it matters), I compile them using gcc, and I analyze the output using
J or perhaps gnuplot. I typically use Dia to create accompanying
diagrams (after starting with that other CAD [carbon-assisted drawing]
tool: the mechanical pencil and paper). Others could, of course, use
different tools, but J offers a few benefits that have really helped,
and the MCSim manual is integrated with Emacs.

Tabular nonlinearities seem particularly arcane to the newcomer (as if J
doesn't , as you can see in the reference card I've posted at that
first link. Once you've done a few, they're not so bad, and they offer
more flexibility than I think I've found in commercial tools, at the
expense of having to learn some of the GSL (GNU Scientific Library).

Does it replace the commercial alternatives? Unlikely. I still use
others from time to time (I'm teaching a graduate course in which we're
using Vensim, and I'm enjoying that immensely). If you like GUIs, you
won't like MCSim (unless you also like writing GUIs, but I find working
in text helpful). If you like creating animated learning environments,
you won't like MCSim. If you like integrated environments, you won't
like MCSim. There are lots of reasons to stick with Vensim, ithink,
Powersim, or the like.

You can find a bit more by searching for MCSim on my blog
(http://www.facilitatedsystems.com/weblog/). I've been toying with
offering a course in the use of MCSim for system dynamics, but I'm not
sure if there would be enough interest. I am open to feedback on that
question.

> > Is it for everybody? Probably not.

Stefano,

One other GPL fact of life to mention: sharing MCSim models comes with
certain constraints. While I can send you the model itself (the text
files) under any restrictions (or lack of restrictions) I wish, I can't
do the same with the compiled executable. That executable is linked
with GPL'd components (MCSim itself plus GSL and perhaps other bits),
and so my executable models automatically fall under the GPL. That's
not a bad thing: I don't /have/ to distribute the executable, and the
claims of the GPL only apply to distributed code.

If I were to distribute (i.e., send you) a compiled model executable,
then I would have to make available all the associated GPL'd source,
which includes at a minimum MCSim and GSL source. That's a big enough
task so that I'd likely tell you how to install MCSim on your system
instead. It should work on anything with gcc and GSL, so Windows, OS X,
Linux, and perhaps many others should do just fine -- it's the typical
configure, make, make install process.


One final thought, if you don't want something as full-featured as
MCSim: about 4 years ago, Pegasus published my ""System Dynamics on a
Shoestring,"" which walks through the process to use Paul Fishwick's
SimPack, another GPL'd simulator, for SD work. If you put SimPack
together with a C compiler (cygwin provides gcc on Windows, and gcc is
likely automatically a part of OS X and your favorite Linux distro) and
your favorite graphing program (Gnuplot is good, easy, free, and cross
platform), you have another complete solution that's pretty easy to use.

SimPack handles both Euler and RK integration. The source to the entire
simulator fits on one piece of paper, as I recall, which is a reminder
how simple the fundamental technology is that underlies our art
(admittedly the major commercial offerings provide a /lot/ more in the
way of features). You'll still have to sort your equations and code
your own table functions, but that's not too hard, and table functions
don't look as complex in SimPack's C as they do in MCSim, even though it
is -- or can be -- really the same thing.

You can find the link at
<http://www.thesystemsthinker.com/nldata ... ItemID=590>.

Does anyone else here use MCSim or SimPack? (I confess that I probably
haven't used SimPack since shortly after writing the article.) Does
anyone have any other GPL'd or FLOSS alternatives?

Bill
- --
Bill Harris
Posted by Bill Harris <bill_harris@facilitatedsystems.com>
posting date Wed, 05 Mar 2008 08:42:42 -0800
_______________________________________________

[Richard Stevenson <rstevenson]

Posted by Richard Stevenson <rstevenson@valculus.com>

Stefano Armenia wrote:
> I believe that the
> unavailability of a free software for SD might also be a reason for the
> scarce submission of models or for the submission of poorly documented
> models to the ISDC.

I could not disagree more.

First, ""free software"" is a myth, as most users of poorly constructed
and badly documented open source software will attest. There is no
substitute for well constructed, robust and well supported SD software
that can be fully audited. How much time do users of ""free"" open source
software waste on problem shooting and web-surfing to find advice? Is
time ""free""?

Second, it is my experience that most SD software suppliers have bent
over backwards to accommodate academic researchers and students with
licensing deals and low prices. It is also my experience that there is
almost no trick that some (by no means all) academics and students won't
get up to to pirate software.

Third, any proposition that a lack of free software is a reason for ""the
submission of poorly documented models"" is just absurd. All the major
SD software packages have excellent internal documentation facilities -
and there are many other software products available for documentation.

Fourth, I suggest that the key reason for ""scarce submission"" of models
to the ISDS is the paucity of interesting SD casework coming out of
academia - and that it is not in the leastl due to lack of software. The
""scarce submission"" issue is also due to the fact that businesses and
consultancies (who can easily afford the software) are discouraged from
submitting interesting casework, not least by ISDS academic strictures.

I believe it is partly the management of ISDS itself that is responsible
for lack of submissions - and for the low growth of the SD field itself.
My reasoning has been aired here in the past but can be summarised as:

* the ISDS is a tiny, inward-looking, academically-focussed body that
effectively discourages discussion about its own purpose and conduct.
The ISDS has effectively become a cabal.

* in my own field of SD business application, there has been no great
leap forward since ""Industrial Dynamics"" 50 years ago. The surge of
business interest generated by ""The Fifth Discipline"" in the 1990's has
completely dissipated - and not inappropriately so!

Jay Forrester's views his in ""next 50 years"" paper are highly pertinent.
In particular, he cites two great challenges - better education of
system dynamics ""experts"", and using SD as an organising philosophy for
a new kind of management education. Those needs are indeed the keys to
the future of SD.

So let's put away ideas that SD is constrained by the cost of software -
it is not.


Richard Stevenson
Valculus Ltd
Posted by Richard Stevenson <rstevenson@valculus.com>
posting date Thu, 6 Mar 2008 17:39:00 +0000
_______________________________________________

[Stefano Armenia - Ateneo <ste]

Posted by Stefano Armenia - Ateneo <stefano.armenia@uniroma2.it>

Dear Bill,

and dear all reading,

thank you very much for your very interesting information. Actually I
did not know about the tools you mentioned. I find that that are surely
worth playing a little bit with them, but all the same the main problem
remains, which in one word is: INTEROPERABILITY.

I mean, I can also use the tools you mentioned, which of course are not
so user-friendly as Stella or Vensim or Powersim may be but surely they
have that Open Source taste which is for those Open Source geeks like me
or you. But what if, as it probably already happens, it's just you or me
who use them tools?

I find that the real issue is the one of Open Formats, which should then
be an available format option also in all proprietary modelling suites.
Of course, if there was a strong OS Development Community behind the
tools you mention, this would probably in the long run lead to some OS
suite which could find compatibility with the proprietary model formats
as well as try to propose their own model format. But think of what
happened for example in the OS communities as long as Productivity
Suites are concerned. I'm thinking of experiences like the one of Open
Office: they started their struggle against Microsoft Office first by
allowing only their own format, which was of course open (.odt) but it
was just them to use it. Then they opened themselves to compatibility to
MSOffice document types, which was a process that lead in the long run
Microsoft itself to open their document formats just recently.

Of course the modelling communities are not so wide as the big public of
people who just have the need to write a couple of pages in a
wordprocessor, use electronic sheets for calculus, and so on, but the
OpenOffice experience could probably teach someone that the ""Open
Revolution"" could also affect the modelling market, sooner or later. The
problem is that i do not see the issue of opening the formats as a
threat, rather as an opportunity.

I probably have my own vision, but if the modelling suites were really
interoperable on their file formats, probably the competition among the
modelling software producers would then be on quality of service (i.e.
functionalities offered to end-users), which is what it should really be
in the end, i think. My vision is that one day I may be able to use
either Vensim, or Powersim or Stella and be able to indifferently open
one of their model formats in a ""cross-platform"" way... Or be able to
open on proprietary modelling sw an ""open source"" model...

I know it's a delicate question, because I'm aware that the SD modelling
sw houses are making their business by trying to attract customers to
their platform... but ours is still a quite small community if compared
to other scientific communities... and how many of us is really
changing the modelling software he is always been keen on? Of course I
know that SD software is quite similar from Suite to Suite, since the
common base is the SD methodology, but still many of us prefer using
this rather than that peculiar suite.

So, at last, my questions are:

1. to the SD modelling sw companies (like Vensim, Powersim, Stella,
Consideo, Anylogic, ecc...): is it sustainable to change your business
model in order to open your file format and agree on a sort of Open or
shared standard?
2. looking more into the future: would it be possible to do it also with
regards to other kind of modelling sw (not necessarily SD related)? I'm
thinking about Anylogic, Extend, Arena, etc...
3. last but not least: is anyone aware of the existence of any community
where the development of a user friendly modelling suite for SD (but not
only) is carried over? If not, I think this might be a very interesting
issue to be carried on, maybe also with respect to the chance to receive
adequate funding for an ""open"" project (I'm saying it with reference to
EU funding programs)...

Wait for feedback from everyone!

Regards,

Stefano Armenia
Posted by Stefano Armenia - Ateneo <stefano.armenia@uniroma2.it>
posting date Fri, 7 Mar 2008 00:18:55 +0100
_______________________________________________

[""richard dudley"" <richard.d]

Posted by ""richard dudley"" <richard.dudley@attglobal.net>

I think that Bill's answer clearly indicates why ""free"" software has not yet
caught on in a larger community. He mentions about five different software
packages that he uses to produce a final product -- and most of these
require some more detailed level of knowledge about computer _programming_
then many of us have.

One of the things I find exceptionally good about the standard system
dynamics software packages is that _modeling_ is separated from
_programming_. I think this is very important for most of us, not only
because we don't want to do programming, but because modeling and
programming are so very different. A good system dynamics modeler can do
the best work when freed from programming. For me, at least, I am free to
think about model structure rather than computer code. I am sure we have
all seen system dynamics models with long strings of embedded if then else
statements. I always imagine this is an indicator that a programmer,
rather than a modeler, created this model.

Stefano really brings up two issues. One having to do with freely available
software, and the other having to do with inter-operability or open access
code so that models from one software can be used with another. There has
been a some effort toward this latter idea in the past.

In reality, at least based on my limited experience, system dynamics seems
to be more inter-operable in a general sense then other modeling paradigms.
To me this is a great strength that has not been widely 'advertised': - the
stock flow modeling paradigm is fairly standard across software and applies
to any problem being modeled, not just to a specific field. I can see and
understand a Powersim, or Stella, or Vensim model much more easily than I
could a program written in C or Fortran, for example.

During the review of models, either academic or otherwise, this
standardization can be a huge benefit IF the software makers ensure that, at
a minimum, they provide fully functional versions which allow one to read,
view the details of, do what if analysis of, and make temporary alterations
to, a model under review.

Would I like a fully functional, free, user friendly system dynamics
software? Of course! But I have also come to appreciate the amount of work
and talent that has gone into the design of the existing packages.
Presumably these people need to be paid for doing this.

Richard
Posted by ""richard dudley"" <richard.dudley@attglobal.net>
posting date Sat, 8 Mar 2008 09:19:21 +0700
_______________________________________________

[Jean-Jacques Laublé <jean-jac]

Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr>

Hi every body

I agree with both Richard's when they say that software companies must have
a return from their effort and that nothing is gratuitous.
The minimum that should be accessible is the code of the application and a
sufficient documentation.
A software reader should be interesting too for some people.

Personally if I am really interested by a model, I will translate it into
Vensim that I master relatively well. Translating a model from one language
to another is the best way to understand it. But to do that one must have access to the
code and preferably to a documentation inside or outside the model.

For instance I could not read any model written in Powersim from the papers
of the last SD conference.
It should always be possible for any papers from the SD conference to
rebuilt the model in one's preferred software of course it the paper subject
is about a model.

That should be the first thing to verify when accepting a paper.
Otherwise what is the interest of publishing a paper if one is not even able
to run the model or eventually modify it?
Regards.
Jean-Jacques Laublé Allocar Eurli
Strasbourg France
Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr>
posting date Sat, 8 Mar 2008 15:23:22 +0100
_______________________________________________

[""Malczynski, Leonard A"" <la]

Posted by ""Malczynski, Leonard A"" <lamalcz@sandia.gov>

Greetings,

Everyone should be aware of Jim Hines' 'SMILE' effort to develop a
common model format.
There is a description of an XMILE format proposed by Vedat Diker and
others.
Karim Chichakly also has published on this.
(see the sds-isig group at
http://tech.groups.yahoo.com/group/sds_isig/ if you are interested)

I submitted a paper in Nijmegen, using what I learned from Kim Warren,
about why SMILE or XMILE will not be realized. Basically, software firms
are competing for our business as Richard Dudley mentioned.

Maintaing the basic stock and flow paradigm is a must for them to be
methodologically consistent. If we take a look beyond that, the programs
are quite different. Each has implemented modeling features that cannot
be easily translated, e.g. conveyors in Stella; some might even require
'programming', e.g. allocate functions in Vensim and Studio; and very
different IDEs (Interactive Development Environments). If there is a
common, easily translated format, low switching costs may put one or
more of these firms out of business. I have been very interested in the
SD tool market and have seen some convergence or 'follow the leader'
behavior by the firms in terms of feature additions.

The competitive strategy of a firm may be producing niche products for
the broad system dynamics community.

When I say broad, the scope ranges from academic exercises to very large
models with too much historical data (ususally prompted by clients who
are still not convinced of the power of the methodology) to flight
simulators that are very interface intensive and error trapping to
models that incorporate other paradigms e.g. operations research.

The firms have to make a decision. They have limited resources with
which to construct their SD software. They must allocate those resources
to stay in business. Should they allocate to developing a common format
or add new features to their tool?

Pedagocially, a simple open source product would be useful. Although as
Richard Stevenson stated, the vendors provide free or low cost crippled
versions of their products, sufficient for learning SD principles
(perhaps these students would then use these tools t work once gainfully
imployed?). A 'free' open source tool would not satisfy some of the
other users I mentioned above. Their motivations might not be pure SD
but they have found client niches that benefit from the SD methodology
and applications that have become what I call 'extra methodological'.

Jean-Jaques point about models from the conference papers has been
bothering me too. I admit to having presented work based on one product
that cannot be duplicated at all or without much difficulty in other
products. At the risk of being lambasted, relatively simple models
could be presented in all 3 major formats if the authors have access and
facility with all 3 products. Again, another barrier.

Regards,
Len Malczynski
Posted by ""Malczynski, Leonard A"" <lamalcz@sandia.gov>
posting date Sun, 9 Mar 2008 10:36:15 -0600
_______________________________________________

[""Magne Myrtveit"" <magne@myr]

Posted by ""Magne Myrtveit"" <magne@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@myrtveit.com>
posting date Sun, 9 Mar 2008 16:04:37 +0100
_______________________________________________

[Bill Braun <bbraun@hlthsys.co]

Posted by Bill Braun <bbraun@hlthsys.com>

Jean-Jacques Laublé wrote that he could not read Powersim models and
laments not having access to the equations.

Perhaps a small rules change for paper submissions could help. If I am
coming up against the page limit of the paper and still have stunningly
brilliant things to say, I'm reluctant to use space for equations. If
the model file (of whatever ilk) can be accompanied by a companion
document that includes the equations and a pdf document that shows the
model structure, anyone ought to be able to reconstruct the model in the
package of their choice. Neither of the two would require work from
reviewers or conference staff.

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Sun, 09 Mar 2008 10:00:50 -0400
_______________________________________________

[Stefano Armenia - Ateneo <ste]

Posted by Stefano Armenia - Ateneo <stefano.armenia@uniroma2.it>


Dear Richard, and dear all,

I will answer to the different issues raised in your email by points.


Richard Stevenson wrote:
> First, ""free software"" is a myth, as most users of poorly constructed
> and badly documented open source software will attest. There is no

I could not disagree ""even"" more... As many success OS products are
there attest, this affirmation is clearly not true, or at least not
truer than my ""hypothesis"" (I was just hypothesizing). I just recall
that the success of an Open Source software most of the times is highly
dependant on the width of its underlying community, which also mean well
supported, well constructed, etc... software. Just have a look at the
MySQL, Apache, or PHP communities just to give a hint on successful Open
Source Software.

> Second, it is my experience that most SD software suppliers have bent
> over backwards to accommodate academic researchers and students with
> licensing deals and low prices.

I am afraid this has been just a ""bad"" experience, just refer as an
example to previous cited tools, but many many more may be found by a
simple search on the web.

> It is also my experience that there is
> almost no trick that some (by no means all) academics and students won't
> get up to to pirate software.

I agree on this, but the problem is: do we really have a common
understanding as well as a clear ""systemic"" view of why this is happening?

> Third, any proposition that a lack of free software is a reason for ""the
> submission of poorly documented models"" is just absurd.

Mine was just an hypothesis among the various ones, trying to find
another reason for the ""poor submission"" issue.
Probably it's not clearly related but it woudl be at my advice worth
investigating, rather than find an early solution like saying that an
hypothesis is absurd. An hypothesis must be tested first.

> Jay Forrester's views his in ""next 50 years"" paper are highly pertinent.
> In particular, he cites two great challenges - better education of
> system dynamics ""experts"", and using SD as an organising philosophy for
> a new kind of management education. Those needs are indeed the keys to
> the future of SD.

I surely agree on Jay's view for the next 50 years, but I leave the
discussion on what has just been said to other researchers surely more
qualified than me in answering this.

> So let's put away ideas that SD is constrained by the cost of software -
> it is not.

I didn't say that, the basic idea contained in my mail was another one,

I'm somehow of the idea that if at least a sort of an interchange format
(XML is just an example) for model-files would be out there (which would
not be hard to do since the common paradigm is the SD theory itself), it
could be easier to share models and to provide users with a common
framework which in the long run (according to my vision) would lead to a
wider use of SD models if compared to other modelling and simulation
communities, with probably some good effects also in the way we submit
models.


Stefano Armenia
Posted by Stefano Armenia - Ateneo <stefano.armenia@uniroma2.it>
posting date Tue, 11 Mar 2008 01:25:08 +0100
_______________________________________________

[Bill Braun <bbraun@hlthsys.co]

Posted by Bill Braun <bbraun@hlthsys.com>

Len Malczynski opines that SMILE and XMILE formats will not be realized
owing to software firms competing for our business.

Assuming that markets are as rationale as our economist friends say, if
the market asks for a common document format, the software publishers
will deliver. Additionally, I would argue that once a common format is
established we would have even better software to choose from, since all
the time formerly spent on file formats would now be spent on features
and workability.

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Mon, 10 Mar 2008 07:56:54 -0400
_______________________________________________

[""Malczynski, Leonard A"" <la]

Posted by ""Malczynski, Leonard A"" <lamalcz@sandia.gov>

In response to my friend Bill Braun:

I agree the users want it. The market however, is composed of buyers and
sellers. The sellers, in a simple economist's world, probably want the
least cost production method that will produce a product that their
potential customers will purchase. Most firms also know that product
differentiation may lead to greater profit. In fact since all consumers
are different, they all have different desires (indifference maps, if
you will, and of course disposable incomes).

In order to produce this common format each vendor would have to export
to it and import from it. Since each vendor's implementation of the SD
methodology and extra-methodology is different there will be many
features that can be exported but not imported. Might his encourage a
homogeneity of tools? If so, what's the point of multiple vendors?
Better development environments? Interface tools?

We also need to consider the exact meaning of words, e.g. model. My work
involves building applications, an SD model with an interface, a flight
simulator if you will. A common language format will make translation
easier but nowhere near complete. In my paper I proposed that at some
level, model translation is not the problem, model availability might
be. Perhaps at the Albuquerque conference we can host a tutorial on
model conversion.

Regards and thanks for all the insights,

Len

P.S. A roundtable to discuss these issues has been proposed at the
Athens conference. The SDS iSig will hopefully host it.
Posted by ""Malczynski, Leonard A"" <lamalcz@sandia.gov>
posting date Tue, 11 Mar 2008 13:15:59 -0600
_______________________________________________

[""Owen Ambur"" <Owen.Ambur@ve]

Posted by ""Owen Ambur"" <Owen.Ambur@verizon.net>

>From my perspective, whether SD software is open source or proprietary is
much ado about nothing. However, I am strongly supportive of Stefano's
suggestion:

> >I'm somehow of the idea that if at least a sort of an interchange format
> >(XML is just an example) for model-files would be out there (which would
> >not be hard to do since the common paradigm is the SD theory itself), it
> >could be easier to share models and to provide users with a common
> >framework which in the long run (according to my vision) would lead to a
> >wider use of SD models if compared to other modelling and simulation
> >communities, with probably some good effects also in the way we submit
> >models.

BTW, I'm struck by how many words the average poster to this list seems to
feel are required to make a point. No doubt, that is because SD theorists
know so much more than most of us about how reality actually works (at least
in their own minds). However, it does cause me to wonder about the
effectiveness of their efforts to *influence* reality (as opposed to merely
""modeling"" and theorizing about it).

Owen Ambur
Co-Chair Emeritus, xmlCoP
Posted by ""Owen Ambur"" <Owen.Ambur@verizon.net>
posting date Tue, 11 Mar 2008 15:17:10 -0400
_______________________________________________

[""Magne Myrtveit"" <magne@myr]

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

Several people have in this thread advocated the benefits of a common model
format, maybe based on XML.

Let us assume that someone starts creating a standard model format. What
would be considered as ""standard"" semantics of models?

The different ""standard"" SD modelling languages do not just have different
*syntax* and some differences in the built-in functions they provide. If
this was the case, both standardization and conversion/translation would be
straight forward (and done long time ago).

However, the modelling languages have big *semantic* differences. This means
that a translation is not possible without conversion. And for some features
it is not even possible to make a conversion at all, unless the software
vendors add features not yet supported on a given platform. [It is easy to
create a long list of critical features that fall into this category]

I think we all agree that at the level of ""basic stock-and-flow modelling""
the various modelling languages are semantically quite similar, and a
translation is easy to do. But most non-trivial models make use of
""enhanced"" features of the various modelling tools.

How do you plan / envision solving this problem?

Best regards,

Magne Myrtveit
Dynaplan As
Posted by ""Magne Myrtveit"" <magne@myrtveit.com>
posting date Tue, 11 Mar 2008 14:43:44 +0100
_______________________________________________

[""Magne Myrtveit"" <magne@myr]

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


Bobby Powers writes:
> How about the following as a start? Different languages that
> additional information to accompany the equations
> of variables can add additional elements to <var>. Also since type is
> just a string, you can include additional
> variable types without changing the save file specification. Also,
> newer versions of the specification can be
> implemented and versioned by changing the markup attribute.

Dear Booby,

Thanks for your response.

To create an XML specification that can store the structure of a model
is not be too hard. The example you enclosed in your posting shows how
this can be achieved.

In order for one software to load a file created by another software,
the *semandics* of each equation must be understood and converted. (The
conversion is sometimes trivial, and sometimes virtually impossible).

As part of my reasearch (my wife keeps asking me when I will finish my
PhD:-) I have devloped two meta languages for storing models. One uses
XML, which is good for automatic storage, exchange, and translation of
models. The other is a plain text format, which is easy to read for
humans. (Typical use: Model equations appendix of book or paper).

I created the formats for two reasons:
1) To learn about the different modelling langauges.
2) To have a format that I could use for my own product (Smia).

The proposed formats have the advantage that they already have all (?)
the features needed to store complete models stored by the most recent
version of:

o) Powersim Studio
o) Vensim
o) Microsoft Excel (yes, that's right)
o) Dynaplan Smia

Stella/iThink should be quite easy to add to the list, if someone has a
way to output their models as text.

If someone is interested in looking at the formats for a third use
(conversion), I'd be glad to share them with you.

Best regards,
Magne Myrtveit
Posted by ""Magne Myrtveit"" <magne@myrtveit.com>
posting date Wed, 12 Mar 2008 13:11:59 +0100
_______________________________________________

[""Owen Ambur"" <Owen.Ambur@ve]

Posted by ""Owen Ambur"" <Owen.Ambur@verizon.net>

A reasonable approach would be to seek consensus on a core set of elements
that comprise the common schema, including not only the names and
definitions of the elements but also the relationships among them -- in an
XML schema (XSD).

If the subscribers to this list could do that, they would be adding real
value to a cause in which it is evident they strongly believe.

Beyond the SD core schema, ""extensible"" is XML's first name and additional
elements can easily be added to accommodate more specialized purposes.
Although the semantic differences among extensions would inevitably arise,
simply having those elements in a standard format (XML) would go a long way
toward facilitating understanding of such differences.

Perhaps this group could also play on ongoing a role in fostering
incorporation of such extensions into the standard XSD, if consensus can be
achieved on their meaning and merits.

Owen Ambur
Co-Chair Emeritus, xmlCoP
Posted by ""Owen Ambur"" <Owen.Ambur@verizon.net>
posting date Wed, 12 Mar 2008 12:24:39 -0400
_______________________________________________

[""Bobby Powers"" <bobbypowers]

Posted by ""Bobby Powers"" <bobbypowers@gmail.com>



Posted by ""Magne Myrtveit"" <magne@myrtveit.com

However, the modelling languages have big *semantic* differences. This means
that a translation is not possible without conversion. And for some features
it is not even possible to make a conversion at all, unless the software
vendors add features not yet supported on a given platform. [It is easy to
create a long list of critical features that fall into this category]

How do you plan / envision solving this problem?


How about the following as a start? Different languages that additional
information to accompany the equations of variables can add additional
elements to <var>. Also since type is just a string, you can include
additional variable types without changing the save file specification.
Also, newer versions of the specification can be implemented and
versioned by changing the markup attribute.

yours,
Bobby Powers
Posted by ""Bobby Powers"" <bobbypowers@gmail.com>
posting date Wed, 12 Mar 2008 12:31:46 +0100
_______________________________________________

[Bill Braun <bbraun@hlthsys.co]

Posted by Bill Braun <bbraun@hlthsys.com>

Len Malczynski, among many good points, says that as features vary
across software vendors there would be mismatches between imports and
exports, and wonders if such a move [to standard file format] might
result in homogeneity of tools? Magne Myrtveit makes a similar point
when he notes that ""...most non-trivial models make use of 'enhanced'
features of the various modeling tools"" and ends by asking, ""How do you
plan / envision solving this problem?""

First to Magne's question: I don't know how to solve the problem; I lack
the technical skill. It occurs to me to ask, if any of the vendors in
the market now wanted to add a feature another vendor has, would there
be any reason they could not do so using their file format currently in
use?

If the answer is no (all features are possible in all current file
formats), then pick one - that's the common file format. If the answer
is yes, then I speculate that each vendor is approaching or at their
limits to growth, and may have to address the problem of an inadequate
file format anyhow. Likewise, pick one, go from there.

To Len's question on homogeneity of tools, I am more cautious. I
appreciate his point and its implications for innovation.

If there is a common file format, the vendor who wishes to add a feature
would propose the file format enhancement. Vendors would be free to
pursue their market strategy and would choose to make use of the feature
or not. I suspect that is no different from what they do now with
different file formats. Having now used Powersim, Vensim, and iThink,
they are quite different tools, each with their array of rich, unique
features and annoyances.

I'm at the end of my knowledge rope (close to hanging myself, I expect).
Can we hear from the experts, Bob and Karim?

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Wed, 12 Mar 2008 18:24:29 -0400
_______________________________________________

[Tom Fiddaman <tom@ventanasyst]

Posted by Tom Fiddaman <tom@ventanasystems.com>

I'm not convinced that competition is the obstacle to SMILE/XMILE
implementation. That presumes that SD software providers have a strong
incentive to restrict access to a valuable network or installed base of
models, or that they behave like the telecom industry (get people stuck
on your product, then confuse and overcharge them). I don't think
there's a strong case for either.

Vensim, for example, has effectively had an open model file format (the
text .mdl) for a long time. The syntax is a little obscure, but 90% of a
translation can be accomplished with just search & replace in a few
minutes, especially with a simple model. There are automated tools
(crude but effective) for Stella and DYNAMO equation translation into
Vensim. Models are easy to translate; the diagram has traditionally been
the sticking point, but that should be easy given today's tools. Ten
years ago I succeeded in writing code to translate a Stella diagram from
an exported PICT image.

The fact that these tools are hardly used suggests to me that there's
little demand for translating models. I'm not really surprised by that.
The core capabilities of SD software packages aren't very different, so
there isn't ordinarily a compelling reason for the shift. What would be
much more interesting is translation across modeling paradigms, for
example from a spreadsheet to SD or from a mathematical programming
language like GAMS to SD. However, there are significant obstacles to that.

In the first case, the problem is that spreadsheets are unstructured, so
there isn't an equation set to translate. Manual replication of a
spreadsheet is horribly painful (as I can attest, having just done one).
Expose ( http://attunegroup.com/Expose/Expose.htm ) mitigates the
problem, but has not taken the world by storm, though perhaps it should.
I'm not sure the pain of translation is the reason for the lack of
appetite for spreadsheet translation. More likely, it is due to the fact
that the majority of spreadsheets are dynamically trivial and thus
rather boring to translate.

In the second case, translation is hampered by the fact that SD
languages may simply not be expressive enough to capture the content of
the original. There's no sensible way, for example, to solve an integer
program with continuous tools. I have translated a few equilibrium
models into Vensim using the FIND ZERO function, but the result is
usually less functional than the original (though perhaps more useful
because it can be connected to other dynamics). In most cases, what is
needed is not translation, but a structured way to exploit and compare
results from both paradigms.

Returning to the open source SD question, I'm all for new tools and
interoperability, but I'm not sure that those are what we need most.
What I see as a greater need is open models. Those might come in two
flavors:
- model components, like the Molecules (
http://www.vensim.com/molecule.html ), but extended and improved
collaboratively
- general purpose topical models, including Jay Forrester's ""20 models""
There are precedents for open models, including MARKAL and LEAP (both
energy models with significant community backing). The payoff would be
to get some modeling productivity enhancements that would make it easier
to compete with established paradigms like general equilibrium. The
trouble with such efforts is that there's a tendency toward bigger,
rather than better models, so mechanisms need to be in place to
encourage quality and transparency.

If we need new tools and interoperability to get those models done and
make them usable, then great. Certainly it would help if SD software
choice were not an obstacle to participation. However, I think the real
constraint is quality control (per the minimum acceptable model standard
conversation). Ensuring that models and components are worth sharing
requires some combination of standards, social measures (ranking), and
automated quality checks.* Tom Malone et al. at MIT are currently
thinking about this challenge in a slightly different context.

Tom

*
Reality Check
http://www3.interscience.wiley.com/cgi- ... 9/ABSTRACT
Validation
http://www3.interscience.wiley.com/cgi- ... 0/ABSTRACT

Posted by Tom Fiddaman <tom@ventanasystems.com>
posting date Wed, 12 Mar 2008 17:00:47 -0600
_______________________________________________

[""Mauricio Múnera"" <mauricio]

Posted by ""Mauricio Múnera"" <mauricio.munera@gmail.com>
X-Antispam: NO; Spamcatcher 4.1.11. Score 2

Hi.

I am Mauricio Munera and I am just a first year master student in SD
Dynamics at Bergen University in Norway.

My Background is in computer science and I got into this mail list
because my professor Earling Moxnes sent to me a thread of discussions
concerning to open source modeling tools and open modeling standard for
SD models.

I found this discussion as a miracle because many of the ideas that were
going into my mind were exposed for some people here what means that
I'm not feeling alone in this matter anymore.

I planing to start my master thesis focusing in the creation of a Basic
OpenSource Modeling tool based on Object Oriented Programming and as
part of my thesis a Modeling Standard language must be created. One of
the main reasons is to step forward in this direction is because the
System Dynamics community may keep going with her evolution in
comparison with what have happened with Computer Science. Some of you
probably remember that time in which in a company people for one
department were non communicated with another department because some of
them were using IBM technology and they were using Microsoft technology
only because the standards this kind of situation have been solved
(probably not 100% but in a high proportion ).

This is a complex task, and probably too much for a master thesis an
probably I'll get a low score because I will get crazy by the dead line
to handout it, but if I can start giving the first steps with those who
has the same ideas I'll be so proud of being able to contribute with
something.

It would be great if people with some background in programing and
software modeling that are interest in the conception of the standard
join forces in this matter.

Greetings.

Mauro.
Posted by ""Mauricio Múnera"" <mauricio.munera@gmail.com>
posting date Thu, 13 Mar 2008 13:35:20 +0100
_______________________________________________

[""Ames, Arlo"" <alames@sandia]

Posted by ""Ames, Arlo"" <alames@sandia.gov>

Maybe it's time for me to weigh in on this.

Before getting involved with dynamics, I worked in the CAD arena. There,
you have a strong need for data interchange (sending data from design
organizations to manufacturing organizations), and some nagging pitfalls
(the geometry you're interchanging is a result of a large set of nonlinear
computations that people don't do in consistent ways in different platforms).

Standards for data interchange have been worked on almost since the inception
of CAD itself. IGES, PDES, and STEP are acronyms you can look up if you're
interested. Generally, the standards development process is long, arduous,
and expensive. The committees working on these things take forever to
converge on a solution. Vendors have a vested interest and want the standard
to look like their system, and non-vendors often have difficulty in knowing
the subtleties well enough to steer the solution in a direction that doesn't
degrade the data as it's transferred.

Once a standard exists, vendors play a very cagey game implementing it.
Implementation and maintenance cost money (money that customers aren't aware
of and are reluctant to shell out), so vendors often write minimal
implementations. Implementation of the export portion of the specification
risks losing customers, as they can now migrate to competing products more
easily than by re-creating their models. Implementation of the import portion
of the specification can make it easier to steal customers from other vendors
by the same logic.

Vendors thrive on adding specific features that other vendors lack -- such
features distinguish their products from the pack, and are often the only
basis for competition. Adding vendor-specific constructs to the
specification drives toward translation is difficult. Vendors don't *want*
to tell everybody the data structures for their new whiz-bang features, so
they don't want to add them to the spec. If you add general capabilities to
add features without adding the specification (e.g. general attributes),
vendors will use them in all kinds of creative ways to make loopback tests to
work (so they can show that their translators are successful), while
obfuscating the translation for any vendor.

When you implement inter-system translation, you are creating a new ecosystem,
with predator and prey behaviors.

All of this isn't to say that translation isn't a good idea. It's a great
idea. I have spent a lot of my career encouraging vendors to do just such
things, and to export their data *in any form* so that we can get hold of it,
because information is power, and even if you have to work hard to deal with
it, it still is an enabler. It's just complicated.

Note too, that once you start participating in this stuff, you're part of the
ecosystem.

Arlo Ames
alames@sandia.gov
Posted by ""Ames, Arlo"" <alames@sandia.gov>
posting date Thu, 13 Mar 2008 14:58:20 -0600
_______________________________________________

[Bill Harris <bill_harris@faci]

Posted by Bill Harris <bill_harris@facilitatedsystems.com>

""SDMAIL Tom Fiddaman"" <tom@ventanasystems.com> writes:
> In the first case, the problem is that spreadsheets are unstructured, so
> there isn't an equation set to translate. Manual replication of a
> spreadsheet is horribly painful (as I can attest, having just done one).

Tom,

Thanks for the link to Expose; I didn't know of it. I try never to use
spreadsheets because of the problems they can cause (see
http://www.facilitatedsystems.com/weblo ... heets.html
and its links). What I find I like is J (http://jsoftware.com/; see
http://www.facilitatedsystems.com/weblo ... gures.html for
background).

Yes, I guess it's programming. No, it's (probably) not like any
programming you've ever done before. In fact, those who have never
programmed may have an easier time with J than those who have programmed
much.

Bill
- --
Bill Harris
Posted by Bill Harris <bill_harris@facilitatedsystems.com>
posting date Thu, 13 Mar 2008 07:47:14 -0700
_______________________________________________