Community Forum : General Discussion Forum
Welcome Guest   
 
<< first < Prev 1 2 Next > last >>
 Subject : SD software characteristics.. 12/05/2018 05:09:45 PM 
Mr. Leonard Malczynski
Posts: 44
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: 26
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 10:05:05 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 12/17/2018 11:57:41 AM 
Jean-Jacques Lauble
Posts: 39
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: 39
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 05:40:47 AM 
Guido W. Reichert
Posts: 26
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 05:46:11 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 04/08/2019 08:53:54 AM 
Mr. Leonard Malczynski
Posts: 44
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 07:35:55 AM 
Guido W. Reichert
Posts: 26
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 07:47:33 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 04/10/2019 11:36:13 AM 
Martin Schaffernicht
Posts: 40
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 03:41:06 AM 
Jean-Jacques Lauble
Posts: 39
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 09:47:01 AM 
Guido W. Reichert
Posts: 26
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 11:17:09 AM 
Guido W. Reichert
Posts: 26
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 11:27:39 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 04/11/2019 12:57:44 PM 
Mr. Leonard Malczynski
Posts: 44
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 01:08:27 PM 
Martin Schaffernicht
Posts: 40
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
 Subject : Re:SD software characteristics.. 04/18/2019 12:00:32 PM 
Jean-Jacques Lauble
Posts: 39
Location
Hi everybody

I wanted to notice that often people miss the root origin of a problem, looking at what is more convenient to observe, leaving other reasons more difficult to grasp ignored.

As a problem owner and SD practitioner too, the SD software are to my opinion the only valid thing that you can find within the SD profession. I have tested during 17 years, books, courses (at MIT and WPI), forums, publications, review, conferences and even a consultant supposedly expert and world renowned. Everything but the software was mediocre, superficial, often simply mathematically wrong, not convincing. Then criticizing the software is just wrong. Of course, it could be better, but it is not at the origin of everything else being poor.

Best regards.

JJ
 Subject : Re:Re:SD software characteristics.. 04/25/2019 07:37:35 AM 
Guido W. Reichert
Posts: 26
Location
Jean-Jacques Lauble Wrote on 04/18/2019 11:00:32 AM:
Hi everybody

I wanted to notice that often people miss the root origin of a problem, looking at what is more convenient to observe, leaving other reasons more difficult to grasp ignored.

As a problem owner and SD practitioner too, the SD software are to my opinion the only valid thing that you can find within the SD profession. I have tested during 17 years, books, courses (at MIT and WPI), forums, publications, review, conferences and even a consultant supposedly expert and world renowned. Everything but the software was mediocre, superficial, often simply mathematically wrong, not convincing. Then criticizing the software is just wrong. Of course, it could be better, but it is not at the origin of everything else being poor.

Best regards.

JJ

JJ,

If all were fine with software, then why is there one new piece of SD software after the other? Len has mentioned the "big three" (being from the 80's/90's) which, as you claim, should not leave a lot of room for improvement. And yet, we see Magne Myrtveit leave PowerSim and come up with Dynaplan. Kim Warren has come up with Sysdea - very likely not because he shared your verdict about tool sufficiency. Ventana, to give another example, has started with Ventity probably because somehow object-orientation and hybrid modeling approaches must have mattered.

I believe these are cases in point for showing the relevance of this thread. All I have tried to point out is, that you can only "say and think" (i.e. model) what your language will allow you to express. A powerful modeling language and its precise specification are important in my opinion.

So far in SD I mostly see proprietary tools and their sales representatives - in very prominent positions. Maybe selling SD software is the real thing?

Regards,
Guido
Last Edited On: 04/25/2019 07:57:06 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 04/28/2019 12:00:34 PM 
Jean-Jacques Lauble
Posts: 39
Location
Hi Guido
I did not notice your post and my answer is a bit late.
I have been programming for about more than 55 years now, and worked with many languages: Algol, Fortran, Cobol, Many different basic, PL1, a relational database for microcomputer named RBASE, once distributed by Microsoft with its own language, later with Interbase, etc… Changing with the tools never added any noticeable advantage. The only significant advantage was from switching from traditional file management to relational databases and the accompanying tools. This was a true technical discovery.
About Sd software, I have over the years tested different software, but never found any utility about changing the one I use and am accustomed to.
There are plenty different cars on the road, and they roughly do the same job, and in this case the differences may be justified, but with SD software, I would like somebody to explain me the real advantage of one software over another one. As you mentioned, the real motivation about launching a new software is financial. Once you have a sufficient number of users it becomes a rent, especially in a market that has no really specific technical improvement. About object oriented as an end user I have never found which utility was in Excel VBA that is object oriented.
About Ventity, I think that Ventana people, wanted to make a more fashionable software and cure some limitations of Vensim: limitations that are easy to avoid if you are sufficiently competent. I have been looking at Ventity, I do not see what improvement it brings. Apparently one of the main purpose is to suppress the mapping system and to replace it by another one that is to my opinion more easy to understand for a beginner, but I wonder if it is as powerful. I like very much Vensim’s mapping system and find it very powerful. I do not need Ventity and I have a doubt about its success in the long run.
Finally, the reason for new software is financial and the desire to add something more than the competitor even if it does not really add anything. My product is better because it is more fashionable! This attracts beginners and people not informed.
Of course I do not deny that SD software could not be better. But was is the interest of being better if the users are not competent enough to use it?
Most Sd modellers are not already able to use SD software as it is now. Why adding more possibilities.
A good example is with Vensim reality check, that was finally a good idea, but was never adopted end users because the average end user does not really mind about having a quality model as long it can be sold and generate money.
This feature being not used was never developed and improved.
Best regards.
JJ
 Subject : Re:SD software characteristics.. 04/29/2019 08:16:39 AM 
Guido W. Reichert
Posts: 26
Location
Hi JJ (and everyone),

For clarity, I would like to start with a slight correction: If you do look up VBA, you will find, that it is "object-based" -- not "object-oriented". That is a difference.

Let me explain for Modelica. Typically you will start out defining Interfaces as partial models. Partial here means, that the model itself will not run (and is not what is called balanced with regard to the number of equations and the number of unknowns). Interfaces typically define base classes by first of all defining what connectors they have.

As an example, a GenericConverter, might have a certain icon (e.g. a circle as in most SD-software) and we may then say that it will have a single output (typically a number of type Real). We can then build another basic class called Converter_SI2SO that simply extends the definition given by the GenericConverter class; to define that class I will only have to add two inputs, so no copy and paste (with errors). This is following the well established DRY (Don't Repeat Yourself) principle of software development.

If I change the Icon for the GenericConverter, then all instances that built upon this class will automatically change as well. This has tremendous benefits for keeping the code base small and for avoiding inconsistencies.

Of course, we are now talking about a low-level activity: Building a library to model SD, for example. A modeler will usually not do this and instead use predefined components which he will then connect or parameterize (e.g. define the parameter n giving the number of reservoirs in a chain thereof).

Thus your verdict, that adding more possibilities will not help to improve SD modeling by "incompetent users" is not a fair statement. There are typically three roles for "programming in Modelica":
  1. the builders of libraries
  2. the designers of components (using libraries)
  3. the modelers using components

Typically, using SD software mostly will not allow you to do roles 1 and 2 (in Vensim you may do some macro definitions, but that is a very uncomfortable alternative). Having more possibilities for building libraries and components will actually narrow the possibilities for the modeler, so that building models is easier and less error prone (at that level). I find this to be an important distinction.

To wrap this up, let me point at the beginnings of the field, which started with DYNAMO - a programming language for models. You will find DYNAMO in the list of programming languages, but you will not find any of the following in that list: Vensim, PowerSim, Stella/iThink, AnyLogic , Sysdea or XMILE. You will also find DYNAMO in the list of simulation programming languages, which at least lists Vensim.

Interestingly, only Modelica, like DYNAMO does make it into both lists.

You never mentioned barriers of entry: You can freely download OpenModelica which allows for complicated array mappings, export of FMI, and optimization. You cannot do any of this with the freely available Vensim PLE.

Regards,
Guido
Last Edited On: 04/29/2019 08:29:23 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 05/28/2019 06:46:46 AM 
Guido W. Reichert
Posts: 26
Location
Hi everyone,

Some time has gone by now and this whole post feels like a non sequitur: There is still after E-Mail exchanges and lots of postings no immediately visible link to Modelica/OpenModelica on the Core Software page. Not even under the section of tools that extend the SD paradigm, even though Modelica offers object-orientation and hybrid discrete-event simulation and the free System Dynamics library ships with World2 and World3 next to other SD examples.

What does it take to take note?

What is even more striking is an obvious bias: Powersim Studio is the only tool that is listed twice (once as one of the three main tools and once as a tool that extends the System Dynamics Methodology)! While we never learn that Ventity, for example, does extend the SD paradigm, Powersim is extensively highlighted as such.

Even more striking, there is only one tool listed under tools that extend the System Dynamics Methodology that is set in bold face - yes, you may have guessed it: It is Powersim Studio!

We have learned, that Len, who seems to be responsible for the page, is a reseller for Powersim Studio...

Now, I don't know about you, but for me this a bit too much and I am not willing to pay a membership fee to finance a sales initiative for tools!

You give a warning with regard to the Wikipedia page listing System Dynamics tools:
Quote:
Wikipedia has a page SD software comparison. This is NOT a comprehensive comparison. Please use with care and visit the individual vendor sites.

But it should be the other way around:
Quote:
The SDS has a tool page, but it really is a vendor sponsored page, that is NOT comprehensive, so read with care. Please refer to public information on Wikipedia for a more unbiased presentation!

Please reconsider the presentation on the SDS page, because I will clearly not renew my membership, if you do not: I definitely expect the SDS to take a "scientific and open" approach to modeling and simulation.

Best regards,
Guido

PS: What I have presented in this thread and on the annual conference of the German chapter of the SDS will be available shortly as a free Modelica library.
Last Edited On: 05/28/2019 06:52:33 AM By Guido W. Reichert
 Subject : Re:SD software characteristics.. 05/28/2019 10:02:36 AM 
Jean-Jacques Lauble
Posts: 39
Location
Hi Guido

The SDS is not scientific and open. And it is better to understand that and not to expect the SDS to ever become better.

For instance, Kim Warren who is the strategy committee chief, will act to defend his Sysdea tool, and everybody in the SDS has his own interest.

For me for instance the SDS has little interest and is just worth the 150 dollars
I pay per year. Having understood that, I do not expect anything and it is better so.

Best regards.

JJ
 Subject : Re:SD software characteristics.. 05/28/2019 10:07:35 AM 
Mr. Leonard Malczynski
Posts: 44
Location
Guido,
I am sorry that the Tools site has not been properly maintained.
I gave up managing that page in May of 2017, almost 2 years ago.

I will see that it gets fixed. Please send me a paragraph and links to Modelica. I realize that you have provided extensive features and screen shots from Modelica on this Forum but I want to be fair to the other tools/languages. You can find my email address under the Members menu item.

In the transition to the new Member Clicks system more than 100 web pages had to be converted to the new system. This was a page that was obviously not updated.

I have never promoted Studio as the 'best' tool nor mentioned specific features in this Forum except that I use it. It is incorrect to say that vendors manage the page. The page got such little traffic it was essentially forgotten. Also note that Vensim and Ventity are linked names while isee systems and Powersim AS are not (at the top of the Core software page). I do not know who did that.

The Society does not manage the Wikipedia page. It may be that some Society members edit it. Nevertheless we know that many more people use SD than are members of the Society.

Regards,
Len
 
<< first < Prev 1 2 Next > last >>
# of Topics per Page