Ventana software support forum

Posted: **Sat Oct 09, 2004 6:14 pm**

Tell me, how much discrete modelling have you done so far?

While working on business simulation models in order to deal with performance
measurement difficulties, I am getting more and more into discrete-flow
modelling using Powersim. I find this feature in Studio very useful.
In my opinion, there can exist discrete-flow areas within business models that
are more helpful than continuous ones. Consider logic systems in a firm such
as the whole accountancy. It would be simply wrong modelling e.g. payments or
depreciations in a continuous way. Moreover, it's harder to explain to
clients why we're doing things like that.
Nevertheless, there are the ""usual soft variable suspects"", where we have to
use continuous-flow structures like the information delay. Employee skill
level, motivation, and decision processes can be modelled easier in continuous
model-parts.
Don't get me wrong. I'm talking about single business models, not a whole
industry or economy, not a world climate model or any other model on a macro
level (no big numbers and only little need for average flows).
I wonder whether you got any experience with such a combination of both the
discrete and the continuous modelling. I'm hoping we can start off a
refreshing discussion.

thanks!

..........................

Paul Koch
paul.koch@email.de

Master programme in System Dynamics, Bergen

Posted: **Mon Oct 11, 2004 12:14 am**

Hello Paul

You are talking about a very interesting topic. Indeed the different
simulation approaches are better for different uses even within the same
system. And I have seen few papers talking about hybrid systems because
of this very same reason. You can make the discussion much more
significant if you summarize your observations of why discrete
simulation was specifically better than continuous. Eventually I expect
to have a set of rules that says where, why, and when a combination of
the two approach should be used.

Best regards

Magdy Helal
Industrial Engi & Management Systems Dept
University of Central Florida
4000 Central Florida Blvd
Orlando, Florida 32816
Phone 407 823 0017 OR 407 882 0285
Fax 407 823 3413
Cell 321 945 8982
e-mail: mhelal@mail.ucf.edu

Posted: **Wed Oct 13, 2004 8:16 pm**

Many people seem to believe that they must model the discreteness of
orders and payments because, at the micro-level, the transactions are
discrete. However, most policy issues deal with average overviews of
the micro level and can be more simply handled as continuous flows.
In the situation below, I assume that performance measures will
relate to overall performance and will not be computed and acted on
as individual transactions by management. Depreciation is much more
a continuous process than discrete; it occurs continuously, not just
at the end of the year when the books are posted.

In the early days of system dynamics, I presented a summer session
accounting model covering double-entry bookkeeping and the purchasing
of capital plant, payment, depreciation, and discard as continuous
stock-flow equations. A corporate financial vice-president in the
class, who was also teaching accounting at the university level,
observed that students would have much less difficulty understanding
the logic of accounting is it were taught in the continuous flow
approach with stock-flow diagrams.

--
Jay W. Forrester
From: ""Jay W. Forrester"" <jforestr@MIT.EDU>
Professor of Management
Sloan School
Massachusetts Institute of Technology
Room E60-156
Cambridge, MA 02139

Posted: **Tue Oct 19, 2004 8:06 am**

I am probably the person who is the most to ""blame"" for the introduction of
discrete flows in Powersim. Maybe I should try to cast some light on why
this was done?

In short, my conclusions are the following:

1) Typical SD models mainly use continuous stocks and flows.
2) Whenever you need to express discreteness in a model, discrete data types
and flows are advantageous.
3) If a SD modelling tool includes discrete data types, it needs to have
discrete flows (and stocks) as well, in order to be mathematically and
logically consistent.

In the following I will argue for providing discrete data types and discrete
flows in SD technology from a technology viewpoint and from a functionality
viewpoint. From the technical side, we introduced data types (other than
real) in order to avoid the problems that arise when using real number to
represent variables that are non-real in nature, such as a logical (Boolean)
conditions or integer values.

An advantage of having an integer and a logical data type, is that models
that make use of variables of a ""logical nature"" or an ""integer nature""
become more readable. This relates both to model equations and to model
input/output. Furthermore, the extra data types allow for better quality
assurance. Now the system can detect a family of modelling errors that
relate to violations of operations on data types. As an example, it does not
make sense to add TRUE and 5 together. Studio detects this error. Systems
with only real data types cannot do so.

In SD the only way to alter a state (stock) is through a flow. Discrete
types cannot be expressed using continuous flows, as the flow itself
involves multiplication by dt (a real number). Integer*dt produces a real.
Logical*dt is simply impossible. What should it mean? Half true?

Hence, there is a need for discrete flows in order to make the modelling
language internally consistent. In addition, we needed to invent the meaning
of logical inflow and logical outflow. (Thanks to Arne Kråkenes who worked
with me on this). With the discrete flows in place, it becomes possible to
""switch"" logical stocks on and off, and models can add/subtract integers
correctly to/from stocks.

Also real flows sometimes need to be treated as transactions, i.e.,
discretely. Traditional SD uses the PULSE function to implement transaction
flows. (Some people divide the flows by dt to achieve the same. Others rely
on setting dt=1; -- a terrible practice). The mentioned practices are
workarounds, with several non-disputable drawbacks, as described in Powersim
Studio's help file. (The presence of PULSE itself indicates that flows with
""discrete nature"" are indeed useful in some SD models. The PULSE function
has been around since the first SD languages).

Now, a few words from the functionality perspective. It is my experience,
for what it is worth, that discrete flows are rarely used in high-level,
conceptual models with a long time horizon. However, SD technology also is
making its way into more low-level problem areas, where accurate
computations of discrete phenomena are required. Without the use of discrete
flows, discreteness must be ""faked"" using workarounds (pulse, divide by dt,
etc.). When discreteness is expressed using continuous equations, the
equations become unnecessarily large, hard to write, difficult to validate,
hard to understand, and almost impossible to explain to non-SD people. (All
bad things.)

So what is best: discrete or continuous? None of the two. Use the right
formulation for the problem at hand. See also J.W.Forrester: Industrial
Dynamics, §5.5, p.65-66.

Magne Myrtveit
former Powersim, now Dynaplan
www.dynaplan.no
magne@myrtveit.com

Posted: **Wed Oct 20, 2004 6:10 pm**

Dear Magne;
There is one part in your message that I do not understand. (Below).
Although you are technically solving an integer flow and stock problem,
WHY would one use such a stock? A stock means, your 'logical flows'
would accumulate. You correctly state that a non integer 'true' is
meaningless. But then again, what does it mean to have '5 trues' in the
stock? 'Extremely' true? Based on your description, I do not think
'logical flows integrating in a stock' properly solves your problem.
(How can a 'logical stock switch on and off"", as it integrates inflows
and outflows?)

My much simpler solution would be to use non-stock (auxiliary) integer
variables to represent logical switches.
all the best from Istanbul,

Yaman Barlas
From: yaman barlas <ybarlas@boun.edu.tr>

Magne Myrtveit wrote:

>...
>In SD the only way to alter a state (stock) is through a flow. Discrete
>types cannot be expressed using continuous flows, as the flow itself
>involves multiplication by dt (a real number). Integer*dt produces a real.
>Logical*dt is simply impossible. What should it mean? Half true?
>
>Hence, there is a need for discrete flows in order to make the modelling
>language internally consistent. In addition, we needed to invent the meaning of logical inflow and logical outflow. (Thanks to Arne Kr?kenes who worked with me on this). With the discrete flows in place, it becomes possible to ""switch"" logical stocks on and off, and models can add/subtract integers correctly to/from stocks.
>
>
>
>

----

Posted: **Mon Oct 25, 2004 8:12 am**

Hello Magne;
I now understand what it is you try to do and why you would need a
stock. Thanks for detailed explanation. You are right, you do need a
stock in this case.
Having said this, let me add that I personally do not think a 'special'
stock-flow definition and technology is needed to achieve it. For
instance, I would do it by:
thermostate = integral(switchon-swotchoff)
switchon = 1 if flow temperature < lowerlimit and thermostate=0
switchoff = 1 if flow temperature > upperlimit and thermostate?0
lowerlimit = 18°C
upperlimit = 24°C
temperature is the room temp state...
In the above structure, the stock would always be an integer is the
system is discrete (DT=1). If the system were continuous, the stock
would move between 0 and 'some' non-zero value (constant). To me, this
is enough -causally and operationally. I think this is how thermostat
switch operates. (on and off does not have to be 1 and 0; it can be
non-zero and 0). But if for some reason, we wanted the stock to be 0 or
1, then all we need to do is to revise as:
switchon = 1/DT ...
switchoff = 1/DT...

All else would remain the same. The above structure may be one answer to
your question. (There can be alternative ones, using effect
formulations, etc).
So, I think it is a realistic and nice problem and I thank you for the
attention. Your solution is good, but I guess I am a 'minimalist' when
it comes to a specialized modeling jargon and technologies - unless they
are absolutely needed. I get the feeling that the readability and
openness of the model may be inversely proportional to the variety of
special variables and equation types we use.
all the best
Yaman Barlas
From: yaman barlas <ybarlas@boun.edu.tr>

[ also the earlier reply that did not make it to the list ]

Magne Myrtveit wrote:

>...
>1) sometimes it is necessary to record logical states in models
>2) logical states must be represented as stocks (the only SD variables with
>""memory"")
>3) the dynamic characteristics of logical stocks should be defined using
>logical operators only (not/and/or).
>4) logical stocks and flows are useful in many situations as they enhance
>readability and facilitate quality assurance
>
>...
>
>Here is
>an example: The current on/off state of a thermostat can be represented as a
>logical value. When the temperature gets below a lower limit, the thermostat
>is switched ""on"". When the temperature gets above an upper limit, the
>thermostat is switched ""off"". Between the two limits the thermostat keeps
>its current state. This logic is possible, but not easy, to express using
>the solution you suggest (using an integer auxiliary). It is very easy to
>express using logical stocks and flows, however. Here is how:
>
> (1) thermostat = stock false inflow switchon outflow switchoff
> (2) switchon = flow temperature < lowerlimit
> (3) switchoff = flow temperature > upperlimit
> (4) lowerlimit = 18°C
> (5) upperlimit = 24°C
> (6) temperature = ...
>
>Equation (1) defines a stock (thermostat), and initializes it to false
>(off). The stock has one logical infow (switchon) and one logical outflow
>(switchoff). Equation (2) defines the inflow, which is true whenever the
>temperature is below the lower limit. Equation (3) defines the outflow,
>which is true whenever the temperature is above the upper limit.
>Equations 4 and 5 define the limits (in Celcius). I did not write the
>equation for the temperature (6).
>
>The above model fragment shouldn't be too hard to understand, but how does
>it work? The answer depends on the software interprets logical inflow and
>logical outflow. We need to make a definition that makes sense from a
>conceptual (pragmatic) point of view, and that obeys the laws of formal
>logic. Here is what we have come up with (t=time):
>
> thermostat(t+dt) = (thermostat(t) and (not switchoff(t))) or
>switchon(t)
>
>In abstract terms, we get this (assuming normal precedence rules for
>not/and/or):
>
> (7) stock(t+dt) = stock(t) and not outflows(t) or inflows(t)
>
>Based on equation (7) we can deduce the following dynamic characteristics of
>logical stocks:
>
> (8) A true inflow will switch the stock on (if it is not already
>on).
> (9) A true outflow will switch the stock off (if it is not already
>off, and if all inflows are false).
> (10) A false inflow will not alter the value of the stock.
> (11) A false outflow will not alter the value of the stock.
> (12) A true flow into a true stock does not make the stock ""two
>times true""; it just leaves the stock in its true state. (true or true =
>true)
> (13) A true flow out of a false stock does not make the stock ""two
>times false""; it just leaves the stock in its false state. (false and not
>false = false)
>
>
>
>

Posted: **Thu Nov 04, 2004 5:48 pm**

Dear Magne;
I see your points and agree that integer and/or logical variables are
sometimes needed for better, more compact formulations.
I think this little debate is about 'degree', not 'kind'. So although I
have no problem with your arguments in general, I am also adding the
following caution: In cases where one can do what she wants with the
basic variables, tools and formulas, these 'standard' tools must be
preferrred. One must be careful not to resort to new macros, variable
types, to new lingo, to new built ins, etc, for every small variation
in dynamic formulations. One typical weakness I observe in novice
modelers: They tend to mistify and exaggerate the role of software and
its specialized tools. This exaggeration puts a harmful 'distance'
between the real world that they are modeling and their equations that
they write. They seem to assume that the software can automatically
build valid models. My rule: A model that can not be -in principle-
built by pencil and pen is a 'risky' model.
Having said this, I of course welcome any new software/features that
facilitate the translation from our 'mental-pencil-paper domain' to the
computer code.
all the best

Yaman
From: yaman barlas <ybarlas@boun.edu.tr>

---------------------------------------------------------------------------
Yaman Barlas, Ph.D.
Professor, Industrial Engineering Dept.
Bogazici University,
34342 Bebek, Istanbul, TURKEY
Fax. +90-212-265 1800. Tel. +90-212-359 7073
http://www.ie.boun.edu.tr/~barlas
SESDYN Group: http://www.ie.boun.edu.tr/labs/sesdyn/
-----------------------------------------------------------------------------

Posted: **Sat Nov 06, 2004 10:50 pm**

[Host's note - this posting is the one to which Yaman already replied]

Dear Yaman (and Mohammad),

Thanks for your model, Yaman. I don't think there is a ""right"" or ""wrong""
here; there are benefits to having a ""minimalist"" language definition (with
only one data type: real), and there are advantages to having more data
types, such as: integer, logical, complex numbers, text, and user defined
lists (sometimes called enumerations). Below I argue that data types can:

- make model structure smaller and more readable
- make model output more readable
- make models independent on particular choice of simulation settings (DT,
order)
- make models more robust (decreased risk of errors due to inaccurate
representation of real numbers)

Your ""real"" version of the thermostat model is ""minimal"" from a data type
perspective (it uses only real numbers), but it is not minimal from a model
complexity perspective: It uses 50% more information links (6 versus 4
links), and each flow equation is 400% more complex (5 versus 1 function)
than in my ""logical"" version. As we all know, structural complexity is one
of the main obstacles when it comes to readability, quality assurance, and
maintainability of models. My claim is:

1) Using real numbers to represent logical stocks can increase structural
complexity significantly.

Divide by DT is used to transfer a quantity ""in one time step"". Conceptually
we deal with an event (or transaction or discrete flow) when this happends.
Dividing by DT is mathematically nonsense since this is essentially division
by zero. However, modellers tend to rely on the assumption that SD
technology implements numerical integration by adding netflows*DT to stocks.
In general, it is bad modelling practice to rely on a particular
implementation or setting in the software. In our case, the assumption about
how flows are integrated only holds if Euler's integration method is used by
the software. If a higher-order integration method is used, the result will
not be correct, even if you divide your flow by DT. The result of adding a
flow of 1/DT to an empty stock is 1 with 1st order, 0.33 with 2nd, 0.67 with
3rd order, and 0.5 with 4th order integration. From this I conclude that:

2) Implementing discrete flows using Division by DT does not produce correct
results, unless you restrict yourself to Euler's integration algorithm.

In the thermostat model it is not important to have 0 and 1 in the
thermostat stock, so the above observation is not critical (as you point out
yourself, Yaman). Even in this case we must divide our thermostat flows by
DT in order to achieve unit of measurement consistency between the
thermostat stock and its attached flows. A flow that is divided by DT cannot
be interpreted correctly by the user (for example in a table output from the
simulation), unless the flow is multiplied by DT first. In order to save
time and reduce structural complexity (extra variables), modellers get
tempted to set DT=1 in this situation. Fixing DT to 1.0 can lead to serious
integration errors; the model can even produce wrong qualitative results
(e.g., diverging behaviour in a stable system). This leads to the third
conclusion:

3) Implementing discrete flows using Division by DT leads to one of the
following problems (depending which approach the modeller takes): a)
increased structural complexity, b) risk of wrong simulation results due to
bad choice of DT, or c) incomprehensive value output for flows.

As a final remark, the flows in your suggested thermostat model compare the
value of the thermostat stock with zero. Comparing real values for equality
on a digital computer is quite dangerous, as floating point numbers are not
exact representations. Again, chances are that your model will work only if
you set the software to use 1st order integration, and even then you can
never be sure that it will work! This too can be fixed by adding more
structure, but that would increase the complexity of your solution even
more. When a discrete data type is used, this problem does not exist.

4) Representing discrete values using real numbers, can lead to subtle
errors that stem from the way real numbers are implemented on digital
computers.

In summary, adding more richness to the modelling language can lead to more
concise and robust models. I am a ""minimalist"" when it comes to models
(""smaller is better""), but not so much when it comes to the palette of
functions provided by the software, especially when these new features can
help me create smaller and more elegant models.

Kind regards Magne
From: Magne Myrtveit [mailto:magne@myrtveit.com]

Ventana software support forum

Discrete-flow modelling for business simulation

Discrete-flow modelling for business simulation

Discrete-flow modelling for business simulation

Discrete-flow modelling for business simulation

Discrete-flow modelling for business simulation

Discrete-flow modelling for business simulation

Discrete-flow modelling for business simulation

Discrete-flow modelling for business simulation

Discrete-flow modelling for business simulation