Community Forum : General Discussion Forum
Welcome Guest   
 
 Subject : A System Dynamics Glossary.. 11/16/2019 10:21:33 AM 
Guido W. Reichert
Posts: 30
Location
Just now via an "early view" for the SDR an updated version of David N. Fords excellent "SD gloassary" appeared in the section "Notes and Insights" (source).

Since this of concern to all of us and an excellent help in communicating about what we do as SD-practioners, I would like to open this thread in order to discuss, clarify, improve, and ammend the excellent work Dr. Ford has begun.

Let me start we my own "nitpicks":

auxiliary (convertor) variables
That should, of course, be "converter" variables or in short: converters.

connector
That definition imo is unfortunate, as it separates System Dynamics modeling from object-oriented modeling (e.g. a model as a separate entity). Talking about a partial model (maybe a generic building block) might be improved, when we talk about a model and its interfaces (i.e. connectors as plugs) and differentiate this from the connections, e.g. the coupling of different interfaces.

If we merely talk about connectors as links to variables, then we need to introduce shadow variables to connect partial model 1 with partial model 2. What will we call a model's interfaces in greater modeling endeavors, when different models from different modelers are joined?

conserved flow
Why are conserved flows only mentioned with regard to transporting material? Flows between stocks never lose anything, neither information nor material is lost.

In my opinion, the better distinction to make would be between material stocks and information levels, as it would then be clear, that flows between material stocks will never transport negative amounts. Regarding flows between material stocks, negativity is purely an indication of the direction of flow, there cannot be any amiguity for a negative flow where it is coming from and where it is going to.

Not so for information flows, as adding (-4) is trivially equivalent to subtracting (+4). (Note, that the explanation for information delay talks about non-conserved variables, which imo is a case in point.)

Edit: J. Forrester in Industrial Dynamics noted (cf. Section 6.2):
Quote:
Therefore, the levels within one network must all have the same kind of content. Inflows and outflows connecting to a level must transport the same kind of items that are stored in the level.

Forrester goes on to describe six elementary networks (e.g. materials, orders, money, personnel, capital equipment, and information). We can aggregate these distinctions into stocks/flows that can store/transport negative quantities (as well as positive ones) and those stocks/flows that can only store/transport positive quantities. Would we distinguish material stocks and information levels, we could immediately spot structural errors in a model without having to inspect any units at all. We would then also have a bridge to models of cyber-physical-control, that quite explicitly make that distinction.

information delay
Delay of perception can also be modeled as a fixed delay with variable delay time; such a delay will not necessarily show gradual delay. Shouldn't we explicitly mention a fixed information delay as opposed to the pipeline delay?

parameters
~ are not necessarily "factors" in a mathematical sense, so I would avoid that term. They are "variables" that may be unknown and can only change between separate model runs. I personally like the distinction made in Modelica between constants and parameters (cf. variability of variables).

simulation
While systems thinking is explained at comparatively great length, we are not sufficiently informed about the nature of a "formal computer model" (graphical representations using computers imo can also be quite formal); also (simulation) run is not to be found anywhere. I would suggest to add "model" (aka computer model) as a separate and important entry; currently we only find → mental model as en entry of its own.

While I understand, that we should not go into Mathematics too deeply with regard to a glossary, we cannot avoid doing so. After all, we talk about "variables", "equations" (→ dimensional analysis), "equilibrium", "functions"... I would thus add some information about the fact, that generating the behavior of a system represented by a model of stocks and flows, has to do with numerically solving a system at least of ODE (possibly also of DAE). We may then also understand solution interval (see next entry).

solution interval
My understanding of solution interval is, that it describes an interval for which a solution (a) exists and (b) is known. Equating time step, delta time, computation interval with solution interval contradicts that understanding, as the time step quite often describes a gap, e.g. an interval for which we do not explicitly have a solution (i.e. the value for all states at all points of time).

I would suggest to have solution interval be equivalent to the simulation horizon (e.g. the interval [startTime, stopTime] for which we numerically solve the equations given by our model) and clearly distinguish it from the computation interval, time step and delta time.

table function
What is a "numeric table version of a graphical function"? To me a "table function" is short for an interpolating function based upon tabular data (e.g. ( function-value-tuples ) that can be piecewise linear or non-linear in the case of higher order interpolation methods and splines.

Here are some suggestions for keywords that may/should be included:

n-th order delay or higher order delay, hysteresis / path dependeny, stiffness (stiff system), ringing or chattering, distributed delay, noise (pink ~, white ~), nonlinear system (or model), linear system (or model, e.g. LTI-system), viability, carrying capacity
Last Edited On: 11/18/2019 11:38:40 AM By Guido W. Reichert
 Subject : Re:A System Dynamics Glossary.. 11/19/2019 02:06:46 AM 
Guido W. Reichert
Posts: 30
Location
Why doesn’t the SDS put up something so relevant and important as a System Dynamics Glossar in a Git-repository and enable true, easy, and reliable collaboration?

I would strongly suggest it - we are moving into 2020. :-)

Regards,
Guido

PS: That would also make a lot of sense for models, as they become transparent and errors can easily be raised as issues. Just take a look at GitHub.
 Subject : Re:A System Dynamics Glossary.. 11/20/2019 06:54:54 AM 
Jean-Jacques Lauble
Posts: 42
Location
Hi Guido

About your glossary, as a client I would prefer to work with a consultant who knows well my problem and works seriously and with Fortran than someone else working with a ‘glossary’ and sophisticated tools but with no experience of the problem and not working very seriously.

SD as a theoretical field has already a lot of names, methods, rules to be respected (in one paper an academic listed more than 300 points to be respected if one wanted to be a ‘good’ modeler).

Interesting for a teacher: learn with me the 300 points and you will be a good modeler and during a long time I will have one more student in my class room.

In one of my discussion with a known professor that man, ingenuously, confessed that his students never found a job where they could apply what he had taught them! But he still accepted his month salary and did not bother about the time and eventually money his students had lost!

Do you really think that if the profession publishes a common glossary (not evident taken the fact that so many people have different point of views), it will make the field more practically useful?
I do not.

Best
JJ
Last Edited On: 11/20/2019 07:06:24 AM By Jean-Jacques Lauble
 Subject : Re:A System Dynamics Glossary.. 11/20/2019 11:15:21 AM 
Guido W. Reichert
Posts: 30
Location
Hi JJ,

While I very much appreciate your critique, I believe, you should have taken a bit more time to really read what I posted about: The glossary I referred to is an updated version of the one, that can be found (here) on the SDS website.

The glossary is not mine, but David N. Ford's work (it certainly carries his copyright) and will be published in the SDR. Since I had some different views, I figured, that posting this publicly would be a good idea, and certainly I find that some common view on common terms / vocabulary is a good idea.

Certainly, one could argue, whether this is a) necessary or b) fruitful to practical work or c) even feasible at all. But, I believe, you should not squelch a little bud, because it is not yet a tree or an orchid.

If you do not believe in a glossary being helpful, why don't you simply abstain from its discussion? You could save yourself a lot of wasted time.

I remember seeing a wonderful documentation about Niklaus Wirth lately, who as a young engineer and pioneer in computer science found, that practitioners never cared for anything but Fortran to write fast applications. Where would we be, if people like him had just listened to the alleged problem owners and heeded their advice?

Have a nice and fruitful day.

Best regards,
Guido

PS: You seem to have read Schopenhauer's advice on "how to win an argument" very thoroughly:
Quote:
as a client I would prefer to work with a consultant who knows well my problem and works seriously and with Fortran than someone else working with a ‘glossary’ and sophisticated tools but with no experience of the problem and not working very seriously.

Please do acknowledge the possibility of someone, who is working with a glossary, sophisticated tools, a good understanding of the problem at hand, and who - to top it all - is working very seriously. It may make your choice a bit more difficult? ;-)
Last Edited On: 11/21/2019 06:46:51 AM By Guido W. Reichert
 Subject : Re:A System Dynamics Glossary.. 11/22/2019 05:19:41 AM 
Jean-Jacques Lauble
Posts: 42
Location
Hi Guido.

One must acknowledge that SD has not the place that it deserves in the OR/MS market. The reason is not the lack of serious people, good tools or knowledge of the problem. The reason is that the people are not the same. People who know the method and can be serious generally do not know the system and are not the decision-takers. The other problem is that to do a good SD study requires a lot of time from all the people concerned. From the modeler taking that time results in high fees or salary, that the other people (mainly decision takers) are not ready to pay. These people are not ready too, to spend enough of their own time to bring the necessary knowledge to the study. These two characteristics oblige the modeler to sell a product at a price acceptable by the market and acceptable in term of time spent from the client. But it generates low quality studies with low results. I verified that 10 years ago working with a world-renowned SD consultant charging a low price and producing a low-quality model, necessitating not much of my own time: a mediocre and superficial study.

This is to my opinion the real problem with SD. The solution to these difficulties is not in modifying the tools that are to my opinion largely good enough to do a good job, but to think about how the method is sold. In fact, the reason of low impact is endogenous: the way that the product is sold and produced and not in some market reasons. You will never change the market behaviour but you can change the product (even if it is very difficult due to the inertia and already long existence of the field).

Best
JJ
 
# of Topics per Page