Using DT in Model Equations

This forum contains all archives from the SD Mailing list (go to http://www.systemdynamics.org/forum/ for more information). This is here as a read-only resource, please post any SD related questions to the SD Discussion forum.
Locked
"Neil Douglas"
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

Using DT in Model Equations

Post by "Neil Douglas" »

Jim Hines reasoning behind the prejudice against infinitesimal quantities
in mathematics
is interesting. However, Im not sure that it hits the nail on the head when
it comes to
the predjudices towards DT in System Dynamics.

The reason for our saying things like "dt is artificial", "never use dt in
an equation" or
"dt is only a technical parameter" within system dynamics equations is
somewhat more
rational. The computer simulation carried out in System Dynamics is at the
most fundamental level
often taken to be concerned with the solution of a system of differential
(or if you want
integral) equations.
(I dont actually think its fair to say that everyone agrees with this
statement, Sterman states
it explicitly in Business Dynamics, Forrester hints at it in Industrial
Dynamics and
Pugh and Richardson avoid the issue altogether in their Introduction to
System Dynamics Modelling.
However, its certainly a popular statement in the SD literature, indeed my
present bedtime reading
Competitive Strategy Dynamics by Kim Warren makes mention of the
differential equations basis of
System Dynamics.)

The algorithms used by the software (most commonly the Euler algorithm) seek
to solve this
system in a numerical fashion (most differential equations of interest to a
system dynamicist
are insoluble analytically).

We do this by discretizing the equation, that is dividing the solution
interval up into many dt
segments and applying an algorithm to get from a solution at point t to the
solution at point t+dt.
(A sensible algorithm can be determined by demanding several properties not
least of which is that
the numerical solution we find tends towards the actual solution of the
differential equations as
dt tends to zero. This can be a tricky business, but the Euler algorithm
manages this, under certain
assumptions, even if sometimes the convergence is slow.)

The actual solution to the set of differential equations that defines our
simulation is clearly independent
of dt (since dt has NOTHING to do with these equations). Since this actual
solution is what we are attempting to find
the simulation results should also be independent of dt (except insofar as
the numerical solution tends
towards the true solution as we decrease dt, which we observe in SD as a
result of the unchanging patterns
of behaviour as we halve dt). This also explains why dt should never appear
in our equations since the differential
equations we are attempting to solve cannot contain dt, which has no meaning
outside the numerical method.

Usage of dt in the equation Flow(t)=-MIN(....,S(t-dt)/dt) is merely taking
advantage of integration error
(since the explicit time constant in the second part of this equation is dt,
by standard SD thinking on time
constants we should expect integration error) to empty this stock in our
difference equations. It is simple
to see why since the Euler method does this: S(t)=S(t-dt)+dt*F(t) so
S(t)=S(t-dt)-dt*S(t-dt)/dt giving S(t)=0.
This formulation isnt independent of integration method, when using
Runge-Kutta it works very
differently (try it!, although the solution will still tend to zero, it
wont ever actually become zero).

All of this use of dt, of course, invalidates the underlying assumption that
we are seeking to solve differential equations.
The dictum that says that this is an acceptable use of dt appears to me to
be based mathematically on nothing better
than an assertion.

I believe Jim is right, and that time is ripe to reassess the place of dt in
System Dynamics. Why do we bother with all this differential
equations/integral calculus nonsense if we
never bother to check that our numerical methods are appropriate OR if the
equations we seek to solve have a
unique solution?

Id be really interested to hear what other people have to say on this
issue.

Neil Douglas

Consultant
Powersim Consulting
ndouglas@powersim.com
"geoff coyle"
Senior Member
Posts: 94
Joined: Fri Mar 29, 2002 3:39 am

Using DT in Model Equations

Post by "geoff coyle" »

Date: Wed, 17 Jul 2002 09:59:53 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Jim Hines says:


> First is the question of where the word "widget" comes from. According
> to the American Heritage Dictionary, the word "widget" is "perhaps [an]
> alteration of gadget". According to the same respected source the
> origin of the word "gadget" is unknown. Just thought Id clear that up.
>

Thats like the apocryphal definition of recursion: RECURSION; see
recursion.

> Second has to do with "dt". As a field were prejudiced against it,
> saying things like "dt is artificial", "never use dt in an equation",
> "dt is only a technical parameter". But this prejudice may have arisen
> -- like many prejudices -- as a byproduct of the way we were taught as
> opposed to anything substantive. Im referring to the fact that most
> of us were taught calculus using the idea of limits.

Id hate to be thought of as being prejudiced against dear old dt, still
less of his big brother DT. After all, some of my best friends are
mathematicians, even though I wouldnt want my granddaughter to marry one.
It seems, though, that the SD standpoint is that DT is not part of the real
business (or other) system and should not, therefore, appear in an equation
purporting to represent decision-making, or any other, system processes.
The three exceptions to that need to be used carefully, but are for special
purposes, such as non-negativity constraints.

Geoff Coyle
From: "geoff coyle" <
geoff.coyle@btinternet.com>
Bob Eberlein
Member
Posts: 49
Joined: Fri Mar 29, 2002 3:39 am

Using DT in Model Equations

Post by Bob Eberlein »

Jim Hines wrote:
> My point is just that dt can now be regarded as being just as rigorous
> as any other real (or hyper-real) number -- zero, one, pi, etc. This
> means that the Dynamo equations (and Euler integration in concept) are
> correct **mathematically**. Of course, digital computers dont allow

I have never really liked the dt notation - though that is largely a taste
issue. If, however, we are to take seriously the representation of
continuous time differential (or integral) equations using this notation we
cannot make use of the such constructs as (I will use dt for the TIME STEP
of integration)

outflow = MIN(normally indicated outflow,stock/dt)

for this would involve the division of a finite quantity by an infinitesimal
which, of course, is a no-no. Instead we would need to use a formulation
such as

outflow = IF THEN ELSE(stock > 0,normally indicated outflow,0)

For the two stock problem the equations become

outflow1 = IF THEN ELSE(stock > 0,normally indicated outflow1,0)
outflow2 = IF THEN ELSE(stock > 0,normally indicated outflow2,0)

Note there is not longer any prioritorization or cross dependence.
Mathematically this is much cleaner.

The problem, however, is that standard integration techniques will not solve
these equations (or the /DT style equations for that matter) as they are
distinctly discontinuous. It makes sense to use /DT notation when Euler
integration will be used as the equations themselves are effectively a
workaround for that integration technique.

Continuous formulations, on the other hand, such as

outflow = normally indicated outflow * effect of stock on outflow

where the effect of stock is normally computed using a lookup table are
continuous, though they can still have numerical problems depending on the
shape of the function.

The point of this is that if we take the dt notation seriously as a
representation of a continuous system no equations other than level equation
should ever use dt for anything and nothing should ever divide by dt.

Bob Eberlein
bob@vensim.com
"Jim Hines"
Senior Member
Posts: 88
Joined: Fri Mar 29, 2002 3:39 am

Using DT in Model Equations

Post by "Jim Hines" »

We certainly are saying a lot about a little. But ...

In order:

Goeff Coyles definition of "recursion" is perfect. But it just raises
another question: Whats the word for a definition that
***demonstrates*** its meaning. For those who still understand
analogies (a much beloved, but now deceased, item that once graced the
SAT exam), we need the answer to
onomatopoeia:word::________:definition.

Also: Geoff, what are the three permissible uses of dt?

----

Neil Douglas says that we shouldnt used dt because its just part of a
particular algorithm used to solve differential equations in which dt
actually plays no part.

Neils comment I think demonstrates how important it is to separate the
mathematical or conceptual dt from "dt" that can appear in some computer
algorithms. We shouldnt use the numerical "dt" in our equations (see
my response to Bob Eberlein for an example). But we can use the
conceptual dt in our equations. Take the equation

Level.k = Level.j + dt*rate.jk

Or,
_b
Level(b) = Level(a) + _/ (rate(t))dt
a

The "dt" isnt there because of Euler integration. In fact, you need
the dt in order for the units to come out correctly. Conceptually (i.e.
mathematically or theoretically as opposed to numerically) dt is part of
the equation. The DYNAMO equation says that the current value of the
Level is equal to the levels value an instant ago plus a "timelet"
multiplied by the rate -- that is, were adding the amount that the rate
"accumulates" over a timelet. The mathematical expression says pretty
much the same thing: The level at time b is equal to its "initial"
value at time a, plus the infinite sum of the rates accumulation over
each timelet between a and b. The hazy "timelet" of the seventeenth
century is just the rigorously defined infinitesimal of the twentieth
century.

As units-conscious SDers, shouldnt we **insist** that dt has a reality
separate from (or in addition to) any computer algorithm?

----

Bob Eberlein agrees that we dont have to dis dt anymore, but says we
shouldnt use it anywhere but in a level equation.

I think restricting dt to level equations may be too confining for the
little guy. For example, Bob says that to protect a stock from going
negative we can use the equation:

outflow = IF (stock > 0)
then (normally indicated outflow)
else (0)

This formulation gets rid dt, but isnt quite as good as a formulation
that uses dt:

outflow = if (stock < normally indicated outflow*dt)
then (normally indicated outflow)
else (0)

The above equation is quite acceptable mathematically, and it passes the
smell test, at least as far as my nose is concerned. It says that if
the quantity remaining in the stock is infinitesimal, then the outflow
is zero; otherwise the outflow is the normally indicated outflow. Now,
whats wrong with that?

On the other hand, taking Neils comment to heart, we do need to be
careful that we dont mix up the conceptual (mathematical) dt with the
"dt" that some computer algorithms use. For example I agree with Bob
that the following equation doesnt make sense, even though it "works".

Outflow = MIN(normally indicated outflow,stock/dt)

In non-standard analysis (one road to the infinitesimal) dividing by an
infinitesimal yields a hyper-real number greater than any real number
(the the other road to dt (infinitesimal analysis) wouldnt allow you to
divide by dt at all). So **at best** the equation is comparing a finite
rate to an infinite number. The comparison should **always** result in
the finite rate being the minimum, and so the outflow here should always
be the normally indicated outflow. This formulation in an SD model is
actually taking making use of the "dt" that the computer algorithm is
using. In other words the formulation in a model is doing what Neil
warned us away from: The formulation is taking advantage of numerical
error -- there is a huge forward error in this calculation, and the fact
that we like the error doesnt make it conceptually correct. I dont
think we should use this formulation, unless maybe we provide a comment
that its a computational artifact, something like saveper in DYNAMO or
Vensim.

In brief Im increasingly convinced that dt is OK in level equations AND
outside level equations. But you should make sure that you mean the
**conceptual** (i.e. mathematical or theoretical) dt and NOT the "dt"
used by some computer algorithm.

Jim
From: "Jim Hines" <jhines@MIT.EDU>
"Jim Hines"
Senior Member
Posts: 88
Joined: Fri Mar 29, 2002 3:39 am

Using DT in Model Equations

Post by "Jim Hines" »

My recent response to Geoff, Neal and Bob contains a typo.
A greater-than sign should appear in my suggested improvement
to Bob’s equation, rather than a less-than. The correct
equation is



outflow = if (stock > normally indicated outflow*dt)

then (normally indicated outflow)

else (0)

Jim
From: "Jim Hines" <jhines@MIT.EDU>
Bob Eberlein
Member
Posts: 49
Joined: Fri Mar 29, 2002 3:39 am

Using DT in Model Equations

Post by Bob Eberlein »

A couple of notes on DT and integration.

Jim suggests that we use an equation such as:


> outflow = if (stock > normally indicated outflow*dt)
> then (normally indicated outflow)
> else (0)

but also says we should not confuse this dt with our solution interval (call
it Time Step). If we really treat dt as an infinitesimal then the conditon
in the above equation is always true unless stock is either 0 or itself an
infinitesimal. If we think this through this means that the above
formulation and my formulation both have the same problem - an abrupt change
when the stock runs out.

Using Euler integration stocks are computed as:

stock(Time) = stock(Time - Time Step) + rate(Time - Time Step)*Time Step

At any given time we can compute what the stock will be at Time + Time Step
using the formula

computed stock for time plus time step = stock(Time) + normal
rate(Time)*Time Step

When this computation gives something less than 0 we know that the numerical
discountinuity in the rate will occur between Time and Time + Time Step. We
could try to figure out the exact value of Time it would occur at, adjust
Time Step to land there and then just start computing again from this new
Time. In fact, there are algorithms that use this approach. But it has the
problem that this needs to be done for every potential discontinuity - so
Time might never progress.

Since we are using Euler integration, and arent really interested in the
exact time of discontinuity anyway, there is a better trick. We just adjust
the rate so that the next Time Step will be the discontinuous point and
allow us to march ahead without problems. Technically we are splitting the
discontinuity between two points and the wonderful thing is that no matter
how many equations are like this we can still march along with a constant
Time Step.

To summarize, these funny stock/DT formulations are really just a way of
assisting our numerical integration techniques to work better when we do not
want to explicitly represent the causal nature of a feedback connection.

As a practical tip - the far more common formulation is

outflow = MIN(regular outflow not gated by stock, inflow + stock/Time Step)

this will let the stock sit at 0 and still pass the inflow through. Without
this you will end up with a sawtooth outflow that is not at all real. If
you have multiple outflows you can use

outflowi = MIN(regular outflow i,share for i*(inflow + stock/Time Step))

where the shares add up to 1 and are computed by any proritization scheme
that seems appropriate (for example ALLOCATION BY PRIORITY).

And that is probably too much of too little a thing- perhaps that makes it
just enough.

Bob Eberlein
bob@vensim.com
Locked