discrete vs. continuous simulation

[CrbnBlu@aol.com]

Just wanted to provide an update indicating that the response to the question
regarding how to determine when to do discrete rather than continuous
simulations had a rather underwheming response.

Maybe it just wasnt a question provoking much thought. As such, there wont
be a forthcoming compilation of the responses because there isnt anything to
compile.

Ill just continue to ponder the question amidst the enormous collective of
one, and if something finally comes to the surface Ill pass it on.

Meanwhile, Ill see if I can come up with a more meaningful question that
might peak your interest.

Please dont misread this message. I am not distressed by the underwhelming
response. I understand that it is my responsibility to ask meaningful
questions if I want responses, not the groups responsibility to be enthralled
by what naggs at my mind.

Gene Bellinger
CrbnBlu@aol.com

[Bill Harris]

Ed Gallaher wrote:

>SD modeling was designed primarily for continuous systems. The fact that
>discrete toolboxes have been added to STELLA and others bothers me
>somewhat. Not because they are incorrect, but Id like to see a *very
>simple* software package available, with just the basic elements. Stocks,
>flows, and a reasonable supply of math functions. No authoring level. No
>ovens, conveyers, etc.

Not that Im very familiar with them, but what about Madonna
(http://nature.berkeley.edu/~goster/madonna.html) or EGO? I have used EGO
a bit, and it certainly seems firmly in the continuous camp. From my
recollection of the Madonna documentation, that is continuous, as well (it
may contain discrete, too, though: I dont remember).

Finally, there are continuous pieces (as well as separate discrete pieces)
to Paul Fishwicks SimPack (see http://www.cis.ufl.edu:80/~fishwick/).

Bill


--
Bill Harris Hewlett-Packard Co.
R&D Productivity Department Lake Stevens Division
domain: billh@lsid.hp.com M/S 330
phone: (206) 335-2200 8600 Soper Hill Road
fax: (206) 335-2828 Everett, WA 98205-1298

[bbens@MIT.EDU]

Greetings,

In my engineering training as a manufacturing process control engineer,
discrete and continuous simulations are done with some purpose in mind.
The fundamental use of simulations is a tool to design a controller.
Many times we build electronics controllers that in principle operate
continuously in time.

Other times, increasingly popular these days, we use digital computers
to compute a control action necessary to regulate our processes. The
computers operate discretely in time; therefore, we should test the
stability of our controller using simulations before its actual
implementation. The main reason is the periodic measurements and
controls performed by the computer cause the process to operate in an
open loop mode in between measurements and controls.

I will elaborate more on the detailed distinctions between the two
should there be sufficient interest in this group.

Regards,
Benny Budiman
MIT Student in Engineering
bbens@mit.edu

[CrbnBlu@aol.com]

irt: billh@lsid.hp.com (Bill Harris), Wed, Apr 24, 1996 5:15 AM EST

I have used Madonna and it is essentially a software program for running
model equations at lightnight speed. I can develop a model with Stella or
ithink, export the equations (in execution order) and load them into Madonna
and it runs about 100 times faster.

Im not familiar with EGO. Anyone have a reference for it on the web
somewhere?

I have looked at the SimPack library and I just havent been interested in
developing simulations that close to a programming environment so Ive shyed
away from it. I like to use an application that is as close to the solution
while not being too restrictive. Its an interesting trade-off sometimes.

Gene Bellinger
CrbnBlu@aol.com

[CrbnBlu@aol.com]

irt: bbens@MIT.EDU (Benny Budiman), Thu, Apr 25, 1996 5:31 AM EST

Benny, I for one would bery much like to have you elaborate on your digital
controller simulation development.

Gene Bellinger
CrbnBlu@aol.com

["Joel Rahn"]

On Fri, 26 Apr 1996 01:15:11 -0400,
CrbnBlu@aol.com <CrbnBlu@aol.com> wrote:

>
>As I perceive the question of determining between discrete and continous
>model development there are 4 factors that come into play.
>
I agree that these are important factors. I would kike to suggest some
alternative images or examples to maintain the industrial flavour of the
distinctions.

>1. The granularity of the environment being considered. Am I addressing the
>manufacture of discernable widgets of the apparent continuous flow of a
>fluid.

or "the apparent continuous flow of products" (when viewed over a
sufficiently long period of time for example, many multiples of the
lead-time or many, many multiples of the cycle time).

>2. The time frame of the events within the environment. Am I addressing the
>manufacture of widgets which take minutes each or am I consdiering the
>molecular interaction within the fluid flow.

or "am I considering the average production rate over a month, a quarter, a
year?" (I think that molecular interaction within the fluid flow would be
treated on an even shorter time scale than the minutes to produce a
widget, almost at the level of considering, for widgets, the wear on the
machine tool used to produce them).

>3. What is the time frame about which I am interested in developing a deeper
>understanding. Am I interested in the operation of the production line over a
>days time or am I interested in the operation of the production line over a 5
>year period.
>
>4. How many events are occurring in the smallest time frame I choose to
>model.

That is, can I identify and model individual events occurring at specific
times, or are such events so numerous, even in an interval a couple of
orders of magnitude shorter than my decision horizon, that they can only be
treated approximately, "on the average".

>I seem to be able to select values for these 4 dimensions which would
>indicate I should consider a production line from a discrete perspective. And
>at the same time I can select values which would seem to imply tht the
>production line should be considered from a continuous perspective.
>
>Does this provide any clarity as to why I remain somewhat confused?
>
I think you have it just about right, Gene. You need not be confused. The
choice of modeling approach will always be part of the art of simulation.
R. Joel Rahn
Dipartement OSD
Faculti des sciences de ladministration
Universiti Laval
Ste-Foy, Quibec
G1K 7P4 CANADA
til.: 418 656 7163 fax: 418 656 2624
e-mail: Joel.Rahn@fsa.ulaval.ca

[LOFDAHL COREY LOWELL]

Discrete versus continuous -- Ive been thinking about this for
several days after a private communication with Gene Bellinger,
and I think I might finally have some admittedly esoteric ideas
as to why he remains somewhat confused.

First of all, let me say that this topic comes up all the time
in electrical engineering (EE), where it goes by the name,
"digital versus analog" -- different names, same problem in that
smart people continue to disagree about the "best" way to solve
engineering problems. When I studied EE, I came down on the
analog side of the fence as, essentially, all EE problems
are analog. If you look at the response of a transistor at
a small enough time scale, it is indeed nonlinear, hence analog.
Digital circuits are thus a simplification of the underlying
analog nature of their constituent parts. Keep aggregating
up and computers are the same things, digital simplifications
of their analog silicon substrate.

The ability of digital computers to simulate continuous response
has been recently discussed here, and so I wont go into it again,
but what I do what to discuss is how really easy it is to go back
and forth between digital and analog (discrete and continuous) as
each is good at different things. The question remains, what are
these things?

Weve already highlighted two dichotomies -- discrete vs.
continuous and digital vs. analog -- so let me bring up some more,
left vs. right brain, or "logic" versus "pattern matching."
The brain actually encompasses both types of cognitive processes,
discrete and continuous, although they go by the names, "logic" and
"pattern matching." As most of us probably already know, Russell and
Whitehead tried to put the finishing touches on logic but was
thwarted by Kurt Godel and math types have since been trying to
interpret just what Godels theorem means ever since with some
holding this is the most important theorem ever and others holding
that its just a proof with little application outside mathematics.
Nevertheless, mathematician Rudy Rucker writes,

On the face of it, the application of formal logic
might be expected to resolve all kinds of disagreements.
As it turns out though, the known lows of logic are too
few in number to be of any great help.

Where does this leave us? Is logic, and therefore discrete
simulation, useless? Of course not. What it does mean though
is that logic (zeros and ones, ands, ors, and nots), is a simplification
of the types of situations describable through differential equations.

This has a cognitive component as well. The left brain contains the
sections that process logic and language, language being reducible
to logic. These are the simplifications that allow people to
communicate with one another. The right brain is able to "pattern
match," that is to perform much more sophisticated computations in
real time. For instance, fighter pilots and artists both primarily
use the right part of their brains. So we are left with the idea
that there is a complex reality out there that is more complex than
be communicated through language. One need only think of being at
the receiving end of a complex description that all of a sudden
becomes clear and exclaiming, "NOW I see what youre saying!"
This phrase captures the interface between left and right brain.

(as an aside, let me note that people are indeed language creatures
as Chomsky argues, but this logical process takes place on an
continusous substrate, neurons. One might want to read William
Calvins "Cerebral Symphonies" to appreciate the continuous aspects
of brains.)

Now let me return to the topic of this discussion group, system
dynamics. While system dynamics has always appealed to me as an
old analog EE type (but younger than Jay whos also an analog EE
type), Ive always wanted to know why system dynamics is right.
My current opinion is that system dynamics specifically and
continuous simulation generally allows one to make a more right
brain, pattern oriented argument than differential equations or
logic would allow. Moreover, system dynamics allows a richer
description of "reality" and all that implies.

Also, now that Im on a roll and have probably lost all my audience,
the scenario analysis of system dynamics allows one to explore the
entropy space inherent in any continuous system. I am not going to
explain this here as it would take to long and draw on knowledge
learned many years ago, but the key point is that a logical,
discrete analysis doesnt have the mathematical subtlety to do the
same.

Although theres much more to be said on this topic, I think Ill end
the argument on this note: continuous simulation is richer and harder
to comunicate while discrete is simpler and easier to communicate.

-------------------------------------------------
| Corey L. Lofdahl -*- lofdahl@sobek.colorado.edu |
| Institute of Behavioral Science |
| University of Colorado at Boulder |
| "there is an ethic to design, interact" |
-------------------------------------------------

[Alan YT HO]

Gene,

Is there anything on the net that give more info on Stella, iThink and Madonna?

[Hosts note if you look at http://www.std.com/vensim/SDSOFT.HTM you will get
a list of links to SD software - though Madonna is not currently among
them.]

Your input very much appreciated.

Tks a lot

Alan HO
alanho@singnet.com.sg

[CrbnBlu@aol.com]

irt: alanho@singnet.com.sg (Alan YT HO), Fri, Apr 26, 1996 6:09 PM EST

If you look at:

http://www.radix.net/~crbnblu/products.html

there are links to every piece of commercial simulation software, and a few
freebies, I have been able to find on the net. There are also links to other
simulation FAQs that Ive connected with.

Gene Bellinger
CrbnBlu@aol.com

[CrbnBlu@aol.com]

irt: lofdahl@sobek.Colorado.EDU (Corey Lofdahl), Fri, Apr 26, 1996 6:12 PM
EST

Corey, I appreciate your perspectives and I didnt perceive that by the end
you had lost me. I was wondering whether the last comment, "continuous
simulation is richer and harder to comunicate while discrete is simpler and
easier to communicate" was intended to be a logical conclusion I was supposed
to understand from the prior discussion, supportable by some insight I was
supposed to have made along the way, or somthing I was supposed to accept on
faith?

On numerous instances I would seem to have found continuous simulation quite
easy to communicate with those I was working.

Gene Bellinger
CrbnBlu@aol.com

[CrbnBlu@aol.com]

irt: STANG@fcit-m1.fcit.monash.edu.au (Shaun Tang), Mon, Apr 29, 1996 5:31 AM
EST

Shaun, I was with you up to the last sentence.

"Trying to rigidly distinguish these two approaches based on the
existing limitation/ deficiency from some currently available softwares
might be too easy to clarify the whole issue without bias. "

Could you elaborate on this piece a bit. Im not sure I quite get the
implication.

Gene Bellinger
CrbnBlu@aol.com

[gbackus@boulder.earthnet.net]

As has been noted by many, this discussion is very old. Most engineering
simulationists have lived this problem since the 60s. The Apollo space missions
and nuclear power simulations lived (and died) based on the appropriate
delineation of this issue. At Purdue Universitys School of Industrial
Engineering, the discrete vs continuous issue is a major part of the curriculum
as is system dynamics. Alan Priskers "Introduction to Simulation and Slam" is a
particularly good starting point because of his "sympathies" with SD.

I may have missed it but did anyone simply denote the "dt" issue as a trivial
Euler solution notation.

dPOP/dt=BR-DR

from Calculus 101: dPOP=POP(T)-POP(T-dt) : in the limit dt=>0

dPOP/dt=(POP(T)-POP(T-dt))/dt=BR-DR

multiplying by dt and placing POP(T-dt) on the left gives the SD notation.

POP(T)=POP(t-dt)+dt*(BR-DR)

One could use any solution method (of this most definitely DQ). The Euler just
makes more logical human sense in that MATHEMATICS IS SIMPLY A LANGUAGE. We can
explain things in many ways in English and many ways mathematically. To say that
the Population now is (equal sign) the previous Population plus (+ sign) the
Birth Rate less (- sign) the Death Rate over (multiply sign) the time interval,
make the causality "obvious" to humans. That "discrete" has a fixed "dt" is
beside the point as is the "classical SD" Euler solution of a DQ.

An important issue Joel Rahn brought up but I think went over the heads of many
is the stochastic aspect. A discrete system representation invariably has
discrete delays (the old DYNAMO boxcar delays). A continuous system
representation invariably contains continuous delays. A continuous SD
(exponential) delay represents an ERLANG distribution and therefore has some
implicit stochastics. To capture the other stochastics, a good modeler performs
exhaustive sensitivity analyses with the input parameters having distributions
that are sampled. There are formal methods for this (See Andy Fords work using
our HYPERSENS - Latin Hypercube sampling system and Henry Neimeiers work from
the Scotland SD conference using closed form solutions.) Mode splitting
(bifurcations) that the analysis produces show critical values for control
(policy) strategies.

In a discrete system, the stochastic term dominates the analysis because the
timing of each discrete sequence is necessarily uncertain (a sample from a
distribution). Therefore, the type of probability distribution of the
parameter/uncertainty can become critical (see Pritsker for starters on this
important issue). The "system" is then run (often thousands of times) until
"valid" output statistics are produced. The systems generally do have feedback
and the separation of feedback from stochastic effects (mode splitting) often
requires a tedious review of model results.

Thus a large "N" system works well for SD models and inefficiently for discrete
analyses. But a small "N" system requires special care in SD and no more than
"conventional" rules for a discrete analysis. (N is the number of process
occurring per unit time like births or machine failures.) A mixed system
requires a good recognition of what part (discrete or continuous) is dominate.
If it is the discrete, then the stochastic runs become important to valid
conclusions.

The issues of "are SD model DQ models?" (yes) and the "continuous versus
discrete interpretation" have hard-core analytical resolutions. The ethereal
discussions going on may be better founded if discussants first revert back to
earlier "scientific" works on the subject.

Given that this listserver appears to be most helpful to people beginning the
modeling process (where I sympathetically understand that going through the
millions of articles that have been written on simulation could be asking a tad
too much), it would seem valuable for the "ancient teachers" of the group (John
S, George R, and Joel R, among others) to think about a section of the SD
Review that focuses on the "tough" stuff. We have, as old-generation SDers,
tried hard to make the approach readily useful to the novice. However, some
technical "back to basics" may now be especially important as the "novices" come
of age. And if the "teachers" spend any more time trying to patiently bring out
the understanding of these deeper issues via the list-server, they will not be
spending their time on their research, not publishing it, and I will have
nothing new to steal and put in my models. Aaah..., aint altruism grand?


George Backus Email: gbackus@boulder.earthnet.net
Policy Assessment Corporation phone: (303) 467-3566; fax: (303) 467-3576
14604 West 62nd Place Denver, Colorado 80004, USA

[LOFDAHL COREY LOWELL]

On Sat, 27 Apr 1996 CrbnBlu@aol.com wrote:

> Corey, I appreciate your perspectives and I didnt perceive that by the end
> you had lost me....
> On numerous instances I would seem to have found continuous simulation quite
> easy to communicate with those I was working.

I think were thinking of the same thing, but terminology and our
individual viewpoints are getting in the way. When I say, "harder to
communicate," Im talking bits, information. Logic, and thus language, is
a compressed information medium as opposed to pictures. Consider the
space requirements for a text message as opposed to a gif or jpeg. A 20k
or 50k or 100k picture is nothing out of the ordinary, whereas generating
that much (coherent) text represents significant work (This message is
about 2700 bytes). And then if we want to move up from still frame to
moving picture (from jpeg to mpeg), then the space/information
requirements go up even more. So the difficulty here is from the
perspective of the information packager who wants to send the fewest
bits possible.

If by "harder to communicate" you mean difficulty for the receiver of the
information, then more bandwidth is better because there is less decoding.
For example, to interpret a picture or movie is quite easy and convincing
for a person because sight is our most prevalent sense. If it isnt, then
why are people buying multimedia computers and downloading netscape web
browsers? Moreover, pictures are understandable by people who speak any
language because there is less decoding. However, pictures requires high
bandwidth as the people in the Media Lab will tell you. One may be able
to convey the same message with fewer bits such as a verbal description,
but this requires more decoding (aka work) on the part of the receiver,
and more writing talent on the part of the sender. It is however
easier on the intervening medium whether it be a shorter book or a
smaller message packet.

This contrast should be familiar to system dynamicists because Dynamo was
able to become Stella only when high bandwidth user interfaces became
available on personal computers, and such interfaces came about purely
because of increased computer speed. There had to be enough spare cycles
available to devote to windows and menus and graphics as opposed to more
prosaic compiler, assembly language, and operating system concerns. One
need only compare an old Dynamo program or lineprinter graph to a
high-resolution, color, Stella visual program or graph to see the
difference. Same information at a differential equation level, but
Stella is far easier to progam and interpret. This increased
sophistication did not come about without cost.

>From a EE/CS perspective, Stella and Ithink represent a great deal of work
because the real-time continuous simulation and graphical presentation
require a great deal of s/w design effort, a very fast processor, and high
bandwith graphics. A consultant who correctly uses this combination of
software and hardware should find that communicating complex ideas becomes
easier as a result.

-------------------------------------------------
| Corey L. Lofdahl -*- lofdahl@sobek.colorado.edu |
| Institute of Behavioral Science |
| University of Colorado at Boulder |
| "there is an ethic to design, interact" |
-------------------------------------------------

[Jim Hines]

Shaun Tang in SD0087 offers further clarification of the discrete vs.
continuous discussion.

I think that Shauns emphasising that discrete event has variable-length
intervals between computations is important and clarifying, because this
is what separates discrete event simulations from discrete-time
simulations like the Samuelsons multiplier/accelerator model (already
mentioned by John Sterman in a prior posting on this topic).

Its also important to emphasize, however, that system dynamics
simulations are not intended to represent a discrete-time world, but
instead are intended to represent a continuous-time world. It is a very
tiny, mouse-like, minor point that the use of digital computers force us
into an discrete approximation of continuous-time. The crititcal,
whopping-big, great-grandaddy point is that the view taken in system
dynamics is one of continuous time.

Discrete-time simulations have important weaknesses, which John Sterman
discussed. These weaknesses are very stark relative to system dynamics
modeling because these two modeling approaches share so much in terms of
their aggregation and simplification strategies as well as in the view
taken of stochastic elements.

Discrete-event simulations, however, are a different beast. They
aggregate differently (or not at all) and stochastic processes seem to
occupy a much more central role in the unfolding of the simulation. It
is not clear that discrete event models are dominated (or mostly
dominated) by the advantages of continuous-time models.

Regards,
Jim Hines

["Joel Rahn"]

On Mon, 29 Apr 1996 19:36:13 +0000,
Shaun Tang <STANG@fcit-m1.fcit.monash.edu.au> wrote:

>a. Continuous-time system that can only be simulated by an analogue computer;
>or b. Discrete-time system to be simulated by digital computers.

While I understand the difference between analogue and digital computers,
I believe the use of simulated in both phrases above makes them both
incorrect. A simulation model is only an approximation of a functioning
system, so the simulation of continuous-time models by digital computers
(or, less frequently probably, of discrete-time models by analogue
computers) is not a distinguishing characteristic of the systems or of
their models.

>
>Discrete-time system can be simulated by two approaches:
>a. Discrete-time of fixed-intervals (eg. System dynamics)

You will not be surprised if I object to calling SD models discrete-time
of fixed intervals. The fact that dt is fixed for a given simulation run
of a model does not make the model a discrete-time type: some integration
methods change the length of time step to maintain numerical accuracy and
stability (rarely needed in SD models) but even the usual Euler method is
used in a context where, in principle, the value of dt could be any of a
wide range of reasonable values with no effect on the models design. To
me, this is enough to call SD a continuous-time model.
R. Joel Rahn
Dipartement OSD
Faculti des sciences de ladministration
Universiti Laval
Ste-Foy, Quibec
G1K 7P4 CANADA
til.: 418 656 7163 fax: 418 656 2624
e-mail: Joel.Rahn@fsa.ulaval.ca

[Shaun Tang]

In response to several previous messages related to system simulation:

The word "system" is a double use word. It can be used to mean a
real system within the pre-defined boundary. It can also be used to
represent an abstract system (as the approximation of a real system)
within the boundary pre-defined according to the objectives of study.
Modelling of a system particularly by computer simulation is
an abstract system. Computer modelling of a system (abstract)
can be qualitative/ quantitative/ both. Basically daily computer simulation
as problem-solving methodologies is based on quantitative modelling.

Based on the development of computer (hardware and software) capability
and progress in mathematics, system can be usually modelled as:
a. Continuous-time system that can only be simulated by an analogue computer;
or b. Discrete-time system to be simulated by digital computers.

Discrete-time system can be simulated by two approaches:
a. Discrete-time of fixed-intervals (eg. System dynamics)
with deterministic/ analytical functions.
b. Discrete-time of variable-intervals (eg. Discrete-event simulation)
with stochastic
andom functions that can be continuous or
discontinuous probability functions.
Both approaches are not ideal ones as the real system does vary
from these approximations. That is why some new hybrid/ combined
approaches are being developed.

Sometimes examples can be seen in the literature to illustrate
solving the same problem by both system dynamics and discrete-event
simulations (with very similar results). That is to say occasionally
these two are not necessarily mutually exclusive options to be chosen
against a real-life problem. They are simply different approaches to
analyse/ solve problems with different views (models) to generate insights.

Trying to rigidly distinguish these two approaches based on the
existing limitation/ deficiency from some currently available softwares
might be too easy to clarify the whole issue without bias.

Does the above induce more confusion?

Regards, Shaun
STANG@fcit-m1.fcit.monash.edu.au

["Joel Rahn"]

On Mon, 29 Apr 1996 11:36:53 -0600,
gbackus@boulder.earthnet.net <gbackus@boulder.earthnet.net> wrote:

>
>An important issue Joel Rahn brought up but I think went over the heads of many
>is the stochastic aspect. A discrete system representation invariably has
>discrete delays (the old DYNAMO boxcar delays).

Actually, in a discrete-event system it is a little more complicated
because the number of boxcars is random (random service time for example),
whereas for discrete-time systems it is fixed (as in time-series models).

>A continuous system representation invariably contains continuous delays. A
>continuous SD (exponential) delay represents an ERLANG distribution and
>therefore has some implicit stochastics.

This point is not trivial. The relationship to Erlang distributions can be
shown easily by analysing the effect of a pulse input (representing many
items arriving in the system all at once) on a DELAY structure. The output
rate has the form of an Erlang probability density.

But an interesting discrete-event model has more than a single server (or
sequence of servers for higher order Erlangs) serving a batch of arrivals.

To deal with stochastic arrivals and multiple servers, I showed in a paper
presented at the Shanghai conference that it is possible to formulate a
discrete-event version of an SD model and that, although the behaviour of a
single replication (i.e. a single run or a single sample from the
distribution of all replications of a given model) did not resemble the SD
result, the correlation structure of the values of a level variable (the
stock) were VERY similar. The example I used was based on Dennis Meadows
Commodity Cycle model.

To answer a suggestion made by Jim Hines, I believe it would be easy to do
the same kind of analysis on the Inventory-Workforce model (that also
shows cyclic behaviour).

The Shanghai result is encouraging because it deals with the fundamental
difference between discrete-event and continuous- or discrete-time models
(as described clearly in another part of the message to which this
responds): The randomness of the time intervals between events causes all
of the queuing effects which are effectively invisible to continuous- and
discrete-time models.

Incidentally, I have tried to use in the above text a classification of
models that someone else on this list used. Discrete-event for models that
have stochastically distributed times of events (i.e. changes of the
state of the model system), discrete-time for models whose times of events
occur at fixed intervals and continuous-time for models whose states change
continuously.

>
>In a discrete system, the stochastic term dominates the analysis because the
>timing of each discrete sequence is necessarily uncertain (a sample from a
>distribution). Therefore, the type of probability distribution of the
>parameter/uncertainty can become critical (see Pritsker for starters on this

Of course I agree with the first sentence above. The second one leaves me
a little confused: am I to read the slash (/) as distribution of the
parameter or distribution of the uncertainty... OR distribution of the
parameter uncertainty? From the first sentence, I take it that you mean
the type of probability distribution of the sequence of time intervals can
become critical. The distributions of other attributes or characteristics
in a discrete-event simulation are important for the design of experiments
as you mentioned.

>important issue). The "system" is then run (often thousands of times) until
>"valid" output statistics are produced. The systems generally do have feedback
>and the separation of feedback from stochastic effects (mode splitting) often
>requires a tedious review of model results.

Do you have a reference or two for this kind of analysis (mode splitting)? I am
not sure I see how it can be done in a discrete-event model. Is the feedback
you mention here based on policies or is it purely random (a certain percentage
of defective items may be re-worked one or more times)?
R. Joel Rahn
Dipartement OSD
Faculti des sciences de ladministration
Universiti Laval
Ste-Foy, Quibec
G1K 7P4 CANADA
til.: 418 656 7163 fax: 418 656 2624
e-mail: Joel.Rahn@fsa.ulaval.ca

[Shaun Tang]

re: SD0089 from Gene Bellinger <CrbnBlu@aol.com>

> Could you elaborate on this piece a bit. Im not sure I quite get the
> implication.

System can be dynamic (being time variant) or static. Both system
dynamics and discrete-event modelling approaches are designed
to simulate the characteristics of a dynamic system.
It can be viewed/ analysed as the combination of two time-variant
components, i.e. fixed interval and variable interval.
They can have effects on the validity of model
since data could be produced by the joint combination of them
but model may be based on single component.

Conventional simulators designed for system dynamics and
discrete-event methodologies were developed to handle mainly
either fixed-interval or variable-interval components.
However, these two methodologies fundamentally require different
approaches/ grammars to construct their unique representation models
(even for the same target system in mind).

Some simulators claim they can handle (to some extent) both components
as well as their combination. I would think that more fundamental studies
should be required because the built-in (say) random component is still
based on the same pre-constructed SD model.

Shaun TANG
stang@fcit.monash.edu.au

Shaun TANG
Department of Business Systems
Monash University
Clayton, Victoria 3168
AUSTRALIA

Email stang@fcit.monash.edu.au
Fax: +61 3 99055159
Phone: +61 3 99055810