Community Forum : General Discussion Forum
Board Index Welcome Guest   
 
<< first < Prev 1 2 Next > last >>
 Subject : Re:SD software characteristics.. 05/28/2019 10:12:20 AM 
Mr. Leonard Malczynski
Posts: 50
Location: 
JJ,
Sorry to be a pest.

The Society is managed my volunteers. Some of them spend more than 400 hours per year doing all sorts of things that most members never see because most members do not participate.

There is no secret group that does things. All meetings are open to all members, etc. The year I served as the Society President many people approached me and said something like this, "You know Len, The Society really ought to do x". My first response was, can you volunteer to do that?

We desperately want more dedicated volunteers.

Anyone that reads this can contact me to volunteer. Look for my email in the Member Directory.

Regards,
Len
 Subject : Re:SD software characteristics.. 05/29/2019 03:18:40 AM 
Jean-Jacques Lauble
Posts: 55
Location: 
Hi Guido

Just a remark concerning the possibility of not renewing your membership. This is something that I am tempted to do every year, since 18 years of membership. But I think that the field needs people like you and me, who feel sufficiently free to name a cat a cat, breaking sometimes the general SDS OMERTA. Do not be afraid: big brother (PHD’s) will not byte you across the ocean.

Best regards.

JJ
Last Edited On: 05/29/2019 03:22:37 AM By Jean-Jacques Lauble
 Subject : Re:Re:SD software characteristics.. 05/29/2019 04:10:34 AM 
Jean-Jacques Lauble
Posts: 55
Location: 
Hi Len

First, Len you are not a pest!

You mentioned the desperate need of volunteers.
You should precise ‘selected’ volunteers.
Last year, I decided to accept being a reviewer of papers published at the SDS conference.
I did not accept it this year, because of the papers I had to review being so bad. Of course, I did not praise these papers, but they were still published during the year! What was the utility of my work?
At the end of 2017, the society asking me to be a volunteer, I accepted to do anything that could be useful. As the president of the SDS you proposed me to participate to the work of the SD strategy committee led by Kim Warren. Different models were sent to me, and in particular the Richardson’s model but too a model written in Sysdea, Kim’s software. Kim did not open his software freely to me so that I could study his model, expecting me to pay the fee to be able to use his software; something that I did not do. I then never studied his model. Not wanting to make another field growth model and not being able to do this seriously, I built a very small Vensim model readable with the free Vensim PLE or the free Vensim reader, about the growth of a consultancy. Kim told me that he did not use Vensim and that he would give the model to you. Did you ever have the model? Now, I think that Kim thinks that I am an idiot to believe that after more than 20 years in the field, he cannot study a very small model written in Vensim using only one view and not subscripted, the software that is the most used by the SD community? He just did not want to hear about Vensim a software competitor. I must say too that building that small model took me more than a week. I studied during the year the Richardson’s model and sent a small report about its many peculiarities (bugs etc…). the answer was ‘we are always happy to have member’s comments’ sent by yourself. And you are looking for volunteers?
I can understand that you are missing volunteers if they are treated like that.
I must add that there is a vacancy in the SD strategy committee since the beginning of the year. I am not particularly interested by being in the strategy committee, and will not take indirect profit from it (I am a business man not dealing with SD), but Kim was certainly not interested by somebody using the Vensim software and daring to criticize one of the ‘hall of fame’ member’s model. Being in the committee would too be annoying for the other sleeping members, preferring to stay asleep.
I am sorry, Len, but you are looking for gentle and obedient volunteers, and I am not gentle and obedient.
Best regards.
JJ
 Subject : Re:SD software characteristics.. 05/28/2020 06:21:56 AM 
Guido W. Reichert
Posts: 34
Location: 
Dear all,

A lot of work has gone into writing the "Business Simulation Library (BSL)" for Modelica using the Wolfram System Modeler. It will now be published within the next 1-2 weeks (some documentation and testing still to be done) via the System Modeler Store at now cost. I will afterwards set up a release for OpenModelica on GitHub, so that the open source idea of collaborative development can come to full bloom.

For those who have become interested in open source, hierarchical, object-oriented System Dynamics modeling using Modelica, here is a short video (18 min) from a recent Wolfram Virtual Conference event introducing System Dynamics and the new library:

Using the Business Simulation Library (BSL)

Cheers,

Guido
 Subject : Re:SD software characteristics.. 06/13/2020 06:35:29 AM 
Jean-Jacques Lauble
Posts: 55
Location: 
Hi Guido

I looked at the Modelica language definition (rather elaborate) and found a last chapter about units generally physical and mentionning user defined units without futher explanations. Is it possible like in Vensim to define units of diemensions and the language verifying the compatibility of the équations with them?

JJ
 Subject : Re:SD software characteristics.. 06/13/2020 08:15:10 AM 
Guido W. Reichert
Posts: 34
Location: 
Hi JJ,

The short answer is: Yes, you can—it depends on what is implemented in the tool you are using as can be seen here. ;-)

But let me elaborate a bit for clarity. Modelica is a modeling language for cyber-physical systems. While in System Dynamics we are pretty much exclusively coming from a causal, "cybernetic" perspective that essentially looks at signal flows, the distinguishing feature of Modelica (as compared to something like Simulink) is the use of what is called acausal connectors to allow for more intuitive representations of physical systems, where the direction of flow is not clear beforehand and one would like to be able to model components to be as reusable as possible (e.g. have a motor component work as a generator as well).

In short, the difficulties of handling physical systems in an intelligent way necessitates the use of DAE solvers (e.g. DASSL), real-time capabilities and very flexible handling of physical units, as you want to allow someone to enter say an angle in radians or in degrees—while still making sure of getting an angle.

A lot of those capabilities are pretty much "wasted" on us for building System Dynamics models, but it is always better to simply neglect features than to find out about a lack of features down the road.

In software like Vensim we need to be "literal" with our units and while we may define "day" to be equivalent to "days" we do not have an equivalent for what is called displayUnit in Modelica. A good example is time. To a physicist, the SIunit for time is second and so to make different models work with each other without risking unit errors, we would like to internally use standardized units like SIunits whenever possible, while when entering inputs and displaying units for output, we would like to simply enter/display the unit we want.

Modelica allows for just that, it will internally use standardized physical units and then simply use conversion tables to allow you to enter or display values in derived units like minutes, hours, days etc.

This way of treating units of time is very elegant and relieves us of worrying about what unit of time we were using—SIunits of course. (Same principle would work for the Radians vs. Degrees example)

Now, a lot of times, we are talking about counting units: People, trucks, monetary units, widgets etc. How to deal with those?

In my library, I decided to distinguish three tpyes of basic units:
  1. 1 (Dmnl)
  2. 1/s (Rates)
  3. 1 s (Time)

I then have a string calles baseUnit that essentially tells us what unit should replace the "1" in any of the principle type of unit given above. This allows me to use the convenient conversion tables for times and rates, while at the same time being flexible enough to represent any unit there is.

To have automatic unit checking as in Vensim I will have to write up some routine in an external tool like Mathematica—as there is currently no support for unit checking in SystemModeler. But on the other hand, the task of checking units in an object-oriented, hierarchical modeling environment looks quite different than what is typically done in SD software.

Think of Molecules of Structure: Once you have checked a component to be valid for say "widgets" it will also be valid for "trucks" or "people". Since you are validating component by component, the task of checking units is broken down in very digestible parts.

For a component all you have to check is the units of its inputs and then you can be assured that the output will have the appropriate units again and again.

To me, having unit testing, e.g. partial model testing like RealityChecks in Vensim has become much more important. I want to be able to check each component of a model (partial model) very thoroughly by a battery of tests that can be run automatically. That works really great using Modelica and Mathematica's Testing Framework for example. I am not seeing RealityChecks being used a lot.

Kind regards,
Guido
 Subject : Re:Re:SD software characteristics.. 06/13/2020 09:01:20 AM 
Jean-Jacques Lauble
Posts: 55
Location: 
Hi Guido

Thank you for your quick answer. It seems that to have the equivalent unit system in Modelica needs some additionnal work. In Vensim is it very practical and every time saved is iportant especially in a time consuming field like simulation. I think that to prove the advantages of Modelica you should build a model easy to understand and that proves without contestation the superiority of Modelica that is currently presented as a too for 'PHYSICAL' systems.

Subsidiary question: is Modelica used for social problems too?

Because even if the mathematics work oorrectly, the social problems are very different from the physical ones and exchanging with people working on physical problems (probably much better in mathematics than SD people and especially ST ones) does not have any interest.

Regards.

JJ
 Subject : Re:SD software characteristics.. 06/13/2020 10:50:33 AM 
Guido W. Reichert
Posts: 34
Location: 
Hi JJ,

I am rather disillusioned with regard to convincing the community of the utility and Max Planck's famous quote comes to my mind:
Quote:
A new scientific truth does not generally triumph by persuading its opponents and getting them to admit their errors, but rather by its opponents gradually dying out and giving way to a new generation that is raised on it.

Certainly, we are not talking about a new scientific truth, but simply some technical capabilities. I would also argue, that Modelica as an open source standard with freely available tools must not be superior but simply as good as what we have right now.

In his 2018 thesis about designing modules for supply chain management, Aly Elmasry concluded with this call:
Quote:
As such, I recommend that system dynamics software would offer a tool in which users could develop a module, specify its inputs and outputs, and the software would automatically show the input and output nodes, so that the user could simply connect a module’s output node to another module’s input node. Furthermore, it is more practical for the user to right click on the module and enter all its parameters in one go, instead of entering the module and specifying each parameter separately. Lastly, the modules should be arranged in a hierarchical class library, such that when a user changes a module class in the library, all the modules “under” this class change accordingly. This is extremely efficient; when a modeller identifies a structural error, he/she can change the module in the library and the software automatically changes all the modules used under this class.

Well, that is essentially how Modelica has been working since 1997/98. Nicely ignored. ;-)

Your challenge to have me demonstrate, how a physical modeling language can be readily applied to social systems modeling appears to me like a Treppenwitz (staircase joke): System Dynamics is rather completely based upon continuous time signal flow modeling in electrical engineering being applied to social systems by a great pioneer of engineering, Jay W. Forrester.

And now, you seriously ask me, how a modeling language that is physical, e.g. that can model both signal flow and acausal (potential + flow) material flow connections can be used for such tasks? So having information flows is supposed to be superior in representing material flows (e.g. people, goods, money...)?

Using fixed step solution methods for ODE is superior to having both, fixed step and variable solvers that can also handle regular algebraic equations? (e.g. you can set up the system in equilibrium by introducing the condition der(x) = 0)

I'll rest my case.

Cheers,
Guido
Last Edited On: 06/13/2020 10:54:13 AM By Guido W. Reichert
 Subject : Re:Re:SD software characteristics.. 06/13/2020 01:08:26 PM 
Jean-Jacques Lauble
Posts: 55
Location: 
Hi Guido

How long did it take to have at least one answer to your message?

Nobody from the SD community (if it exists) is interested in Modelica.
I hate to dream. Let us work towards more achievable objective.
Nobody obliges you not to work with Modelica if you like it and it suits maybe very well your needs.

But forget changing things in a field that is subject to a big inertia gained with its years of existence.

It started with models about things that can be changed (Industrial Dynamics) went into problems about things that should be changed (Urban and World dynamics) and stayed there.

Regards.
JJ
 Subject : Re:Re:SD software characteristics.. 06/13/2020 02:19:23 PM 
Mr. Leonard Malczynski
Posts: 50
Location: 
Bonjour Jean-Jaques,

I was wondering if you meant that there has been no progress in the methodology or no expansion of the problem domains to which SD has been applied in your last paragraph.

Maybe we should open a new topic for that discussion.

Best regards,
Len
 Subject : Re:Re:SD software characteristics.. 06/13/2020 02:35:47 PM 
Mr. Leonard Malczynski
Posts: 50
Location: 
Guido,

What Elmasry asked for is available in some SD software. SI units, reusable components, etc. I know Vensim is the predominant tool, there are others.

Getting someone to try something new whether is is food or software has always been difficult. There is some inertia and path dependency. Firms will tout their new features, flavor, ingredients, etc. Some may lower prices to induce customers to switch.

The one additional cost for software is switching costs that include learning time, searching time, and converting old work time. So sunk costs are not truly sunk if you have reusable model components.

I don't have an answer. I note that JJ has mentioned modelers not being domain experts and likewise, domain experts not being modelers. It seems to be that outside of business applications, new texts are trying to introduce domain experts to SD modeling and the Group Model Building approaches have been working hard to resolve that problem. Perhaps there is also the issue of applying SD at the wrong time to the wrong problem.

Regards,
Len
 Subject : Re:Re:SD software characteristics.. 06/14/2020 05:11:41 AM 
Jean-Jacques Lauble
Posts: 55
Location: 
Hi Len

I prefer not to start a hazy discussion. I estimate having been sufficiently clear so far. I prefer then not to add any more ‘comments’.

JJ
 Subject : Re:Re:SD software characteristics.. 06/29/2020 02:27:05 AM 
Mr. Bill Harris
Posts: 2
Location: 
There's another free simulator that I've found intriguing: GNU MCSim (https://www.gnu.org/software/mcsim/). I first encountered it in an idle search for simulators in GNU software about 15 years ago.

In my first try, I found it had attributes that matched my workflow nicely. I started by defining a simple (SIR? Bass? I no longer recall.) model to see how MCSim worked.

When I got the syntax right and the model compiled, I sat it aside and thought about the parameter values that might be appropriate, for defining in puts and perhaps parameters is a separate step. After reflecting, I decided to pick all combinations of the upper and lower limits of the few parameters plus the midpoint. I coded that and ran the model. Then I realized that was likely the first time I had ever done a factorial design for my first model run.

Now I had results, and I wanted to look at them. I was mostly doing visualizations in J or gnuplot at the time. Without thinking about it too much, I created a 3-D graph with axes for time, for a state, and for a corresponding flow. If you can spin that graph, you can in one plot see a behavior-over-time graph of either variable, a phase plane diagram, or a 3-D version of all three; see the last graph in the quick reference guide at the bottom of the GNU MCSim page for a simple example. I even tried stereograms (in J) and found at least one other person who found them intriguing!

I'm not claiming MCSim is better than any other arbitrary simulator. What I did like is the sequence of process focal points:

- At the start, focus on the model. Get the syntax and semantics right. Check units (manually--a potential weakness). Compile it, and set it aside.

- Then design the experiments you want to run. Design them all at once; it's easy to set up one simulation input file with multiple experiments.

- Then run the experiments--it's fast-- and analyze the data. Iterate as you wish in the exploration of results; if you designed the input file well, you've got lots you can explore, and the fact that you ran them all together makes it easy to compare results between experiments.

- If you need other experiments, it's easy to back up a step, change the input file, and produce new experimental data.

- If you discover you want to try a change to your model, back up one more step to edit the simulation model description and recompile it.

Other things I liked:

- As with some other simulators, MCSim uses text files, so version control is easy.

- With modern computers, most models run quickly, but MCSim models seem to run really quickly. With the above workflow, I run models less often, as well.

- It has automatic integrators, so I didn't have to think much about time step--perhaps just whether I was dealing with stiff equations or not.

- The code looks enough like Dynamo or Vensim so that it's not hard to decipher, even if you're new to MCSim. I find it easier to write MCSim code than to write Vensim code, though--probably just my lack of experience writing Vensim code without using the GUI.

- Its primary field is PBPK, not system dynamics, and so its existence and survival isn't dependent upon adoption by the system dynamics community.

- Arrays came in the cheapest version. :-)

- Because MCSim has inline capability, one can define tabular nonlinearities using the GSL. If you care, that gives an even broader range of options for interpolating between points than I think is customary. See the reference guide on the MCSim page for an example.

- I could pick the tool for each phase of the work. In particular, I could create model definition and simulation input files in my preferred editor environment (for me, Emacs), and I could use whatever collection of visualization tools I found useful--J, R, gnuplot, ....

- I could use MCSim's MCMC sampler to create posterior distributions of parameter values given the (possibly hierarchical) model and data.

- The ability to optimize the selection of data collection times to minimize posterior parameter estimation uncertainty is intriguing, although I haven't really used that yet.

There's more; see the manual and the examples that come with the system.

I'm not saying that MCSim is necessarily better than other tools overall or even by individual feature; I'm simply saying that these are its features that attracted me at the time.

Most probably won't care about MCSim, but I think it's well worth considering.

Bill
 
<< first < Prev 1 2 Next > last >>
# of Topics per Page