Guenther Ossimitz wrote (edited for brevity):

>4) Wayne Wakelands binary "furnace on-off 0-1 stock" is

>really a great idea - if you want such a thing at all in a

>SD - model. Of course a flow of 1/DT is the only possiblity

>to maintain such a stock. however, it is easy to prevent

>the 1/DT division of the switching rates if one wants

>to: just create a stock with the levels 0="off" and DT="on"

>instead of 1="on". ...

One thing that helps with situations like this is to define names for

constants - e.g. create a variable called "Off" with the value 0, and a

variable called "On" with the value 1 or DT. Then you can write things like

IF THEN ELSE( Switch = On, ..., ... ), which may help model users interpret

the results.

Creating a stock that takes on a value of 0 or DT doesnt really get you

out of the conceptual bind of avoiding DT on the RHS of equations. The

behavior is identical to the version with the 1/DT flow, just scaled by DT.

Worse, the units are very odd - a dimensionless flow integrated to a stock

with units of time.

Its worth noting that 1/DT tricks dont work unless you use Euler

integration. Higher-order integration methods (e.g. RK4) assume continuous

derivatives and behave much like a smaller time step, so a stock draining

at a rate of stock/dt will never really empty all the way. You may be able

to get around this by using functions (PULSE in Vensim for example) that

hold values constant within a time step regardless of integration method,

but better to carefully consider what youre doing first.

>3) ... There are quite a number of contexts

>where a "natural" DT > 0 is given: consider any deliverance

>models where products are delivered say once a day every

>morning; many production processes have naturally induced cycles

>(eg. in farming, where one cant harvest the apples continually

>over the year), which make it plausible to set DT= 1cycle. ...

This is dangerous ground. When presented with a discrete time model that

aspires to policy relevance, I instinctively reach for the antacid tablets.

I dont want to argue that one cant build a good discrete time model, just

that many people dont.

-Theres a long history of discrete time models that mistake the sampling

frequency of a dataset for the relevant time scale of the system.

Samuelsons multiplier-accelerator and the Cobweb pricing model are both

examples of discrete time models that generate economic cycles as an

artifact of their simulation method.

-Discrete time models Ive seen tend to neglect stock-flow distinctions and

units of measure in general, which eliminates an important tool for

understanding and error-checking.

-Using discrete time (obviously) assumes that nothing of importance happens

on a time scale < DT. In my experience, the reverse is usually true in

strategic models - the important behavior of the system occurs on short

time scales (e.g. weekly sales and production) with measurement processes

layered on top at discrete intervals (e.g. annual revenue reporting).

-Using discrete time (less obviously) also complicates the representation

of behavior near the time step. A capital stock with a 15 year lifetime

will not be smoothly integrated in a model with a 10 year time step.

Modelers often account for this by explicitly correcting for compounding

within the time step, but this complicates the model and is seldom done right.

-The biggest problem with linking the simulation time step to the freqency

of a process in the model is that it then becomes less meaningful to test

whether the time step matters by changing it.

The approach I would prefer in most circumstances is to build the model

with a smaller time step than whatever discrete behavior is of interest,

and to include a clock mechanism to trigger whatever events do occur at

discrete intervals. This complicates the model somewhat, but allows a high

level of confidence. The (untestable and possible dangerous) alternative I

often select is to ignore the discrete calendar and treat everything as

continuous.

****************************************************

Thomas Fiddaman, Ph.D.

Ventana Systems http://www.vensim.com

8105 SE Nelson Road Tel (253) 851-0124

Olalla, WA 98359 Fax (253) 851-0125

Tom@Vensim.com http://home.earthlink.net/~tomfid

****************************************************