To the System Dynamics Community.
As somewhat of an outsider, I guess I dont appreciate why there is so much
concern over the question of discrete vs. continuous modeling techniques, and
limiting the techniques that can be called SD.
>From my background in Systems Engineering, the process I am familiar with is (1)
define the problem, (2) pick a tool that will efficiently do the job and can be
trusted. CLDs, stock-and-flow, differential or difference equations, various
graphical and numerical methods, etc. are just some of the tools in the tool
box. Getting a reliable answer, within time and resource limits, that provids
insight and/or convinces a client, is all that is important.
Defining SD in terms of a limited tool set doesnt seem particularly productive.
Hesitantly,
Bill Cutler
4114 Park Blvd.
Palo Alto, CA 94306
415-493-8715
72734.3452@compuserve.com
Discrete vs. Continuous and Defn of SD
-
"William H. Cutler" <72734.3452@
- Junior Member
- Posts: 11
- Joined: Fri Mar 29, 2002 3:39 am
Discrete vs. Continuous and Defn of SD
Bill Cutler in SD0184 writes
"As somewhat of an outsider, I guess I dont appreciate why there is so
much concern over the question of discrete vs. continuous modeling
techniques, and limiting the techniques that can be called SD."
I dont think people want to limit techniques.
I do think a concern has arisen because
1) Most people in SD are only familiar with continuous-time modeling
2) People are wondering if in fact continuous-time modeling is the best
tool, or if they are missing something
3) If continuous-time modeling is the best too, why.
Finally, I think that continuous-time modeling is USUALLY the BEST tool.
Discrete-time modeling seems to be close to being dominated (in a pareto
sense) by continuous time modeling (see John Stermans posting). That
is, discrete-time modeling probably doesnt do much of anything better
than continuous-time, and it does a lot of things worse.
Discrete event modeling is more subtle. However, I think it is not as
good for representing feedback as continuous time. The reasons:
a) In many cases, one would like to make the feedback go through the
random generating processes. For example, bank customers arrive
according to some stochastic process, but wed like the mean of that
process to change as the lines get longer. You rarely see this sort of
thing in discrete-event modeling, though perhaps this is not a fault of
the tool, but the tool users.
b) More importantly: Continuous-time simulations aggregate in a way
that makes it MUCH easier to think about the feedback. Two examples:
It is common to have feedback from an agregated inventory of diverse
items (SKUs) to the shipment rate; as the inventory is depleted the
shipment rate declines due to the increasing probability of stock outs
(Jack Homer has a great, old, unpublished, undated memo on this). In an
SD model, nothing could be simpler. In a descrete event model, however,
there really isnt feedback from the inventory -- the inventory may not
even exist. Instead we might track individual items (SKUs). We ship if
the item is there and we dont if it isnt. Selling an item does not
really feedback to the shipment rate at all. Maybe if we squint, wed
say if we sell the LAST item, there is a feedback on shipments of that
kind of item; but there is not feedback for selling anything other than
the last item.
Another example: In SD global modeling, its common to have feedback
from pollution to the aborption capability of the environment. However,
the chemistry is quite complex. The release of one pollutant may
interupt the aborption of a different pollutant. Only if the second
pollutant through some chain of causality actually prevents the
absorption of the first, is there really feedback. By aggregating
pollutants together, however, we "create" the feedback and have a
compact and powerful way of thinking about how pollution can rise.
The first example is a clear cut case where the aggregation common in
continuous time makes it easier to see and think about the feedback.
The second example is trickier. Its likely that the "complicated"
feedback actually exists and that the simpler aggregated feedback
therefore also really exists. HOwever, there may be some situations
where feedback does not exist without aggregating. In this case, I
think that it is still cricket to think in feedback terms; because its
useful. But, perhaps its open to question. So:
1) Are there really any cases where feedback is a product of
aggregation and does not exist on a disagregated level?
2) In these cases (if there are any) is it good to still represent
feedback?
Regards,
Jim Hines
jimhines@interserv.com
"As somewhat of an outsider, I guess I dont appreciate why there is so
much concern over the question of discrete vs. continuous modeling
techniques, and limiting the techniques that can be called SD."
I dont think people want to limit techniques.
I do think a concern has arisen because
1) Most people in SD are only familiar with continuous-time modeling
2) People are wondering if in fact continuous-time modeling is the best
tool, or if they are missing something
3) If continuous-time modeling is the best too, why.
Finally, I think that continuous-time modeling is USUALLY the BEST tool.
Discrete-time modeling seems to be close to being dominated (in a pareto
sense) by continuous time modeling (see John Stermans posting). That
is, discrete-time modeling probably doesnt do much of anything better
than continuous-time, and it does a lot of things worse.
Discrete event modeling is more subtle. However, I think it is not as
good for representing feedback as continuous time. The reasons:
a) In many cases, one would like to make the feedback go through the
random generating processes. For example, bank customers arrive
according to some stochastic process, but wed like the mean of that
process to change as the lines get longer. You rarely see this sort of
thing in discrete-event modeling, though perhaps this is not a fault of
the tool, but the tool users.
b) More importantly: Continuous-time simulations aggregate in a way
that makes it MUCH easier to think about the feedback. Two examples:
It is common to have feedback from an agregated inventory of diverse
items (SKUs) to the shipment rate; as the inventory is depleted the
shipment rate declines due to the increasing probability of stock outs
(Jack Homer has a great, old, unpublished, undated memo on this). In an
SD model, nothing could be simpler. In a descrete event model, however,
there really isnt feedback from the inventory -- the inventory may not
even exist. Instead we might track individual items (SKUs). We ship if
the item is there and we dont if it isnt. Selling an item does not
really feedback to the shipment rate at all. Maybe if we squint, wed
say if we sell the LAST item, there is a feedback on shipments of that
kind of item; but there is not feedback for selling anything other than
the last item.
Another example: In SD global modeling, its common to have feedback
from pollution to the aborption capability of the environment. However,
the chemistry is quite complex. The release of one pollutant may
interupt the aborption of a different pollutant. Only if the second
pollutant through some chain of causality actually prevents the
absorption of the first, is there really feedback. By aggregating
pollutants together, however, we "create" the feedback and have a
compact and powerful way of thinking about how pollution can rise.
The first example is a clear cut case where the aggregation common in
continuous time makes it easier to see and think about the feedback.
The second example is trickier. Its likely that the "complicated"
feedback actually exists and that the simpler aggregated feedback
therefore also really exists. HOwever, there may be some situations
where feedback does not exist without aggregating. In this case, I
think that it is still cricket to think in feedback terms; because its
useful. But, perhaps its open to question. So:
1) Are there really any cases where feedback is a product of
aggregation and does not exist on a disagregated level?
2) In these cases (if there are any) is it good to still represent
feedback?
Regards,
Jim Hines
jimhines@interserv.com