Simulation Model Interchange Language

["Malczynski, Leonard A"]

The DOE National Laboratories may be interested in developing a Simulation
Model Interchange Language Entity (SMILE).
There are internal research funds available on a competitive basis to tackle
problems such as these.
We, at Sandia National Laboratories, are increasingly using SD to look at a
variety of issues. Satisfying multiple customers
with multiple software and hardware platforms and multiple vendor licensing
requirements makes a SMILE very attractive
(no pun intended).

I am interested in helping to draft a research proposal.

Regards,
Len Malczynski
Office of the Chief Economist
Sandia National Laboratories
lamalcz@sandia.gov
V: 505-844-7219
F: 505-844-3296

["Thompson, Jim A-136"]

I may run into this problem less frequently than others. When I do, it is
annoying. But the differences between graphical interfaces, proprietary
built-in functions, and how each handles subscript matrices probably makes
SMILE complicated and difficult.

As Carolus indicates, three publishers offer some form of no charge or
inexpensive model reader/limited functionality package:
Vensim Model Reader: http://www.vensim.com
eader.html (no charge)
STELLA/ithink Model Reader: http://www.hps-inc.com
eader.htm (no charge)
Powersim Studio Express: http://www.powersim.com/technology/express.asp (60
day limit, limited functionality)
Vensim Personal Learning Edition: http://www.vensim.com/venple.html (free
for academics; $50 commercial; fully working, limited features)

My experiences with Vensims Model Reader and Personal Learning Edition
indicate that these are easy downloads with clean install/uninstall. They
are back compatible with models built with earlier versions of the software.
STELLA/ithink is a bit more ornery to download and wont run models built
with all earlier versions of the software, e.g., version 1.02 wont run in
version 7.x without significant conversion work. Ive never used Powersim.

This doesnt address the issue, however. I wonder what incentive we
consumers can offer the publishers that would make them SMILE?
Jim Thompson
Economic & Operations Research
CIGNA HealthCare
900 Cottage Grove Road A142
Hartford, CT 06152
Phone: 860.226.8607
Fax: 860.226.4447
email: jim.thompson@cigna.com

["Jim Hines"]

There would be many benefits to a simulation model interchange language
(smile). Just to list some, starting with the one that Carolus names:

A SMILE would ...

1. Make it easier for colleagues (or potential colleagues) to exchange
views best expressed as models (where the exchange would preserve both
equations and diagrams).

2. Make more valuable a model repository. (An idea currrently being
pursued by the system dynamics society and already offered by a number
of companies and individuals on their own websites)

3. Increase total sales of SD software by increasing the value of each
vendors product. All vendors of SD software are small; a company
investing hundreds of thousands or millions of dollars in model
development will be more eager to do it in iThink, Vensim, Powersim
(pick any one) if theyre confident that in effect all three vendors
stand behind the model-investment, not just one.

4. Create a flowering of new SD approaches/techniques/tools by making
it possible for non-commercial folks to articulate a single innovative
idea in software without having to also create stuff theyre not
interested in (which could include graphical model editor, text editor,
model simulator, plotting capability, simulation engine (Euler, Runge
Kutta, etc), etc.) Instead the amateur "fiddler" could concentrate on
just the new feature that he or she is interested in, leaving everything
else to the bullet-proof commercial vendors. A vendor could adopt any
idea that actually seems valuable to it. In effect, the R&D efforts of
each of the commercial vendors would be multiplied many times.


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

["Michael McDevitt"]

In the summer of 2002 I began developing an XML schema for business models.
The final schema will be delivered to my customer this month. The schema
includes SD models as well as discrete event simulation (DES) models. It
was developed to support a business model repository. The schema is
currently undergoing testing at the University of Central Florida Institute
for Simulation Technology (IST).

An XML schema may provide a "universal" structure for describing SD models
that would enable parsing into and out of the software application of
choice and make us all SMILE. Of course some one would have to write the
parsers. I must acknowledge the work of Ferdinando Villa at the
University of Vermont on "Integrated Modeling Architecture."

Please contact me if you are interested in the schema.

All the Best,

Mike McDevitt
mmcdevitt@caci.com
858-695-8220 x1457

["Ray on EV1"]

Yes, as Jim Hines points out, this is extremely valuable. It would be
appropriate to set up a list server to address this issue so as not to clog
the normal SD channel.

There are many examples of specification development and recommended
practices development on the web. It would be appropriate to have a site
with a third party to host such a process. Leonard, any idea who might
sponsor such an effort?

Raymond T. Joseph, PE
rtjoseph@ev1.net

["Jim Hines"]

(1) Jim Thompsons most important question is whether the users can
offer any kind of incentive to vendors for incorporating the ability to
export and import SMILE files. Nothing very good comes to my mind,
which is why its such a dandy of a question. Just to illustrate how
nothing very good is coming to mind: Ive thought of maybe having all
of us agree to pay a "tax" to the vendors for a few years so that they
could build SMILE compatibility into their products. Or maybe we could
all pledge to upgrade. What else?

(2) Jim Thompson also mentions that simply creating the SMILE language
will be a challenge. No question: Creating a SMILE isnt something you
do casually one evening at the pub. It would take years of evenings at
the Pub, (or probably a month or two of work outside of a pub). This is
why it would be good to find some funding, particularly if we decide not
to do the work at a pub.

Fortunately, the biggest headache -- incorporating full-blown
discrete-event or agent-based approaches into the language -- could
easily be postponed if we wanted. Were lucky that the major system
dynamics vendors all derive their languages from the same source
(ultimately DYNAMO), and so their languages are VERY similar in basic
capability and also in notation -- both text-based and graphics-based.
I dont mean to trivialize the differences, but the difference are far
less than the commonalities.

I also dont want to trivialize the challenges, because the
propeller-heads on this list wont want to do it if its too easy.

(For my non-native-English speaking friend (and for my friends who have
the misfortune to have learned English in England) ... "Propeller-head"
means "gear-head" or (at least on the East Coast of the US) "nerd". I
refers to someone who is very, very smart and very, very interested in
technical things -- like computer programming, or ... well... like
system dynamics modeling.

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

[George Richardson]

On Sunday, March 2, 2003, at 03:49 PM, Jim Hines wrote:

> (1) Jim Thompsons most important question is whether the users can
> offer any kind of incentive to vendors for incorporating the ability to
> export and import SMILE files. Nothing very good comes to my mind,
> which is why its such a dandy of a question.

Its worth recalling that this issue was brought up very publicly in a
plenary session at the Tokyo conference, and two of the three main
software houses said theyd be happy to create an interchange
capability in their products.

The idea was to specify an interchange language which each software
platform could import and could create. Eberlein and Myrtveit said
they could do it and would be happy to do it. HPS was represented by
someone other than Barry (Im sorry I cant remember her name) who said
shed check out the idea with the HPS staff.

As I recall, HPS was not particularly interested in adding the
translating capability to STELLA and iThink, and no one got to work on
the task of specifying what the common interchange language would look
like, so the project -- endorsed wholeheartedly by the assembled
multitude in Tokyo -- disappeared.

It could be that someone other than the software houses could specify
the essentials of the interchange language and ship that off to HPS,
Ventana, and Powersim for their adjustments and action. [Without
knowing what Im talking about, I can say that it looks promising to me
to have the text format of Vensim models be the common interchange
language, since translating into and out of text sounds to me like the
easiest thing to do, but as I say, Im over my head here.]

...GPR
From: George Richardson <gpr@albany.edu>

*George P. Richardson
*Rockefeller College of Public Affairs and Policy
*University at Albany - SUNY, Albany, NY 12222
*gpr@albany.edu *518-442-3859 *http://www.albany.edu/~gpr

["Will Glass-Husain"]

Colleagues,

Ive been following the model interchange discussion with interest as I recently spearheaded the development of a Forio model import capability. This allows the Forio web system to import a text file into the Forio modeling language exported by any of the major desktop software packages. As part of this development, Ive learned a lot about the compatibilities and differences between our language, Vensim, iThink, and Powersim.

Weve found that there is a common core of mathematical, logical, and dynamic functions that are very similar between the packages. At Forio we have been able to in apply simple transformative rules to convert text equations and a large pool of functions from these various packages into a common language.

We had to make some assumptions about the details of computation. All packages support the basic Eulers method, but there are subtle and not-so-subtle distinctions. A few examples: iThink has options to restrict the accumulation of levels (a check box for non-negative stocks and a switch for "uniflow" vs "biflow"). Powersim Studio has a built in unit conversion that will automatically convert a variable in one measurement (e.g. days) to a different measurement (e.g. years) as necessary. Vensim allows TIMESTEP and FINAL TIME to be equations that can change as the model simulates. The packages all vary as to how and when the user inputs impact the results when the model runs step by step.

Similarly, we found a common core of array capability and a common core of "gaming" capability, with again with some differences between the packages. The greatest difference between the software languages involves discrete functions (like iThinks "Conveyors") and analysis tools (to use a very general term), such as Vensims RealityCheck.

***

The System Dynamics Society might learn from other industries and trade groups that have successfully designed and implemented inter-vendor open standards. The ADLs e-learning standard Sharable Content Object Reference Model - SCORM (http://www.adlnet.org/ ) and the World Wide Web Consortiums various XML Working groups ( http://www.w3.org/XML/ ) are both good efforts to look at.

Following these examples, I suggest a model interchange initiative should consist of two efforts:

(1) Specification of a common language for model interchange. This needs to be more than just the syntax of such a language; it should also include specification of arguments and behavior for each included function, and specification of a common computation method. Im familiar with some work done on this in the past by Magne Myrtveit, perhaps this could be a starting point.

(2) Development of a reference run-time implementation to simulate models in the common format. No specification can cover every possibility. When a vendor finds an ambiguity in the specification, the reference implementation serves as the standard. This is common in standard development. The ADL developed the SCORM reference run-time environment, and Sun lent its support to Apache Tomcat as the reference implementation for Java Server Pages.

>From a business perspective, I agree that the key challenge is to encourage the relevant software firms to implement a model interchange format. To be sucessful, a critical mass of vendors must sign on.

So, heres the gauntlet. Id like to offer the support of our firm, Forio Business Simulations, to the goal of designing a model interchange language, contingent on 3 other firms also comitting support. I propose that we implement a model interchange capability in our respective softwares by March 2004. Specifically at Forio, we can do the following

--> Share our research on model compatibilities/differences between the existing packages
--> Actively participate in a design committee, taking a leading role in specification design
--> Implement a reference implementation that would simulate a model in this common language, certified and distributed by the System Dynamics Society.

Look forward to comments from others on the list and at the NY conference!

regards,

Will

_______________________________________
Forio Business Simulations
Will Glass-Husain
chief software architect / founder
(415) 440-7500 phone

wglass@forio.com
www.forio.com

["Jim Hines"]

It looks like the time has come for Magne Myrtveits 1995 proposal at
the Tokyo Conference for a interchange language. Unlike then, I think
the society now would probably sponsor such an effort.

I suggest we have an organizing meeting at the New York conference this
summer. Everyone with an interest or something to contribute would be
welcome. I suggest that Magne Myrtveit chair the meeting.

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

["Ray on EV1"]

I have really enjoyed this topic. A little research shows that the Defense
Modeling and Simulation Office (https://www.dmso.mil/) has supported the
development of an integrating concept labeled High Level Architecture (HLA).
More info can be found at: http://www.mitre.org and http://www.omg.org/.
The idea was to allow developers to produce models under any development
environment they chose and allow the end user (military) to run simulations
in any simulation environment they choose. This extends the simulation to
distributed computer systems communicating over networks.

At one point, the DMSO had a publicly available simulation environment built
so everyone could test there products. Now the DMSO requires all models to
be delivered in this format.

The obvious advantage here is that the model can be built in an environment
conducive to the required productivity and quality for the project. The
model then can be delivered independent of its development environment. A
whole new set of tools can be marketed for the simulation of these models
(more competition).

A short sighted vendor community may see this as a loss in sales of their
integrated environment. As most corporations do not want to change (it cost
money to change), it will be difficult for some to adjust to this new
paradigm of the modeling and simulation market. Others will flourish as it
opens up new opportunities for user friendly simulations; simulation
applications that may use common engines but provide interfaces unique to
the specific application. This opens the door for value added resellers to
broaden the sales channels of engine producers.

The area is huge. The opportunities are vast. The far sighted developers
will identify the core tools and driving technologies that will explode into
this new market.

Ray
From: "Ray on EV1" <rtjoseph@ev1.net>

PS: The underlying key here is that we already know the fundamentals that
all models share - components and connections.

["Magne Myrtveit"]

Dear Colleagues,



Thanks to those of you who have posted your thoughts on standards and
formats for interchanging system dynamics models between tools and
platforms. I presented a proposal along the same lines at the SD conference
in Tokyo (1995). At that time the initiative was received positively.
However, the SD society did not want to sponsor or even recommend the idea,
as they were afraid that it could influence the competition. It also turned
out that the three main vendors at that time were not even able to agree
that it would benefit the field (and the vendors) if models developed in
different tools could be exchanged.



I am glad that there is not a new interest in this direction. Here are a few
things to keep in mind:



1) Standardization can be harmful if not done carefully

A standard can slow down and limit the innovation that goes on in the
various technology development organizations. If the standard is
ill-defined, we may "force" current and future technology into the wrong
direction.



2) Current SD tools have a common core, but differ dramatically in the way
they deal with important features such as unit of measure, arrays, model
hierarchy, data types, discrete flows (accumulation vs integration), etc.
Standardization in these areas runs the risks of favouring one tool or
locking the future to a poorly designed solution.



3) Standardization will and should take time

I do not think it is possible to define and implement a standard in one
year, unless the standard is limited to a small subset of the overall
functionality of the different SD tools. (The latter would limit the
usefulness of the standard.) If a standard is defined that includes all
(major) features of all (mainstream) SD tools, we would at first have a
situation where nobody supports the standard 100%. Vendors must be given
time to implement the necessary changes in order to support a new standard.
(The task of defining and implementing such a standard is huge.)



Going forward, I think the following approach may be worth considering:

Step 1: Define an open model export function in each tool (basis for step 2
and 3)

Step 2: Implement import functions in each tool (models can now be
interchanged)

Step 3: Define and implement a common model format (long term)



The challenge of step 1 is to convince the vendors to open up for exchange
of models by implementing a comprehensive model export feature in their
tools. The output can use XML, for example. (My initial proposal was to base
the standard on the syntax of RTF (rich text format). Today, XML is more
appropriate.) The exported format must be documented, and contain enough
information to describe exactly the semantics of a model (so it can be
simulated). The initial task of a standardization group would be to define
the guidelines that each vendor would follow to generate its versions of the
XML model.



When the XML-specifications from each vendor are ready, we have a complete
definition of the simulation languages that are supported, and it is
possible for each vendor to implement an import function from one or more
foreign formats (step 2).



A vendor should not be permitted to implement an import function unless it
also implements an export function (first).



After step 1 (and 2) we would have a better understanding of how a common
format could be defined.



With this approach I think that we can avoid some of the dangers with
defining a standard, and at the same time save time and effort to implement
interchange of models between tools.



Magne Myrtveit

Dynaplan

Home page: <http://www.dynaplan.no> www.dynaplan.no

Mail address: Helland, 5936 Manger, Noreg

E-mail address: <mailto:magne@myrtveit.com> magne@myrtveit.com

Telephones (+47): 56 37 40 09 (office); 95 82 75 00 (mobile)

Telefax (+47): 56 37 35 00

[=?iso-8859-1?Q?Anast=E1ssios_Per]

Dear friends,

picking up from two recently posted messages on Simulation Model Interchange
Language, I would like to share a thought. Besides the technical
pro-SMIL(E) arguments presented, and the valiant collaborative offers of
certain colleauges, there is a common-sense reason to go ahead with it: a
fragmented (or non-bridged/ non-unified) SD software market creates
non-cohesive image of System Dynamics. So, as a matter of strategy, it
seems imperative that the SD community supports a SMIL(E) project.

Just a thought, calling on visionaries.

Best regards,
Tasso

---
Anastássios Perdicoúlis
From: =?iso-8859-1?Q?Anast=E1ssios_Perdico=FAlis?= <tasso@utad.pt>
www.utad.pt/~tasso

[carolus]

SDs,

The construction of SD models is done in a number of ways including
different software
packages on different platforms. This diversity has a number of
advantages but at the same time it is restricting the ability to
exchange views and comments on certain models, since models are not
(yet) vendor- and platform neutral. That restricts the necessary feed
back on our models from colleagues who are just using something else.
Or, in an other envrionment, it limits the possibilities of learning
simply because the client is using something else.

One way to handle this problem is the development of a Simulation Model
Interchange Language Entity
With such a SMILE, modelers could go on modeling using their prefered
tools whereas the result shoud be usable by anyone using other (SD) tools.
This would improve the exchangeability, of models, increase feed back
and knowledge about models.
It would also increase the insight in system dynamics regardless of the
coincidental soft- or hardware choice of the modeler.

This idea is not a new one.
Several vendors allready have a - limited - feature of translating
(parts of) models from language A into B.
However, it mostly comprises the stripping of an original rich model
that then has to be redressed.
In the end, the experienced modeler just rebuilds it: starting from scratch.
There is nothing wrong with that.
On the contrary, it often enriches ones understanding of a problem
using a different tool.
On the other hand, the ability to learn from others has to start with
the possibility to look into each others THIS IS SPAM. And that is - for the
time being - not so easy.

So, I wonder who is interested in the development of a SMILE?

In order to answer this question it might be worthwhile to make an
inventory of the diversity in software packages and hardware platforms
amongst the SD users (at least on this list).
Would it be interesting to spend some effort both by users and vendors
in developing criteria, searching for pitfalls and sketching an outline
for the development of a SMILE?

--
greetings,

Carolus Grütters
Law & IT
http://www.jur.kun.nl
it/

Centre for Migration Law
http://www.jur.kun.nl/cmr/

University of Nijmegen
Nijmegen, The Netherlands
email: c.grutters@jur.kun.nl
tel: +31 (0)24 361.57.01
fax: +31 (0)24 361.61.45

["George A Simpson"]

I think it would be beneficial if SMILE included both dynamic and discrete
simulation.

Also, there is an initiative called BPMI (Business Process Modelling
Initiative) with a well developed language (BPML) which may be an
appropriate foundation for SMILE.
Its XML and pi-calculus based. See www.bpmi.org. for details.

...george...

Dr. George Simpson, Principal Consultant, CSC
From: "George A Simpson" <gsimpso4@csc.com>
Royal Pavilion T3 floor 2, Wellesley Road, Aldershot, Hampshire GU11 1PZ
United Kingdom
office +44 (0)1252 536523, fax +44 (0)1252 534132, mobile 07814 623 518