dt/time step in the real world

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
Kim Warren
Junior Member
Posts: 10
Joined: Fri Mar 29, 2002 3:39 am

dt/time step in the real world

Post by Kim Warren »

Old Subject: The Derivative in the Real World
I would like to seek thoughts on one issue from this latest discussion -
explaining dT.

The mystical meaning of dT seems to be a major conceptual hurdle for
most regular people [not math genii] getting their heads around system
dynamics, especially when you start having to explain why variables take
a value in a simulation that is 1/dT greater than 'reality'.

I would be interested to lear how others cope with this pedagogically.

I have adopted an approach that - whilst probably anathema in the strict
sense - seems to be 'good enough' for most practical purposes. This is
to focus students' and executives' attention on choosing the appropriate
time *period* instead.

Having identified that the quantity of stocks [and constants or
decisions] at the start of a period determine the rate at which things
happen during that period, I suggest they ask themselves 'for how long a
period is it safe to assume that these rates don't change significantly,
relative to the overall scale of the situation?'. That length of time
becomes the time period of the simulation, and dT is 1.0.

This seems to be reasonably safe, and good enough for practical purposes
- e.g. if things continue more or less at a steady rate over a month at
a time, it is safer to set 'months' as the time period and have dT of
1.0 than it is to set 'years' as the time period and dT of 0.25.

It would be helpful to hear how others might explain the dangers of this
simplifying approach to audiences that don't have a strong grasp [or
interest!] in the math.

Kim Warren
From: ""Kim Warren"" <
Kim@strategydynamics.com>
""geoff coyle""
Junior Member
Posts: 2
Joined: Fri Mar 29, 2002 3:39 am

dt/time step in the real world

Post by ""geoff coyle"" »

Much as I like and respect Kim, I'm afraid that he is a little off-beam
about dt and especially 1/dt.

The key fact, in my understanding of SD (no doubt imperfect) is that dt is
an artefact of the simulation which has nothing to do with the real world
which, in simplified form, we are trying to simulate. In short, we only
need dt in order to get our equations to run on a computer. It follows that
dt has only a subsidiary relationship to the time units which are relevant
to a given model. Thus, if the natural, common-sense, time unit for the
system is months then the simulation should also count time in months, and
stop when the necessary simulation duration has been reached. Then, if there
is, say, a third order delay of 3 months, dt would be calculated from the
well-known formula that dt must be < delay_duration/2*delay_order (I
actually prefer 4*delay_order). In this case dt < 3/2*3, or 0.5. (it should
be less than or equal to, but this email won't do that). The reason for this
is to avoid numerical instability with Eulerian integration. dt should also
be the decimal equivalent of an exact binary fraction, so the permissible
values are 0.5, 0.25, 0.125 etc, depending on the problem.

1/dt is an artefact to bring about sudden changes, such as resetting annual
accounts back to zero at the end of the twelfth month. There are two other
valid uses of 1/dt, but this stuff is all in my 1966 text. I also have a
teaching note on the correct handling of TIME in SD models, which is not as
simple as you might think.

It is a great pity, in my opinion, that simulation packages allow a default
value of dt, which the unwitting will simply take to be valid for all
models.

I also dislike the use of timestep in place of dt. timestep sounds like
something real, which dt is not. In any case, timestep arises in discrete
event simulation, in which it is usually not a constant and may, in fact, be
random.

As Kim points out, this 'debate' about dt is all old stuff. The explanation
of dt has been in the text books for more than 40 YEARS so it should be
fairly well understood by now.

No doubt someone will correct me.

Regards,

Geoff

Visiting Professor of Strategic Analysis,
University of Bath
From: SD List Moderator <
system-dynamics@vensim.com
Cc: ""geoff coyle"" <geoff.coyle@btinternet.com>
""Jim Hines""
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

dt/time step in the real world

Post by ""Jim Hines"" »

Posted by ""Jim Hines"" <jhines@MIT.EDU>
Kim Warren asks about dt (or ""time step"" in Vensim).

DT has a very simple real world meaning. DT is an instant of time. Nothing
mystical about it. In our models, we use a very small quantity to represent
what in the real world is an infinitesimal quantity of time.

Kim is right that dt is the amount of time during which ""rates don't
change"", or even less technically, the time during which nothing (much)
happens as I've heard Bob Eberlein describe it.

I disagree with my friend Kim, though, when he says that this means that dt
is the time period (i.e. time unit) of the simulation model. The two are
very different, aren't they? The time unit of a simulation is the ""natural""
unit in which people tend to think when thinking about the patterns of
interest: Seconds or minutes if the pattern is a heart attack; months or
years for oscillations in a supply chain. In contrast, an instant, is ...
well... just an instant and you can measure it in seconds, minutes, months,
years, millennia...

There are two reasons to pay attention to DT. The first is so that you can
choose a DT that avoids misleading computational error. The second is that
the old DYNAMO-like notation can sometimes help people understand what a
level is (or does): Level[t] = Level[t-dt] + dt*(inflow[t-dt] -
outflow[t-dt])

There are situations where explaining dt isn't worthwhile (e.g. in a half
hour presentation to the board of directors). In such cases it seems best
to simply not mention dt at all. On the other hand, in situations where it
is worthwhile to explain dt (e.g. when teaching people how to model), then
one might as well spend the required five or ten minutes to explain it
properly, rather than having to explain it once and then again (and maybe
again and again) when the first explanation causes difficulties.

Jim
Posted by ""Jim Hines"" <jhines@MIT.EDU>
""Kim Warren""
Junior Member
Posts: 3
Joined: Fri Mar 29, 2002 3:39 am

dt/time step in the real world

Post by ""Kim Warren"" »

Posted by ""Kim Warren"" <Kim@strategydynamics.com>
thanks for this and other responses to the challenge of dealing with dT
with non-technical audiences.

I realise that how to treat dT has been very well-explained for SD
professionals and modelers for many years. But my question is somewhat
different - simpler and mundane, but challenging nevertheless.
Essentially, it's a pedagogical question, not a technical-modeling
question ...

- we are trying to help ordinary executives to appreciate how their
strategies deliver performance by building, developing and sustaining
resources that are interdependent
- they pretty much get the idea that 'stuff accumulates' and understand
too that the arithmetic of this is tricky
- ... so, we explain, it makes sense to have a computer do the tricky
arithmetic for you

So far, so good - they start up their computer, put in their staff
numbers, customers etc, and if they have been paying attention, get
stocks, flows and other variables about right. They also connect up
their stocks to costs and revenues to arrive at profits.
Then, they create a data table and run their model. They expect it to
match their real-world [e.g. month-by-month] data, and it doesn't,
because the stocks have incremented 1/dT times during each period - so
e.g. they thought they were adding say 20 customers per month, with
customers in month 1 rising from 200 to 220. However, the resulting
revenue does not reflect '200 customers' for the whole month, but a
rising number. So although our software reports the revenue at the start
of the month correctly at, say, 200 customers * $3m/month = $600m, it
tells them that the cumulative revenue at the end of the month is >$600m
because the customer-base was increasing during the month [if dT is 0.25
in this example, the model reports cumulative revenue at the end of
month 1 of $622.5m].

They get the point, but still have numbers that - in their terms - don't
make sense. What are they to do? telling them 'don't worry your little
heads about it - your SD expert will sort it out' isn't good enough,
since virtually none of them will have such a beast to call on. The only
solution I have found is to tell them to set dT to 1.0 but make sure
they model short-enough periods that things don't change too much within
any period.

Yes, they 'only' need dT to get their model to run on a computer, since
as Geoff points out dT isn't a feature of reality, but we always warn
them that they can't mentally estimate dynamic performance results, so
they really must use a computer if they want to get things right .. so
they inevitably bump into dT.

Does anyone out there in SD-land actually tell non-SD-technical modelers
to leave dT set at, say, 0.25, and if so, how do you then explain to
them what the model reports, and what to do about reconciliation?

Kim
Posted by ""Kim Warren"" <Kim@strategydynamics.com>
yaman barlas ybarlas boun.edu.tr
Junior Member
Posts: 4
Joined: Fri Mar 29, 2002 3:39 am

dt/time step in the real world

Post by yaman barlas ybarlas boun.edu.tr »

Posted by yaman barlas <ybarlas@boun.edu.tr>
Hi Kim;
Regarding your suggestion/question below, I think:
- Your suggestion is not really 'safe enough'. We can not assume in
general that people can informally guess a proper dt value by simply
asking ' how long a period is it safe to assume that the rates don't
change significantly'. If this were possible, there would be no need to
the immense branch of 'numerical simulation' (under mumerical
analysis). In any given (especially nonlinear) model, there can be very
sophisticated ways in which delays, functions or other parameter values
would dictate suprisingly small dt values. There are some sopisticated
quasi-mathematical ways to determine it, but ultimately the 'safest' is
to experiment by smaller and smaller dt values and stop when there are
no behavioral (pattern) changes in the output dynamics
- Any discussion of 'dt' must be preceeded by a decision as to whether
the model is 'basically' continuous or discrete. i- In a 'basically'
(not necessarily philosphically) continuous model, the 'value of dt' has
no meaning and must NOT be tied at all to model conceptualization. One
should forget about dt and conceptualize the model by choosing a proper
time unit that is meaningful with respect to the problem of concern,
decision rhtyms and time horizon. Dt selection must come later in the
SIMULATION of that model. (In the conceptual model, the value of that dt
is infinitesimally small, a limiting notion) ii- But if the model is
conceptually discrete, then DT has a real meaning: it corresponds to
some meaningful change step that exists in the real problem. On such
discrete models, it is best -as you describe- to set DT=1 and then scale
all parameter values (or potentially some other alternative change
steps) accordingly .
This is at least how I approach dt in my lectures.

Kim Warren wrote:
>Having identified that the quantity of stocks [and constants or
>decisions] at the start of a period determine the rate at which things
>happen during that period, I suggest they ask themselves 'for how long a
>period is it safe to assume that these rates don't change significantly,
>relative to the overall scale of the situation?'. That length of time
>becomes the time period of the simulation, and dT is 1.0.
>
>This seems to be reasonably safe, and good enough for practical purposes
>- e.g. if things continue more or less at a steady rate over a month at
>a time, it is safer to set 'months' as the time period and have dT of
>1.0 than it is to set 'years' as the time period and dT of 0.25.


best wishes for 2005 to all!
Yaman Barlas
Posted by yaman barlas <ybarlas@boun.edu.tr>
Jean-Jacques Laublé jean-jacques
Senior Member
Posts: 68
Joined: Fri Mar 29, 2002 3:39 am

dt/time step in the real world

Post by Jean-Jacques Laublé jean-jacques »

Posted by =?iso-8859-1?Q?Jean-Jacques_Laubl=E9?= <jean-jacques.lauble@wanadoo.fr>
Hi everybody.



Responses to the challenge of dealing with dT
with non-technical audiences from Kim Warren.


I do not understand the problem of explaining the influence of the time

step on results to non SD technician.


It is first not a problem of SD but of common sense.



One example:


If I negotiate with by bank that I will get a 5% interest rate a year,

it means that every year the bank will calculate the average

position of my account during the year, and give me at the

end of the year, the 5% interest on my average account.

Every body is able to understand that.



Now if I ask to my bank to give me the interest already after

a month and to add that interest to my account at the end of the month
instead of

waiting until the end of the year, everybody

will understand that at the end of the year, the total interest will

be greater than with the preceding method.

This can be easily checked with a spreadsheet.

It is not necessary to speak of actuarial or nominal or proportional
interest unless if you want to make things more complicate than they are.



If you want absolutely that the interest be paid at the end of each

month, your bank will probably make you the proposition to

decrease the interest rate, so that the result at the end of the year,

will stay the same than with a higher interest rate with interest

being added at the end of the year.



If the interlocutor being interested in some modelling insights

is not able to understand that, I think it is better to find another

interlocutor.



This explanation being well understood, it is easy to explain that any rate

in a model works in the same fashion, and depending on the time step that

you choose (a time step where everything is sufficiently stable) you will
have to

adjust the rate so that after a certain delay the increase of the level will
be the

same as it is expected in normal life.



So it is not necessary to automatically choose a time step equal to the time
unit

if you understand the necessity to adjust the rate in consequence.


Even if this notion takes some time to explain, it is worth doing it.



At the utmost, if the client does not want the interest to be added every

month, wants the interest rate to be the same as specified with his bank

and still wants the time step to be equal to one month, with the interest

being capitalised after a year, it is still possible to use special
functions

like 'sample if true', to stop the interest from being added every month.





Then the client will see some rates working exactly in a yearly fashion

and some others working in a monthly fashion as it some times happen in

ordinary life.



Regards.



J.J. Laublé

Allocar, rent a car.

Strasbourg France
Posted by =?iso-8859-1?Q?Jean-Jacques_Laubl=E9?= <jean-jacques.lauble@wanadoo.fr>
John Sterman
Senior Member
Posts: 117
Joined: Fri Mar 29, 2002 3:39 am

dt/time step in the real world

Post by John Sterman »

Posted by John Sterman <jsterman@MIT.EDU>
Kim points out that "" we are trying to help ordinary executives to
appreciate how their
strategies deliver performance by building, developing and sustaining
resources that are interdependent."" Kim's focus on helping real
managers make better decisions in trying circumstances is right on
the money.

Kim is also right that some people get confused because rates aren't
constant over the time period they normally consider (month, quarter,
year) so that a stock next quarter isn't equal to the stock this
quarter plus the reported change over the quarter.

But this isn't a technical issue to be hidden away. It has nothing
to do with the way we simulate our models. It's an important feature
of real systems that executives (and everyone else) should
understand. The reported rates in typical spreadsheets are averages
over the period, not the instantaneous rates at the beginning or end
of the period. People need to understand that well, and in my
experience they often don't. We do not serve them well if we try to
hide the difference. The solution of making DT equal to the data
reporting period is not appropriate. There is no guarantee that the
reporting period will be short relative to the dynamics of interest.
Having a model that generates erroneous results and spurious dynamics
because the time step is too large is a much greater risk to your
ability to have real world impact.

However, Kim is correct that managers demand, and should be able to
get, numbers from a model that are consistent with those they deal
with in the real system. It's quite simple to do so, and often is
required for accurate and appropriate modeling of the decision rules,
and for calibrating models to data.

For example, consider a model in which the sales of the firm are
growing exponentially. The current, instantaneous sales rate will be
larger than the average (or total) sales for the quarter or month
reported in the accounting system. If you calibrate the model
(formally or by hand tuning) to match simulated sales to the reported
sales you will be introducing significant distortion. These errors
can be large, as Kim points out.

The solution is simple: you need to model the reporting system. You
need to compare simulated reported sales and earnings to the actual
reported sales and earnings. You can do so by creating a variable
such as ""Reported Sales"" which accumulates actual sales over the
period (say, 1 quarter year). At the end of the quarter this
cumulation will equal (if the model is well calibrated) the actual
data for quarterly sales, even though actual current instantaneous
sales will be different (in the case of growing sales, it will be
larger). The interface of the model or management flight simulator
will display numbers that will ""make sense"" as a spreadsheet does but
will also include the 'true' instantaneous values of the rates -- and
the managers will be able to see the difference between them, if that
is an appropriate part of the learning strategy for the session.

There are several ways to model accounting systems, all easy to do
(and not described here). Nelson Repenning and I used these
structures in our model of Analog Devices (Sterman, J. D., N.
Repenning, et al. (1997). ""Unanticipated Side Effects of Successful
Quality Programs: Exploring a Paradox of Organizational
Improvement."" Management Science 43(4)(April): 501-521). The
technical documentation for that model is available at
http://web.mit.edu/jsterman/www/ADI/ADIhome.html.

Similar structures are also used in the model of dot.com businesses
Rogelio Oliva and I developed (Oliva, R., J. D. Sterman, M. Giese.
(2003). ""Limits to Growth in the New Economy: Exploring the 'Get Big
Fast' Strategy in e-commerce."" System Dynamics Review 19(2): 83-117.
The model is available at
http://iops.tamu.edu/faculty/roliva/research/dotcom/

John Sterman
Posted by John Sterman <jsterman@MIT.EDU>
Kim Warren Kim strategydynamics.
Junior Member
Posts: 16
Joined: Fri Mar 29, 2002 3:39 am

dt/time step in the real world

Post by Kim Warren Kim strategydynamics. »

Posted by ""Kim Warren"" <Kim@strategydynamics.com>
thanks John - this has helped bring the communication challenge into
focus for me. The key point I see in your advice is ... 'The solution of
making DT equal to the data reporting period is not appropriate [since]
there is no guarantee that the reporting period will be short relative
to the dynamics of interest.'

Telling them to choose a fractional dT, however, still leaves them
seeing numbers they don't recognise, because the model will interpolate
and use those interpolated values rather than the input values they
typed in. If we have a long time to tutor people carefully in all this,
that's fine, but execs typically want to see data they recognise, with
SD's magic dust, quickly give them some insight they didn't have before.
If not, they lose interest and turn attention instead to something else.

The solution I am trying to this is, rather than [a] tell them ""your
reporting periods are too long, so get the model to split it up"" , then
try to help them make sense of the numbers afterwards - tell them
""your reporting periods are too long, so you need to estimate values for
shorter-length periods"". For long-term issues this might mean estimating
quarterly data when your reporting is annual, and for shorter-term
issues estimating monthly data when your reporting is quarterly. That
way [I'm thinking] we get the exec to confront directly the
ever-changing nature of their world, rather than try to explain to them
how to make sense of what is, as you note, a non-trivial technical
solution that the software cleverly uses to produce something
realistic-looking from too-crude data.

They can still, of course, build in the reporting-period accumulations
so they get 'quarterly sales' for example. Indeed, it might make more
sense to see 'Quarterly Sales' being the accumulation of 3 x 'Monthly
Sales' rather than 4 x '0.25-of-a-Quarter's Sales'

.. does that make sense?

Kim
Posted by ""Kim Warren"" <Kim@strategydynamics.com>
Jean-Jacques Laublé jean-jacques
Senior Member
Posts: 68
Joined: Fri Mar 29, 2002 3:39 am

dt/time step in the real world

Post by Jean-Jacques Laublé jean-jacques »

Posted by =?iso-8859-1?Q?Jean-Jacques_Laubl=E9?= <jean-jacques.lauble@wanadoo.fr>
Hi Kim

I tried to send mails with attached files. but it does not work on this
list.
And the messages were not probably sent too.
You can find the files in a winzip .zip file on the
http://www.ventanasystems.co.uk/forum/
on the thread system dynamics discussion. I join 4 models and a .doc
explanation. Files can be joined on this forum.
The multiple_2 model makes the same thing then the multiple_time_steps one
but is more simple. The multiple_time_steps model had a bug in its first
version.
Regards.

J.J. Laublé

Posted by =?iso-8859-1?Q?Jean-Jacques_Laubl=E9?= <jean-jacques.lauble@wanadoo.fr>
posting date Sun, 9 Jan 2005 15:51:13 +0100
Locked