Building your own models

Locked
"Kim Warren"
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by "Kim Warren" » Sat Apr 01, 2000 8:10 am

Very helpful clarification Jaideep (and apologies for jumping in so hard
first time). Your reply is a useful focus for my concern ... your first two
Unstructured problem characteristics (first-cut, top down) are fine. The
problem arises with the third characteristic - qualitative. Heres my
reasoning
- A basic reality-check for any situation should, I believe, involve
gathering some top-level numbers (have we got an idea of ... how fast this
firm is losing customers / how quickly this population is catching a disease
/ how rapidly this natural resource is being depleted and so on ???).
Without these high-level numbers, I dont see how we can be sure that we are
addressing the clients issue, or even talking the same language. (It often
surprises me how, when asked to put numbers on something, people discover
they were using the same word to mean quite different things, which is why I
would never put an item on a board without knowing what its value might be).
- Such headline items either are, or depend upon, stocks of some kind
(time-based problems always involve stocks), and stocks are accumulating or
depleting at some quantified rate. So a further reality check should again
involve getting some rough numbers. We may have whatever mental model we
like about what the structure of the system is, or what we think its
feedback structure looks like - but those stocks exist, can be detected and
measured, and are doing as they please, not as we might like to imagine.
- CLDs cant capture the arithmetic of accumulation and depletion, so (in my
view) we cant have confidence in any qualitative behavioural insight that
we might offer from such a top-down, first-cut, qualitative approach. (It
has long been known that linear flows can create complex dynamics with no
feedback whatever, and even simple reinforcing structures can create a wide
variety of behaviours beyond the basic exponential growth and decline that
is usually taken to be their hallmark).
All is not lost, though, because it seems that ordinary folk are quite
capable of sketching out the numbers over time on important stocks in any
real case. They need only a little SD help to get a clear understanding of
how changing flows are causing these numbers. From there it is a small step
to seeing, quantitatively, why their issue is embarked on its particular
trajectory through time.
I think we would all acknowledge, that, when any more than the most basic
feedback is added in, the wider explanation becomes complex to the point of
being non-intuitive. But this is no reason to abandon what can be achieved
with the fundamental numbers that are generally knowable, even in the
earliest phase of work.

Id like to build on another important point Jaideep makes - the link to
statistical methods. In recent work on retail banking by some colleagues at
Darwin here in London, it proved critical (unsurprisingly) to know the rates
of customer acquisition and loss, and more importantly, the reason why these
rates were running as they were. Customer research had been done for years,
so it was easy to do regression analysis. These flows could be forecast with
quite some precision, if customers were asked how warmly they felt towards
the bank.
Correlation methods failed, though, the instant we crossed the flow-to-stock
boundary (so customer numbers, deposits, interest-income etc. did not
correlate well with anything) - which is exactly as expected, since
accumulation confounds linear causality and destroys any chance of finding
reliable correlations.
So may be we shouldnt be at all afraid to embrace statistical methods for
understanding the directly causal relationships that do exist, so long as we
dont pursue them across stock boundaries (Im sure others must have made
this observation long ago, but I remember it coming as a flash of light to
me when I first saw the point)

Kim
From: "Kim Warren" <
kim@strategydynamics.com>

Michael Evans
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by Michael Evans » Sat Apr 01, 2000 11:33 am

Jaideeps struggle with the uncertainty principle is a great analogy for
these philosophically murky Unstructured Systems (if we can continue to use
that very helpful term). The popular literature on physics these days (e.g.
almost anything by Paul Davies in a good bookshop) is so accessible that
you dont really need to be a physicist to develop an insight into the
seeming-paradoxes of quantum physics and relativity. And yes, the same
insights are helpful in appreciating the gap between SS and US systems.

For instance, Jaideep quandrifies:

We cant see where electrons are, but they must be somewhere in actuality,
so how can there be a probabilty distribution (cloud) of electrons
presence all over space (and even time, a la positrons, Feynman??!!)

The mistake is to try to visualise electrons etc as being merely localised
particles, like motes of dust. Its true that they can be made to interact
in an apparently localised way with a measuring device such as a
fluorescent screen, but that is more to do with the physical arrangement of
the device than with the properties of the electron.

An analogy (you have to get used to analogies in quantum mechanics, because
you cant interact directly with objects of this scale) is to appreciate
that an ocean wave breaks at a certain point on a shallow shore-line
because of the interaction between wave and beach. Similarly an electron is
a wave which actualises at a point on a screen. The converse view, i.e that
an electron is a point particle independant of our observation of it, is
like imagining an ocean wave as a permanent breakline which the beach
somehow makes visible. Wave-particles are not *like* that, they just
*behave* that way.

So the essential reality of an electron is a wave distributed through
space-time and occasionally interacting with macroscopic objects in a
seemingly localised but entirely probabilistic way. In the same way an
SDer of the *US* school might claim that there is no underlying inherent
reality in some classes of complex systems, merely a potential to actualise
in unpredictable dynamic configurations if we try to manipulate or
otherwise interact with them.

Im not necessarily arguing that this is always/often/sometimes/never the
case, but certainly the view that there is a contuinuum from SS to US
systems in practice is very enlightening to me and I thank Jaideep for his
insights. I hope this reply is at all insightful for him.

Michael Evans
From: Michael Evans <
mevans@metz.une.edu.au>
Centre for Water Policy Research
University Of New England, Australia
+ 61 0 6773 3744
fax 0 6773 3237



"Roderick Brown"
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by "Roderick Brown" » Fri Apr 21, 2000 1:51 pm

Jaideep Mukherjee comments:

"I think designing your own models is useful, but is of a limited value
only. In the extremely fast-moving technological world of today,..."

I think this might underestimate the speed of modelling in SD or
overestimate the speed with which business managers need to react. I think
there can be few circumstances where the results of a good model are
overtaken by events. Our consulting friends and other modellers will no
doubt argue that the time and effort spent in building and calibrating
models to assist decision making are generally commensurate with the risk or
opportunity. Thus, the many months (or years even) that it has taken to
develop fabulously sophisticated models of de-regulated electricity markets
is entirely justified by the pace and magnitude of the issue at hand. At
the other end of the scale, Ive seen the awesome results of just a morning
spent planning the destruction a rival companys dynamic resource system.
To be sure, the client, a manager of a high profile pharmaceuticals product,
had days to respond to the launch of a drug identical to his and there was
no time for a full scale modelling project: in fact, the model remained on
the whiteboard but it allowed him to orchestrate a devastating dynamic
strategy.

Jaideep makes an implicit assumption that, to be useful, SD models take a
long time to build and timely delivery is less likely unless modelling
shortcuts are taken. My first point is that, in my experience, this is
simply not true, more likely the reverse: if a model takes so long to
develop and interpret for the client that the point of decision is past,
then model design was inappropriate. My second point, a little more
controversial, is that the use of molecules solely to speed model
construction can lead to very poor models indeed. Molecules, if used at
all, are perhaps best confined to situations where they are simply the best,
most efficient and valid constructs yet devised. Seeing them simply as time
saving devices encourages the bending of such constructs to circumstances
for which they are less satisfactory than a bespoke approach would have
delivered. This is not to say that we should reformulate the macro code for
every built-in function we might use in contemporary software, which
undoubtedly save time, but I think there comes a point where the more
complex molecule structures should be treated with a suitably long barge
pole, particularly if our only reason for using them is to save time in
project that deserves time spent on it.


Rod Brown
rod@strategydynamics.com

"Bailo"
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by "Bailo" » Fri Apr 28, 2000 6:30 am

I appreciate Jaideeps comments on SS and US. I have worked for more than 20
years with system approach to problems in Africa and found it very difficult
to go behind insights and be operational due to the unstructured nature of
the problem. Influence and causal-loop diagrams are usually the tool needed.
My point is that in a country like France, I see that the main stream is
also US. May be the support from the environment is what determine the SS
and the US.
A+
======================================
Bureau dAnalyse dIngénierie et de Logiciels
08 BP 533
Abidjan 08
Côte dIvoire
Fax : 22472788
Email bailo@aviso.ci
mdtraore@bailo.net
bailo_mt@yahoo.com

"Kim Warren"
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by "Kim Warren" » Fri Apr 28, 2000 7:38 am

I must take issue with this perspective ... it is symptomatic of where
system dynamics is sacrificing the high ground by falling way short of what
it can deliver, and letting clients down into the bargain. I dont recognise
the class of unstructured problems described - we may not always be
examining systems with hard-wired physics, and many of the behavioural
responses that influence social systems may only be estimated with a large
degree of uncertainty, but the system *is* operating, and our task should be
to get as close as possible to capturing its structure, populating it with
the best facts we can get our hands on, and making our best estimates of the
scale and speed of change of its performance into the future.

There is no reason, in any of the unstructured cases listed, or others, to
be limited to qualitative insight. Unless we venture into the far reaches of
science fiction, there are always relevant, quantifiable facts to be had -
estimated number of possible customers, staff morale, product functionality
.... It is of little value to those who seek our advice to be told, after
hours of debate, that they can expect some qualitative boom-and-bust
scenario or to watch out for cyclicality caused by supply-line delays. I
dont deny that, for many, such insights may be unexpected, but the
structural causes of these qualitative phenomena and the contexts where they
may arise have been well-rehearsed by many expert writers in the field - we
can show these to clients in a few minutes and get on with some fact-based
analysis of the specific challenge that is confronting us.

We seem to have got into a forced dichotomy between, on the one hand,
concern to produce quantitative simulation models capable of producing
high-accuracy explanations vs., on the other hand, where this cannot be
achieved, throwing up our hands and saying well, if we cant produce
accurate models, all we can offer is qualitative behavioural descriptions.
There is a very wide spectrum of possibilities indeed between these two
extremes, and many (Id venture to say most) client concerns are very well
served by applying fact-based analysis to basic SD frameworks without going
near a computer. The managerial world is not universally beset by a
nightmare of intractable multi-loop complexities - much of the challenge
consists of relatively simple structures where the principal question is
about the broad scale of outcome and approximate rate of change that can be
expected.

In the case of Amazon.com, for example, many people would dearly like to
know just when the combination of increasing customer numbers, widening
product range, declining purchase rates and accumulating infrastructure
might result in a business architecture that is capable of making
sustainable profits. Every quarter, analysts produce forecasts that have
little basis in dynamic understanding of the implications of simple SD
structures, such as customer churn rates and co-flows. It puzzles me why so
many of our community robustly refuse to make the powerful contribution to
improving, by just a little, the quality of such forecasts and insist that
we cant say anything about such numbers without building detailed models.

Take the pharma. rivalry case mentioned by Rod. There is a known number of
customers, and a known number of sales people in both firms. These sales
people can make a known number of calls, which means that we know the number
of days it will take them to call on all customers. We probably know the
normal success rate of sales calls from similar occurrences in the past or
in similar market sectors, so we know at what rate the stock of potential
customers might be taken by the rival. The firm certainly knows from its own
experience the factors that sway a customer to switch suppliers, and the
balance between them. The manager can then estimate, quantitatively, the
extent to which he will have to cut back the rivals success rate to
undermine the whole attack, and the specific actions he can take that might
cause that scale of change to the time-path of the battle. As soon as the
battle starts, he can start collecting factual, quantitative information on
the important variables, and adjust the scale and balance between his
actions, week by week. All this he can share with his team, and get them to
share his understanding and track their success as events unfold.

Kim
From: "Kim Warren" <
kim@strategydynamics.com>

Bill Harris
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by Bill Harris » Tue Nov 14, 2000 7:30 am

Jim Hines wrote:

> I like your comment about the desirability of building your own model. What
> do you (and others) make of the many queries in this list asking for models
> on this or that topic?

Im bimodal. On the one hand, I agree with Geoff that building your own
model has many advantages, including that it may/should be more focused
on the specific problem and that it may lend itself to dialog among
those in the system about what is really going on, rather than having
them tending to accept the model as a black box.

On the other hand, I see the merits of reading others models to learn,
much as writers read others writings and electrical engineers study
others schematics.

My personal opinion is that general study of the literature, the books
and articles many on this list have written, and the study of others
models is an offline task, to be done to improve ones general skills.
Someone in product development with no particular problem at hand who
wants to find good models others have built to address product
development problems is arguably broadening their understanding of how
modeling could be applied in their field.

Modeling to solve a particular problem is an online task. I think
looking for a model at this point is a much less fruitful approach than
looking straight at the problem itself. It may be reasonable to look at
others approaches to similar problems after youve started your own
model to unfreeze your mind from early assumptions that may be
limiting. Even then, I think itd be more useful to find a model that
had addressed how to improve quality/cycle time/market focus in the
product development process, rather than to find a model of product
development. To emphasize, though, I think the most profitable online
focus is on the problem and the client.

Comments?

Bill
From: Bill Harris <
bill_harris@facilitatedsystems.com>
--
Bill Harris 3217 102nd Place SE
Facilitated Systems Everett, WA 98208 USA
http://facilitatedsystems.com/ phone: +1 425 337-5541

Bill Braun
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by Bill Braun » Tue Nov 14, 2000 7:56 am

At 10:48 AM 11/13/00 -0500, Jim Hines wrote:
>I like your comment about the desirability of building your own model. What
>do you (and others) make of the many queries in this list asking for models
>on this or that topic?

They may not be seeking them just to cannibalize. They are also a wonderful
way to learn. Ive frequently gained deeper insight into both the nature of
a problem as well as facility in the technical aspects of modeling (the use
of a particular function, for example).

Bill Braun
From: Bill Braun <medprac@hlthsys.com>


"Jim Hines"
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by "Jim Hines" » Wed Nov 15, 2000 2:55 pm

Niall Palfreyman writes
>I guess the equivalent [to software patterns] in the SD world are the
systems
>architypes, but Ive never seen these all gathered together in one place
>in a form which would be directly insertible into an SD model.

I think that the SD **molecules** are equivalent to patterns. And many are
gathered together into the Molecules which exist as a software plug-in for
Vensim and I think for Powersim, too. There is also documentation
available.

Whats the difference between molecules and architypes? The Archetypes are
peices of **systems** wisdom and are usually represented in words or loops.
The Molecules are pieces of **modeling** wisdom and are usually represented
in equations or stock and flow diagrams.

A note: Molecules are described many places in various amounts of
completion, including the documentation for iThink, Jay Forreters
Industrial Dynamics, John Stermans new book, the Richardson and Pugh book,
(probably Geoff Coyles book -- darnit, Ive got to read that) as well as
some documentation that Ive put together. The MIT SD group is currently
working on an upgrade to the Molecules in a joint effort with the Media Lab
and the Center for Coordination Science.

Regards,
Jim
From: "Jim Hines" <jhines@MIT.EDU>


"Jaideep"
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by "Jaideep" » Thu Nov 16, 2000 1:37 am

I think designing your own models is useful, but is of a limited value only.
In the extremely fast-moving technological world of today, designing your
own models is very slow from a business standpoint. Businesses are
interested in quick profits and competitive edges, and slow model building
for insights is generally a big waste of time, suitable only for ivory-tower
academia.

What can be useful is a combo of both modeling ability and the ability to
recognize what/how to reuse/cannibalize (in programing in general & SD in
particular). I have found it very useful to think (slowly, reflectively,
DESPITE pressures to do otherwise) in terms of patterns, then do quick
model/code prototypes, throw most of them away, and reuse what survives.
Object-oriented thinking definitely helps, even though it is not directly
translatable in practice, just as the SD archetypes are useful in good
thinking but not directly transferable in practice. In this sense I agree
with the sentiment below. I like to model/code to learn lessons, but also
reuse as much as possible for speed & efficiency (other emails on this topic
have said similar things).

> Im reminded of the software reusability issue. In the early nineties
> there was great hype about how we could now reuse all our code because
> of object-orientation, but then it turned out that people didnt
> actually _want_ to reuse code. Instead, everyone wanted to learn their
> own lessons by writing the code themselves.

It is a mix between Xtreme (
http://www.extremeprogramming.org/) and
structured programming (http://www.robelle.com/smugbook/structpr.html), and
the place where you stand in that mix is determined by your experience & the
wisdom of old age. I am slowly but surely getting there:-)

I am behind in my update of the SD mailing list search engine on my web
site, but will do it soon (for newcomers on this list, it is a search engine
that allows you to do quick keyword searches of all past emails on this
list). See www.optimlator.com for details.

Best regards & thanks for your time

Jaideep Mukherjee, Ph. D.
jaideep@optimlator.com
www.optimlator.com


"Jaideep"
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by "Jaideep" » Sun Nov 26, 2000 1:36 am

Thanks to Warren and Rod for their thoughtful comments to my post. Rods
points are well-taken, however, Id like to clarify some ideas (they became
clearer after this exchange, so thanks again).

I believe there are 2 types of SD modeling situations: modeling in
structured situations and modeling in unstructured situations (let us call
them SS and US for Structured Systems and Unstructured Systems
respectively). Extreme examples of SS would be the dynamic systems found in
physics and engineering (spring-mass systems, capacitor-resistor systems,
etc.). Many of these have closed-form solutions and, if they do not, the
math around them is highly developed such that SD-type simulations are not
necessary. Still, there are surprises even with structured systems (such as
Lorenz system) that SD can be useful for observing and understanding and
hopefully controlling such systems. There are SS also in biology and in very
highly industrialized societies such as in Western Europe and North America
(e.g., in industries where ERPs have been successfully implemented,
"structure" all the way from suppliers to customers, happily for ever!!).
Your example of de-regulated electricity market would be such a structured
system.

Unstructured systems would be the kind you find at the start of any new
unexpected phenomena (highly nonlinear, lots of delays, lots of
uncertainty), for example, the case of ecommerce today everywhere, or in the
case of any businesses that may venture into African markets (less so in
Asian markets). Your example of the pharmaceutical company probably falls in
this category (dont know enough so please correct me if I wrong).

Id also venture to say that the above 2 modeling situations correspond to 2
different types of SD modeling activities: (a) SD for policy prescriptions
(for Structured Systems - the "detailers") and (b) SD for insights (for
Unstructured Systems - the "insighters"). Even though there is only one SD
mailing list, and all SD modelers call themselves "system dynamicists", I
think there is a distinct difference in the way these two groups behave.
Many of the battles on this list occur when "insighters" cannot see the
"detailers" point of view and vice versa.

So what is my point: my point is that so long as one is dealing with US, and
it is a fairly new, uncertain situation, one can and should start with SD
for insights - high-level, first-cut, top-down approach. Just the fact of
bringing some order out of chaos will most certainly lead to useful insights
(again, your example of "the model remained on the whiteboard but it allowed
him to orchestrate a devastating dynamic
strategy"). What Id venture to say is that you dont need "system dynamics"
(traditional SD as I understand it, stocks and flows, variables, parameters,
simulations, etc.) necessarily for this kind of work. In fact, many modelers
successfully use other facilitation techniques, causal-loop diagrams,
hexagonal cards, & so on to create enormous value for their clients.

OTOH, my comment in the first email was about SD for policy prescriptions. I
doubt that managers in a de-regulated market really build large SD models
for years only to obtain insights. They use them for policy prescriptions
and thus to beat their competitors, and I felt that it is in this area that
SD could benefit much from reuse and cannibalization, leading to the kinds
of efficiencies we see in so many other OR/computer programming techniques.
Once years have been spent on building a large useful model, the only way
before competitors catch up is to reuse parts of that model for competitive
edges. As Warren correctly points out, object-orientation in SD will be very
useful in this, & that they are already working on it (by the way, Warren,
is the cited work available on the web??)

Most unstructured situations relate to human situations which are difficult
to measure, so simulations for insights and building models may be the only
way out (again, we dont need very sophisticated software such as Vensim DSS
for this). DLLs for human motivation, love, spirit,courage??? OTOH, one
could have reusable "population" modules (as in Limits to Growth), or
"demand" and "supply" modules as in many electric utility, transportation
and telecommunications models.

Bottomline: for SS, reuse, and have systematic techniques to promote reuse
as in OOP; for US, build models as there is no way out.

Regards

Jaideep

Jaideep Mukherjee, Ph. D.
jaideep@optimlator.com
www.optimlator.com


"Jaideep"
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by "Jaideep" » Wed Nov 29, 2000 1:35 am

Kim writes:

>I dont recognise
> the class of unstructured problems described - we may not always be
> examining systems with hard-wired physics, and many of the behavioural
> responses that influence social systems may only be estimated with a large
> degree of uncertainty, but the system *is* operating,

My categorization into SS (structured systems) and US (unstructured systems)
was only a simplification of reality (top-down, first-cut, qualitative
approach). Of course, if you drill down and bring the light of real world
data to it, you find that there is a broad continuum between SS and US.
There is truly no pure SS or US situation, only a difference of degree. My
point was simply that in *generally* unstructured situations, qualitative
techniques *may* help. The value & teaching of SD as introduced by
Forrester, in my view,
is that those qualitative techniques can be downright faulty, and a
structured SD approach (stocks, flows etc.) can lead to more insightful
results than qualitaitive thinking (there is an article by JF somewhere to
the effect "Counter Intuitive Behavior of social systems" in this regard). I
agree. In fact, I even believe (contrary to SD orthodoxy) that linear
systems also
can produce great insights, that causal-loops (& similar approaches) are
mostly
a waste of time, that SD can gain a lot more prestige by embracing
statistical models (O my god,
what have I said now), and that the speed of growth in SD theory is nowhere
comparable to that in other computer-aided decision tools - that was one of
the
points of my first post on this subject. I actually even agree
with Kims assertion that "it is symptomatic of where
system dynamics is sacrificing the high ground by falling way short of what
it can deliver, and letting clients down into the bargain."

An unrelated but interesting story on the point of "system * is*
operating", I remember my confusion about the uncertainty principle in
quantum mechanics. We use photons to see electrons, but because photons may
be the same size as electrons, they can be bumped by photons before they
reach our eyes. So the actual position of electrons is unknown as they are
bumping around even though photons tell us the place where they first met
electrons. So we can never know where electrons truly are, but we develop a
whole mathematical structure assuming that even the electrons dont know
where they are. I found it quite confusing and had the same argument - the
system *is* working, so at least the electrons should know where they are. I
still dont know the answer to this question. We cant see where electrons
are, but they must be somewhere in actuality, so how can there be a
probabilty distribution (cloud) of electrons presence all over space (and
even time, a la positrons, Feynman??!!). Physicists on the list, please
enlighten me.

> There is no reason, in any of the unstructured cases listed, or others, to
> be limited to qualitative insight. Unless we venture into the far reaches
of

Amen. If you check my past postings on the list (search "jaideep" on mailing
list search engine), I have always been a big advocate of whatever Kim said
here.

After reading Kims post a number of times, I was truly left wondering where
there
was a disagreement between us. Many a time I have raised the same points as
raised by Kim and I wholeheartedly agree with the concerns.

Cheers

Jaideep

Jaideep Mukherjee, Ph. D.
jaideep@optimlator.com
http://www.optimlator.com

"Jay W. Forrester"
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by "Jay W. Forrester" » Wed Nov 29, 2000 3:53 pm

>... (there is an article by JF somewhere to
>the effect "Counter Intuitive Behavior of social systems" in this regard). I
>agree.


The Counterintuitive paper is available at:
http://sysdyn.mit.edu
oad-maps
m-toc.html

---------------------------------------------------------
Jay W. Forrester
From: "Jay W. Forrester" <jforestr@MIT.EDU>
Professor of Management
Sloan School
Massachusetts Institute of Technology
Room E60-389
Cambridge, MA 02139

Tom Fiddaman
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Building your own models

Post by Tom Fiddaman » Wed Jan 10, 2001 7:47 pm

At 08:10 AM 12/1/2000 +0000, Kim Warren wrote:

>So may be we shouldnt be at all afraid to embrace statistical methods for
>understanding the directly causal relationships that do exist, so long as we
>dont pursue them across stock boundaries.

Its safe and useful to cross the stock boundary as long as you have the
right tools. Any time we hand calibrate a model to data we cant help
crossing it, with the handicap that propagation of state uncertainty is
probably not a strong point of human cognition. Doing the same with
statistical rigor normally requires dual estimation of parameters and
system state with some flavor of extended Kalman filter (as possible in
Vensim and advanced engineering and statistical packages).

There are also more structurally agnostic methods - like cointegration and
dynamic neural networks - that you will find in the econometrics and data
mining literatures. In my experience these arent really helpful for
typical SD models where data coverage is pretty sparse compared to the
model content, but are useful in other circumstances.

A few references:

David W Peterson, Hypothesis, Estimation, and Validation of Dynamic Social
Models - Energy Demand Modeling, MIT PhD Thesis, 1975.

"Statistical Tools for System Dynamics" by D.W. Peterson in Elements of the
System Dynamics Method edited by Jørgen Randers (Chapter 11, pp. 224-241,
The MIT Press, Cambridge MA, 1980).

Uncertain Dynamic Systems by F.C. Schweppe (Prentice Hall, Englewood
Cliffs, NJ, 1973)

Robert F. Stengel, Optimal Control and Estimation, NY: Dover Publications,
1994.

Theres also plenty of material on the web.

Happy new year, everyone!

Tom

****************************************************
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
****************************************************

Locked