Community Forum : General Discussion Forum
Welcome Guest   
 
 Subject : SD software characteristics.. 12/05/2018 05:09:45 PM 
Mr. Leonard Malczynski
Posts: 34
Location
Hello everyone,

If you had to choose 5 features or characteristics of your favorite SD software tool what would they be?

I am often asked to suggest and compare tools. As far as I know no such comparison exists. Of course there are lots of opinions and there are network effects.

I am looking for objective measures.

Thanks,
Len
P.S. If you want to work on this please let me know
 Subject : Re:SD software characteristics.. 12/13/2018 12:14:25 PM 
Guido W. Reichert
Posts: 10
Location
Hi Len,

your question unfortunately already appears a bit "loaded" as it addresses "tools". I would start with a modeling language for SD - for example Ventana talks about the "Vensim modeling language" in its documentation. Unfortunately, the "Vensim lanaguage" is proprietary and in fact every SD-tool somehow produces it own code.

While as far as I understand it XMILE attempts to establish a kind of meta language for SD, I find XML-like standards unfortunate, as they are anything but not human-readable (you very likely would not want to read and write XML to model).

My language of choice for modeling dynamical systems is Modelica which has these features:


1. A more or less wide spread open source standard (non-proprietary) for which there is a sufficiently rich choice of commercial and free set of tools (e.g. for graphical and equation-based modeling, simulation, and analysis). Note, that the language has a concise specification so that there is no question about what goes on behind the scenes.

I am using Open Modelica and the Wolfram System Modeler for modeling, which is tightly integrated with Wolfram Mathematica for simulation and analysis.

Functional Mockup Interface (FMI): The model can be simulated pretty much on any device and allows co-simulation and real-time application, if wanted/needed.

2. Enables hierarchical modeling using reusable components (e.g. object oriented modeling based upon classes and inheritance). Each partial model or component can have its own documentation (which is also inherited and linked...).

3. Is equation based ("==") not assignment-based (":=") so that a model and the machinery ("solver") for simulation are separated. Also Modelica can solve algebraic equations (DAE) so that there is great flexibility to include acausal physical components as well. No tight binding between model and simulation, e.g. no "TIME STEP" hard wired in equations as a model should be compatible with many different solution methods, not only fixed-step solvers.

4. Multi-paradigm language, that allows to do combined discrete-event and continuous-time modeling within the same model (hybrid modeling). There is an elaborate event-handling machinery.

5. Multi-domain modeling (To me this is the main appeal of Systems science): Next to our general System Dynamics modeling, there exist a pletora of libraries (commercial and free) for other domains that can easily combined within a model: complex physical systems containing, e.g., mechanical, electrical, electronic, hydraulic, thermal, control, electric power or process-oriented subcomponents. Just have a look at Modelica libraries with fuzzy control, neural networks etc.

For a nice introductory overview with regard to System Dynamics see here.
Last Edited On: 04/16/2019 09:05:05 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 12/17/2018 11:57:41 AM 
Jean-Jacques Lauble
Posts: 15
Location
Hi

I added a post to the Community forum that replies partly to this thread.

Regards.

JJ
 Subject : Re:SD software characteristics.. 02/01/2019 04:52:14 AM 
Jean-Jacques Lauble
Posts: 15
Location
Hi Guido, Len and everybody else.

When I consider the evolution of Vensim since I started to use it 17 years ago, I cannot find any new feature that meanwhile really helped me improve my modelling capability. My modelling capability came from experience only. I cannot tell if I do SD modelling and at what extent, being concerned with the solving of my problems that exist independently of any paradigm or software.
For example I have added recently dynamic programming methods to my models, something that I have still to experiment. I can do it with Vensim so far.

I then think that improving or comparing different SD or partly SD tools will not solve the main problem of SD: the fact that 99% of SD people are incompetent and the 1% that are or could be, do not dare to denounce the bad models of their colleagues, something that would at last redirect SD towards a true scientific and efficient tool. I do not put myself in the 1% competent, having not yet being able to build a model really useful to something.

Best regards.

JJ
 Subject : Re:SD software characteristics.. 04/08/2019 04:40:47 AM 
Guido W. Reichert
Posts: 10
Location
Hi JJ,

I would not say, that 99% of System Dynamicist are incompetent, but model quality and the ability to do the "hard stuff" (e.g. use modern quantitative methods as proposed by Sterman recently in his article "The path forward - System Dynamics at sixty") are crucial and you touch a nerve there.

Making System Dynamics more scientific (which does not preclude them to be useful products from an "applied science" at all!) is imo definitely the way to go. This starts with having models and results replicable. You mention turning to dynamic programming. If you take a look at chapter eight in "Analytical Methods for Dynamic Modelers" edited by Rhamandad et al., you will find a good introduction written by Erling Moxnes. Unfortunately, in that book you will not find the code for his models -- instead there is a reference to digital content that can be freely downloaded (i.e. Online Appendices).

In Moxnes' case he has published PowerSim models that cannot be read by someone that does not own PowerSim (opposed to, for example, Vensim, the model's code is not given as an intelligible text file, but is given in a binary format only). So, the use of some proprietary software makes replication a nuisance.

Modelica models -- like Vensim models -- are published as plain text files (modeling after all is declarative programming). Unlike Vensim, Modelica is a widely adopted open source language, that is not proprietary and is compatible with a lot of different tools for modeling, simulation, and analysis.

This to me is important in making System Dynamics more scientific.

You claim, that Vensim's innovation (and maybe the features of Modelica that I mentioned?) have not helped you so far in solving your very own problem(s). But these problems of yours are also "proprietary": You have never published them and thus nobody can replicate what you say. We simply have to take your word for it -- which is very unscientific ("nullius in verba")...

I find, that hierarchical, object-oriented modeling -- next to an open source, widely adopted standard accross different domains -- is helpful at least in building models faster and more reliable. Having partial models as "instances" also greatly helps in testing partial structure and thus may help to raise model quality in the long run.

Personally, I have found the unifying promise of "Systems Science" most appealing. But what has happened is, that System Dynamics has pretty much decoupled from the "hard sciences" which uses other tools even for equation based modeling. This development seems unfortunate to me. In Modelica I can easily do physical, chemical, biochemical, or even physiological models next to System Dynamics.

Modeling complex dynamical systems should be a non-proprietary universal language as much as possible.

Best regards,
Guido
Last Edited On: 04/08/2019 04:46:11 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 04/08/2019 07:53:54 AM 
Mr. Leonard Malczynski
Posts: 34
Location
Guido,
Thank you for the interesting comments.

So many ideas come to mind when reading your post: network effects, path dependence, switching costs, etc.

When looking back on the tool selection I made in the early 1990s it was a decision based upon features. The modeling tool had a feature that none of the other leading tools had: access to MS Excel data. As more and more projects used the tool we developed more and more skill and reusable components that encouraged us not to switch tools. The firm that made the software kept improving and adding features to the tool. We stayed with it and have not yet been limited by what the tool can do.

Of course, that may be a function of the problems we tackle (not general modeling) and the proprietary nature of the work. Most of use were not software engineers but domain experts that welcomed the interactive development environment (graphical, supported SD methodology, permitted non-SD extensions, etc.).

I went to the Modelica site and was quite confused about how to get started, what to download, etc. That is a switching cost to me. Of course, the cost of conversion and possible missing functions, interface objects etc. are also important. Perhaps this debate is making clear that there are niches in the modeling world; academic, proprietary, constrained, etc. that require one tool or another. I was told at least twice what tool to use, over my protestations. The final work suffered because of the choice.

P.S. Vensim models are indeed in text but must be parsed to make sense of them. Studio models can be exported to delimited MS Excel files so all equations can be seen with name, units, dimensions, functions used, and more.

Len
 Subject : Re:SD software characteristics.. 04/09/2019 06:35:55 AM 
Guido W. Reichert
Posts: 10
Location
Hi Len,

you mention switching costs and path dependence. Alas, that almost always holds and fighting climate change is a very good case in point; who will switch to a different behavior when there is a cost?

But we have to consider "barriers to entry (and understanding)" and "barriers to collaboration" as well. Ideally, in collaboration with other modelers everybody should simply write his model in "his langauge (!) of choice" and then in the final simulation the partial models are simply run in combination.

That is called "Co-Simulation" and Modelica supports the Functional Mockup Interface that exactly allows to do just that.

While there is switching costs, there is also something to gain and today very few people still write their programs in Assembler. The gains of higher level programming languages obviously was higher than the costs.

To me, System Dynamics modeling is more like Assembler and is very low level (few building blocks). While we claim to model "structure" nobody can usually identify a real system's structure from looking at a System Dynamics model. Logistic growth as a System Dynamics model cannot be recognized from looking at its visual structure alone; to be safe, you will have to inspect the equations hidden as "parameters" of converters and other elements.

So to have a "SinkOrSource" element in Modelica (e.g. a flow coming from a stock with infinite capacity or filling it) called "Logistic Growth" on its Icon showing an inflow to me is very compact and concise. It allows a third party to immediately see what is going on in the partial model just from visual inspection.

Conversely, the ideal in Modelica is that a modeler should not have to write equations. More realistically using Modelica minimizes writing equations and thus helps to prevent copy & paste errors.

Here is an example:

QOOiq.png

Of course, you do not have to use graphical building blocks and you can always just write text:

Bqx6v.png

I would argue, that the switching cost to learn writing SD models in Modelica as text is rather quite low. ;-)

Note: To set up the model above in equilibrium you might simply add

initial equation
der(x) = 0;
der(y) = 0;

since Modelica can solve algebraic equations as well


To start you simply can download Open Modelica here. There are excellent introductions and you can model, simulate, and analyze your models using Open Modelica (which has interfaces to Java and Python as far as I know). Michael Tiller has written a very easy to understand introduction where the Lotka-Volterra example comes closest to what we do in SD.

Using the freely available SD library by Cellier allows to model SD using Forrester's symbols from Industrial Dynamics (the library also has World2 and World3 included which eases learning greatly). One can simply download (or fork) it from GitHub and use it with Open Modelica to get started.

Best regards,
Guido
Last Edited On: 04/09/2019 06:47:33 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 04/10/2019 10:36:13 AM 
Martin Schaffernicht
Posts: 27
Location
Thanks Guido,

this discussion has ignited my curiosity so much that I'll invest some time into OpenModellica.

In my opinion, being able to work with "chunks" (rather than atomic components) looks promising. We've seen the Vensim "molecules", and in recent years the STELLA "modules" and SYSDEA sub-models have made steps toward decomposition and a more modular approach to model formulation. It also seems to me that the "standard formulations" are the mental counterpart to such "model chunks", and that a person who is acquainted with these formulations can retrieve a mental representation of the space of likely behavior modes implied by this-or-that basic model structure.

I also believe that developing diagrams is more of a help than a bother, at least while you are in the face of a complex situation you are not entirely familiar with. Again, software like SYSDEA always tries to display the behavior of variables (so you are not on your own with mental simulation). Isn't the development of a diagram a useful step on the way from natural language to a mathematical representation?

Well, now I'm curious to find out about Modellica!

Best greetings,
Martin
 Subject : Re:SD software characteristics.. 04/11/2019 02:41:06 AM 
Jean-Jacques Lauble
Posts: 15
Location
Hi Guido.

You know my opinion about SD. For a field to be successful there is a need for a solvable market,
good tools to produce the service needed and competent people to use the tools.
In the case of SD, the tools of course could be better, but they are not better because the people are not competent and deliver a cheap and low service quality.
For instance, in the case of Vensim that I use, there was an interesting feature released in 1994, the reality check. The idea was good, with the intention to test the adequacy of the model to the reality it was supposed to represent. Unfortunately, nobody used the tool, and it was never improved.
In fact, the field decided to deliver a low level of service and low price, where there was enough demand and the technical ability to serve it.
You realize that by surveying the quality of the publications at the SD conference for instance.
I tested too the competency of a renowned consultant that delivered a low quality and cheap study which had even equation bugs in it. I estimate that to make a real quality study, the consultant should have charged the service about 10 times more than what he charged, something that I was ready to pay. Of course the consultant was not used to deliver high quality studies and delivered what he is used to deliver.
In fact the field is trapped in a feedback loop: low quality -> low reputation -> low price -> low revenue -> low quality.
And it is not by trying to improve software that you will change that. Currently SD people are not even able to use correctly the current software available and there is no interest providing them better solutions.
Best regards.
JJ
 Subject : Re:SD software characteristics.. 04/11/2019 08:47:01 AM 
Guido W. Reichert
Posts: 10
Location
Hi JJ,

I can understand your frustration with the field and some low quality. While the right choice of software/modeling language is no panacea, it it imo a good start.

I have "coded" dynamical systems in Stella/iThink, in Vensim, in Wolfram Mathematica, and in Open Modelica/ the Wolfram System Modeler. Vensim definitely has very nice features and the reality check was a great idea (I actually used it).

Nevertheless, I have shifted away from Vensim because I was a bit tired of wainting for bugs being fixed and because there were limitations to what you could do (or do "nicely"). Wolfram Mathematica to which I turned has proven to be an (elegant) swiss army knife for anybody working remotely quantitatively. It opens up an integrated modeling workflow from importing data, transforming and pre-processing it up to building simulation models with event handling.

Unfortunately, doing anything more elaborate with system modeling does need a graphical user interface (GUI). I tried coupling Vensim and Mathematica (via the DLL) and that has some charm, but it also has its limitations - there is no nice integration.

Modelica is declarative programming language that is very, very flexible. Essentially it empowers you to do "whatever you want" and to make it look like you want it (you could approach the look of a Vensim model, if you wanted that).

Essentially, I believe in using the "most advanced / flexible tool" out there, so that the likelihood of "hitting a wall" later on (when you are deeply invested and have fallen prey to what Len calls "switching costs") is minimized. With Modelica there seems to be always a way to tackle a problem without having to wait for my "vendor to implement it".

That will certainly not solve the other problems of System Dynamics, but it seems to me a sensible choice of "tool" (better: language) to go about building dynamic models. Needless to say, most of the "advanced methods" are still originating in engineering or STEM and not in the social sciences. Modelica being firmly established in the former community does increase the chance to have more advanced methods being implemented.

Reusable components do help to avoid basic errors and may also help to build better models -- especially if you share "good & proven" partial models on something like GitHub.

RealityChecks essentially are changes in a model and a rather generic comparison with test signals/ modes of behavior. Since Modelica allows to declare components as "replaceable" (change of model structure) and since one can easily modify parameterization you can probany achieve something similiar there by "redeclaring" components (test case) and then comparing the simulation's output to a reference behavior mode/pattern. While it probably would take some time to write it up in Mathematica, the point is: You could (likely) do it in principle by yourself instead of being dependent upon Ventana (having lost interest).

Empowering the modeler will not make great SD by itself, but it imo is a good start.

Best regards,
Guido

PS: For passive checking you can always write assert( condition , "Message", ... ) statements in Modelica as that is what it does to detect events.
 Subject : Re:SD software characteristics.. 04/11/2019 10:17:09 AM 
Guido W. Reichert
Posts: 10
Location
Hello Martin,

I am glad, that I have succeeded in making you curious enough to download OpenModelica. There is a circle I have started here about OO-modeling with Modelica - I would be happy, if you joined. ;-)

Unfortunately, what I have shown so far is based upon my own library (work in progress). And that compactness in diagramming is what has driven me to go those extra miles. In Modelica, there is so far mostly the free library by Cellier to use that looks like Dynamo.

Going about (reuseable) component based modeling requires some "rethinking". Essentially one starts with defining the interfaces of a system. In Modelica you will typically have causal inputs and outputs (e.g. the blue and white arrows) and acausal connectors (e.g. stock and flow ports shown as magenta squares).

Acausal connectors typically are unknown in System Dynamics. They are related to bond graphs where an arrow always describes a bidirectional flow (e.g. potential and effort as through and accross variables).

xnJI1.png

While we claim to model "structure", we will probably agree, that nobody would recognize the inverted pendulum model from looking at the lower left corner. But everybody will at once recognize the Modelica model on the right side.

In Modelica causal loops (feedback control) are separated from reusable, acausal physical models that may behave differently depending on their use. While in causal, block-based SD modeling we would have to write two different models if the motor in the example were to be a generator - in Modelica a single model will suffice.

Unfortunately, in SD energy conservation and definite natural laws are rather non-existant. Nevertheless, as I said, we may use acausal connectors to make models more readable and compact. We are simply using the "potential" of the acausal connectors as a data channel to transmit the amount contained in the connected stock (thus we do not need to make minor loops explicit!). We are thus using some kind of "mass port" (e.g. like double arrow - connections).

Once we have defined our connectors, we can classify our components according to their interfaces:

1sNNG.png

The Basic Components are mostly well known; the "Sources or Sinks" are simply flows that orginate from or flow into a stock with infinite capacity (i.e. a cloud). In the example given here "Logistic Growth" is such a compact component (the "Lotka-Volterra" is an interaction).

The Molecules of Structure that Jim Hines has meticulously written up and that you have mentioned, might be divided into six types of components: Policy, Information Processing, and four different types of generic subsystems.

A typical Transceiver-subsystem is the Aging Chain. It consists of a chain of Material Delays (another component) and one can simply set the length of the chain by a parameter in the modeling environment. Also, different from Hines' version, for each material delay in the chain a different delay order can be given. There is also a switch to have the chain end in a cloud or in the (out-)flow port.

nzq8Z.png

Using hierarchical modeling most SD models (hopefully) could then be presented using iconic images (as in the pendulum example) or - on a lower level - as Policy Structure Diagrams following the diagramming critique by Morecroft (1982).

Once a certain level has been reached pictorial icons (e.g. management, factory, customers ...) can be used to achieve the same kind of recognition as in the pendulum example.

I am not so sure about showing the behavior (e.g. the time series for some stock or flow) in the model diagram. While I am aware of Kim Warren loving it, I personally find, that it clutters a digram rather quickly.

Structure causes behavior and I would first of all like to show structure very clearly and recognizable. The behavior can then be presented as needed (maybe even within an aggregated causal loop as a "graphical node"?). Showing behavior directly imo only works for atomic elements (e.g. single stocks or flows) in diagrams, e.g. which time series should be shown for the aging chain component?

Best regards,
Guido
Last Edited On: 04/11/2019 10:27:39 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 04/11/2019 11:57:44 AM 
Mr. Leonard Malczynski
Posts: 34
Location
Everyone,

When I think about modeling software I know that there are many tools to choose from. I have used many myself. However, when I was exposed to the System Dynamics methodology I first looked for a tool to enforce the methodology that was developed by Jay Forrester - basically stocks and flows. I wanted a tool that would constrain me to developing models that could describe problems in the system dynamics applicable problem domain.

After using all of what I call the 'Big Three' I settled on what was then Powersim Constructor (circa 1993). I stuck with the software over time (now called Powersim Studio) and have been able to do SD, discrete, and hybrid models with it.

The network effects and path dependence plus the switching costs of moving to another tool are overwhelming. If the problem required non-SD concepts I would try to use Studio and its built in extensions (VB Script and C++). If that didn't work I sought the right software for that domain, e.g. linear programming. I was successful in using Studio to do minimal spanning trees, simple GIS, estimate 5th order polynomial functions, build very useful user interfaces, etc.

I am definitely biased, I am a reseller of Studio in North America, I monitor the Yahoo Studio User Group, and with my business partner have made more than 100 models from texts (Sterman, Hines, Bossel, Richardson) available for free in Studio (with units!) on our website.

I have been trying to imagine a scenario that would make me switch.

Nevertheless, I encourage this discussion. Last year in Reykjavik I gave a talk on model construction quality. One point was this (taken from the Romans): De gustibus non disputandem est – About matters of taste there is no point in arguing.
De veritate disputandum est – About matters of truth, dispute is fruitful.

Thanks for getting me to think and reflect.

Best regards,
Len
 Subject : Re:SD software characteristics.. 04/11/2019 12:08:27 PM 
Martin Schaffernicht
Posts: 27
Location
Hi Guido and Jean-Jacques and Len,

thanks for the additional orientation. I will need a while to make my first explorations, but whenever I have a question, I know whom to ask :)

Curious: one of the things I'll be interested in is precisely the import of data and its use for "reality-checking". I am not surprised that I get this idea from Jean-Jacques: over the years, I have picked up quite some inspiring questions and observations coming from Jean-Jacques.

I do agree with Len that it is a tough decision to switch from one modeling environment to another. It takes time to become proficient with a new tool, so there is a sacrifice, and it is not easy to decide if the benefits will outweigh the sacrifice. I've lived with this tension for years now, using Vensim or STELLA or SYSDEA or Mathematica (depending on what I needed to do), and having second thoughts on XMILE (as long as only one software provider implements it, it does not take off).

Over the past years, we've seen SD libraries in Python and in R, NetLogo has some of SD capabilities in it... now let's see how much time it takes me to start "talking" Modellica...

Best greetings,
Martin
 
# of Topics per Page