# Simulations, SD and Control Theory

[Wolfgang Zocher (980807.0850 MESZ)]

I don't undestand the upcoming differences concerning the SD
"paradigma" and classic control theory as used in PCT to simulate
the control of behavior.

What we are trying to do (in terms of SD or PCT) is to simulate
a continuous system (continuous in time in most systems we are
are looking at) on a digital computer. A continuous system is
described mathematically with ordinary differential equations (ODEs),
differential algebraic equations (DAEs) or partial differential
equations (PDEs). All we have to do is to formulate the mathematical
description of the system and to solve the equations

ODE, DAE and PDE are used to describe the dynamics of a system!

In former times (30 or 40 years ago) solving ODEs was done with
analog computer machinery: the advantage was that a continous
"problem" was solved on a continuous machine - the disadvantage was
the need for big machinery ... But this way of solving (in finding
an electronic analogon for any mechnical, chemical or biological
system) was very close to the physics of the real system.

All ODEs which describe the dynamics of a particular system were
solved using a circuitry of integrators and amplifiers and
special devices like delays etc. eventually.

ANY system dynamics in ANY sort of system existing in reality
(or in mind) which could be described in terms of differential
equations could be simulated on such computers, including all
sorts of control problems, since control systems are nothing but
dynamic systems which can be described in ODEs, DAEs and PDEs.

Today, we are using digital computers. These computers are NOT
continuous devices since all data represented on these machines
have to be digitized and we have to look for good algorithms to
make them behave like analogs.

All those simulators are nothing but ODE- or DAE-Solvers!

I can't see anything NEW in a new "SD-paradigma" ...

···

--
Wolfgang Zocher

-------------------------------------------------------------------
email: zocher@rrzn.uni-hannover.de (office)
zocher@apollo.han.de (home)
www: http://www.unics.uni-hannover.de/rrzn/zocher
-------------------------------------------------------------------
--- Hiroshima '45 --- Chernobyl '86 --- Windows '95 ---
-------------------------------------------------------------------

[From Bill Powers (980907.0320 MDT)]

Wolfgang Zocher (980807.0850 MESZ)--

I don't undestand the upcoming differences concerning the SD
"paradigma" and classic control theory as used in PCT to simulate
the control of behavior.

What we are trying to do (in terms of SD or PCT) is to simulate
a continuous system (continuous in time in most systems we are
are looking at) on a digital computer. A continuous system is
described mathematically with ordinary differential equations (ODEs),
differential algebraic equations (DAEs) or partial differential
equations (PDEs). All we have to do is to formulate the mathematical
description of the system and to solve the equations

What you say is true, but it doesn't help a person who lacks the
mathematical background. A nice feature of simulation methods is that they
teach mathematical relationships without the student knowing that he or she
is learning differential equations!

I'm pleased to hear that you're still interested in developing your analog
computer program when you get a PC.

Best,

Bill P.

[From Wolfgang Zocher (980807.1400 MESZ)]

Bill Powers (980907.0320 MDT)

What you say is true, but it doesn't help a person who lacks the
mathematical background. A nice feature of simulation methods is that they
teach mathematical relationships without the student knowing that he or she
is learning differential equations!

That's right for "simple" systems. If the systems get more complicated, the
modeler _must_ know the underlying maths - that's my experience from about
15 years of simulating continuous systems ...

Best,
Wolfgang

···

-------------------------------------------------------------------
email: zocher@rrzn.uni-hannover.de (office)
zocher@apollo.han.de (home)
www: http://www.unics.uni-hannover.de/rrzn/zocher
-------------------------------------------------------------------
--- Hiroshima '45 --- Chernobyl '86 --- Windows '95 ---
-------------------------------------------------------------------

From [ Marc Abrams (980907.0936) ]

[Wolfgang Zocher (980807.0850 MESZ)]

I don't undestand the upcoming differences concerning the
SD "paradigma" and classic control theory as used in PCT
to simulate the control of behavior.

What we are trying to do (in terms of SD or PCT) is to
simulate a continuous system (continuous in time in most
systems we are are looking at) on a digital computer. A
continuous system is described mathematically with ordinary
differential equations (ODEs), differential algebraic

equations >(DAEs) or partial differential equations (PDEs).
All we have >to do is to formulate the mathematical
description of the >system and to solve the equations

makes _all_ the difference in the world. There are people I
know who can look at a problem and specify the equations
right on the spot. I have no such talent. I need a
_structured_, _organized_ way of formulating and dealing
with the various elements in a problem. SD works for me.

ODE, DAE and PDE are used to describe the dynamics of a
system!

In former times (30 or 40 years ago) solving ODEs was done
with analog computer machinery: the advantage was that a
continous "problem" was solved on a continuous machine -
the disadvantage was the need for big machinery ... But

this >way of solving (in finding an electronic analogon for
any >mechnical, chemical or biological system) was very
close to >the physics of the real system.

SD does not use differential equations. It uses first order
difference equations to represent the "Levels" in a model.
See _Principles of Systems_ by Jay Forrester Pgs 6-10 to
6-12 for a full explanation as to why. Most people in the
40's and 50's in the biological and engineering sciences
were introduced to systems with the use of differential
equations.

All ODEs which describe the dynamics of a particular
system were solved using a circuitry of integrators and
amplifiers and special devices like delays etc. eventually.

The key word here is _were_.

ANY system dynamics in ANY sort of system existing in
reality (or in mind) which could be described in terms of
differential equations could be simulated on such

computers, >including all sorts of control problems, since
control systems >are nothing but dynamic systems which can
be described in ODEs, DAEs and PDEs.

Today, we are using digital computers. These computers are
NOT continuous devices since all data represented on these
machines have to be digitized and we have to look for good
algorithms to make them behave like analogs.

All those simulators are nothing but ODE- or DAE-Solvers!

No they are not.

I can't see anything NEW in a new "SD-paradigma" ...

Who said there was anything new.

Marc

[From Bill Powers (980907.0832 MDT)]

Marc Abrams (980907.0936)--

There are people I
know who can look at a problem and specify the equations
right on the spot. I have no such talent. I need a
_structured_, _organized_ way of formulating and dealing
with the various elements in a problem. SD works for me.

The danger in such a rote-memorization approach is that you can end up
believing (passionately!) in all sorts of things that aren't true, or that
are true only by accident. Consider Gene Bellinger's model "atbd.mdl", a
"Balancing loop with delay." In this model, the "current value" is
described by the equation

current value = INTEG(flow)

and "flow" is described by

flow = DESIRED VALUE - DELAY3(Current Value,DELAY)

The DESIRED VALUE is 75.

The Current Value starts at the initialized value of 50 units, then rises
to about 90 units, falls to bout 65, rises to a little less than 80, and
after a few more oscillations, settles down at the desired value of 75.
That model is attached.

A person who simply took this behavior at face value might conclude that in
a balancing loop with a delay, the Current Value would overshoot and
undershoot a number of times before coming to rest at the DESIRED VALUE --
in other words, that the delay has made the system somewhat unstable, and
it's just the nature of negative feedback loops with delays to be unstable.
This is the basis of the "feedback is too slow" myth.

If, however, you make a slight change in the equation for the flow, the
story comes out differently:

flow = 0.365*(DESIRED VALUE - DELAY3(Current Value,DELAY))

We have lowered the gain in this loop to 36.5% of its former value. The
second attached model, atbd2.mdl, shows the effect. Now the Current Value
rises smoothly to the reference level -- excuse me, Desired Value --
without any overshoot. The system is now stable, without any change in the
delay.

In the model as given, there is no provision for varying the gain of the
loop. There should be another adjustable factor, GAIN, where the "0.365"
appears above. With GAIN fixed at 1, the system is unstable at all values
of DELAY, from 0.3 to 3 at least, the numbers I tried. With an adjustable
value of GAIN, the system can be made stable with any DELAY in the loop.

By the way, the reason for the instability is that the Delay3 function puts
in three additional leaky integrators, so there are actually four
integrators in this loop. If you don't understand why this creates
instability, you need to consult a control engineer.

A similar situation would occur if a pure transport lag were involved. A
pure transport lag is achieved by the (undocumented) function

Delay Fixed(input, delay time)

I don't know if the graphic setup will be included in these files; if not,
SELect the Desired Value and the Current Value for display, with a lower
limit of 40 and an upper limit of 100.

Best,

Bill P.

Atbd.mdl (57 Bytes)

atbd2.mdl (58 Bytes)

[From Oded Maler (980907)]

(Wolfgang Zocher (980807.0850 MESZ))

I don't undestand the upcoming differences concerning the SD
"paradigma" and classic control theory as used in PCT to simulate
the control of behavior.

[...]

I think this was one of the most sane posts on simulation that
has been seen here recently, and I completely agree with everything
you said.

The SD stuff seems to represent one of the most retarded branches of
cybernetics, while Bill's talk of analog computers represents some
confusions between models and computational models. The entities you
want to represent and simulate, at least at the lowest levels of PCT,
are physical models whose mathematical models consist of dynamical
systems governed by ODE or DAEs. They can be represented graphically
using block diagrams. At the past you could simulate them using analog
building blocks, and today you can use digital computer to generate
discretized approximations of their behavior.

--Oded

From [ Marc Abrams (980907.1239) ]

[From Oded Maler (980907)]

I think this was one of the most sane posts on simulation
that has been seen here recently, and I completely agree
with everything you said.

Good. I have a little problem maybe you and Zocher can help
me solve. It's called the 3 body problem. I just thought of
it this morning and thought you might be able to cut a quick
ODE for me. What is the analytic solution to the position of
the Earth, Moon, and Sun at _any_ time. No simulated tables
please. When your done with this i have a real doozy for
you.

The SD stuff seems to represent one of the most retarded
branches of cybernetics,

Really?, In your "learned" opinion what other branches are
retarded?

while Bill's talk of analog computers represents some
confusions between models and computational models. The
entities you want to represent and simulate, at least at

the >lowest levels of PCT,

You obviously have not yet received the good news. Zocher is
making a comeback with the analog computer. All will be well
with the world once again.

are physical models whose mathematical models consist of
dynamical systems governed by ODE or DAEs.

Have you come up with the answer to my little problem yet?
Keep workin' on it it'll come to you.

They can be represented graphically using block diagrams.
At the past you could simulate them using analog
building blocks, and today you can use digital computer to
generate discretized approximations of their behavior.

Thanks to Wolgang in a very short period of time this will
no longer be a _dilemma_ for the people on CSG net. _What_ a
guy. I can hardly wait to see the advancement of computers
go _back_ 50 years. Anyone for bobbie sox?

Marc

From [ Marc Abrams (980907.1303)

[From Bill Powers (980907.0832 MDT)]

Marc Abrams (980907.0936)--

There are people I know who can look at a problem and
specify the equations
right on the spot. I have no such talent. I need a
_structured_, _organized_ way of formulating and dealing
with the various elements in a problem. SD works for me.

The danger in such a rote-memorization approach is that
you can end up...

Rote memorization? Sorry, these are people who can _APPLY_
their understanding of mathematics to a problem.

Consider Gene Bellinger's model "atbd.mdl",

I don't care about Gene Bellinger, or his freakin model. Why
don't you try answering some of the questions I have posed
over the last two days? What is the problem here?

I am _impressed_ by your modeling prowess. But I am _much_
more impressed with your ability to side step and avoid some
issues you would rather not talk about. So you actually
looked at his Vensim models? No different than his CLD's
Huh?

You're a piece of work. Thanks for all your help and
cooperation. I wish you and Wolfgang a long and prosperous
analog life together.

Marc

[From Bill Powers (980907.1127 MDT)]

Marc Abrams (980907.1239)--

Marc, despite all provocations nobody is saying what they think of your
level of expertise when it comes to modeling and systems analysis. Are you
just trying to drag it out of them? Beware getting what you want.

Best,

Bill P.

[From Bill Powers (980907.1130 MDT)]

Marc Abrams (980907.1303) --

Consider Gene Bellinger's model "atbd.mdl",

I don't care about Gene Bellinger, or his freakin model. Why
don't you try answering some of the questions I have posed
over the last two days? What is the problem here?

One of the questions was "How can you comment on models that you haven't
run?" or something to that effect. So I did download Bellinger's Vensim
models (you recommended reading Bellinger) and found what I found. Now
you're not interested in Bellinger or his freakin' model, or what I have to

I did answer a number of other questions, and you acknowledged some of the

I have just obtained "Beginning Modeling Exercises", "Prepared for MIT
System Dynamics in Education Project, Under the Supervision of Dr. Jay W.
Forester" and written by Helen Zhu. Copyright by MIT. I do not recommend it
for reading by PCTers or others who want to learn about system modeling.

We just went through a discussion of the difference between equilibrium
systems and negative feedback systems, so I need only say that Zhu doesn't
understand the difference, and she doesn't understand the difference
between the end-state of a passive equilibrium system and the goal-state of
an active control system. It's also obvious that Zhu doesn't understand the
idea of a true goal-directed system; to her, the goal of a rainstorm is to
get the whole sidewalk wet, and the goal of a chromatograph is to bring the
actual height of the columns to their final height. Zhu also believes that
as a leaking balloon runs out of air, the pressure squeezing the air out
decreases (it actually increases -- it would decrease only in a non-elastic
container).

If this article was prepared under the supervision of Jay Forester, he was
asleep on the job. I assume, charitably, that he does understand these
distinctions and that he does know how balloons empty themselves.

I am _impressed_ by your modeling prowess. But I am _much_
more impressed with your ability to side step and avoid some
issues you would rather not talk about. So you actually
looked at his Vensim models? No different than his CLD's
Huh?

Not to me, except for the specific parameters. It's not that I don't want
to talk about the issues you raise. If you insist on knowing, I sidestep
some issues because I don't want to embarrass you by exposing your
ignorance. But if you insist, I'll oblige.

You're looking for a shortcut to understanding and it doesn't exist. There
is no way to grasp system relationships without at least some mathematical
understanding. Your preoccupation with the surface appearances of models --
what symbology is used, what the conventions are -- shows that you are
clinging to straws of appearances and missing out on the substance. Such
conventions are no obstacle to anyone who looks beneath the surface -- as
you seem implacably determined not to do.

That is, of course, your choice. But please don't expect me to try to
validate SD where I see it is deficient, or where its practitioners are
promulgating superstitions.

Best,

Bill P.

From [ Marc Abrams (980907.1543) ]

[From Bill Powers (980907.1130 MDT)]

I wish you and Mary a long and healthy life. You spend too
much time talking out of your ass though for my taste. I am
_not_ an expert in systems analysis or math, but unlike you
I am smart enough to know that and know where my limitations
are. You are one of the more self-righteous pompous asses I
have ever encountered.

Peace

Marc

Marc

Marc,

This post is unworthy of you. I was thinking that you were headed in
this direction and tried to warn you off.

The level of frustration reflected in your post can't be good for your
health.

It also takes some of the fun we are having playing with the SD tool
which you made us aware of.

Thanks,
David

Marc Abrams wrote:

···

From: David Goldstein
Subject: Re:Simulations, SD and Control Theory
Date: 9/7/98

>From [ Marc Abrams (980907.1543) ]

>[From Bill Powers (980907.1130 MDT)]

I wish you and Mary a long and healthy life. You spend too
much time talking out of your ass though for my taste. I am
_not_ an expert in systems analysis or math, but unlike you
I am smart enough to know that and know where my limitations
are. You are one of the more self-righteous pompous asses I
have ever encountered.

Peace

Marc

Marc

From [ Marc Abrams (980908.0153) ]

From: David Goldstein

This post is unworthy of you. I was thinking that you were
headed in this direction and tried to warn you off.

The level of frustration reflected in your post can't be

Your definitely right on one count and probably on both. But
I am not going anywhere. PCT and the modeling effort are too
important to me.

For 3 days I was trying to get Bill to look at SD as it is
currently conceived and used. I don't need nor did I ask for
a critique of anyone person, model or paper. I am not an
expert modeler and thought I made that _very_ plain and
clear. I _have_ been involved in SD modeling for the past 6
years so I do know and have _some_ knowledge of it's use. I
have also spent a great deal of time with other modeling and
simulating environments. Mainly I have worked with a ton of
people on _reading_ and understanding models others have
done. I have seen it work I have seen it fail. ( Modeling
attempts ). Not _one_ success or failure had to do with the
underlying method used. ( Sort of like having a piece of
software fail because it was done in C rather then Pascal,
who cares? )

_ALL_ had to do with the ability of the modeler(s) to be
able to communicate and engage others ( at whatever level )
in the modeling effort. The easier it was to get others
involved and interested the _better_ the modeling effort
was. _ALL_ modeling methods will give you the same results.
It might be easier to implement something's in one rather
then another but the end result should all be the same.
Whether Bill models in "C", Pascal, Java, Vensim, Stella,
Tutsim, or _whatever_, the end results should not vary. What
_will_ vary will be the type and kind of involvement he will
have from others. There _is_ a particular style to modeling
in SD. Just like there is one to programming in a higher
level language rather then assembler. But _one_ reason ( not
the only one ) for using a higher level language is
accessibility by others.

Yesterday I got my answer from Bill Powers on where he stood
with SD, and his willingness to look at the style and see
what fits and what doesn't. There are some _interesting_
process in SD, that effect not so much an individual control
system but multiple ones. Are there any conserved flows
conceptually or real ) What are they? What are the "rate"
or "policy" ( auxiliaries and rate variables ) variables?
_Exactly_ what "accumulates" in the system and where does it
come from? Where does it go? All the above just some BS on
my part. Fine say so and lets move on. What bothered the
hell out of me is that he ( Bill )took this real smug
position based on one persons modeling effort and _a_ paper
by some undergrad student. ( Yeah, I know, been there done
that ) What about the _other_ papers in that Chapter of
RoadMaps or how about the other 8 chapters. At this point I
really could care less. I will be posting my Vensim models
to CSG and communicating and having dialog about them for as
long as people on this net are interested.

Marc

[From Wolfgang Zocher (980808.1450 MESZ)]

From [ Marc Abrams (980907.0936) ]

>All those simulators are nothing but ODE- or DAE-Solvers!

No they are not.

I think you never understood the difference between "continuous"
and "discrete". What do you mean is a "difference equation"?

···

--
Wolfgang Zocher

-------------------------------------------------------------------
email: zocher@rrzn.uni-hannover.de (office)
zocher@apollo.han.de (home)
www: http://www.unics.uni-hannover.de/rrzn/zocher
-------------------------------------------------------------------
--- Hiroshima '45 --- Chernobyl '86 --- Windows '95 ---
-------------------------------------------------------------------

From [ Marc Abrams (980908.1003) ]

[From Wolfgang Zocher (980808.1450 MESZ)]

I think you never understood the difference between
"continuous" and "discrete". What do you mean is a
"difference equation"?

Maybe :-), It's my understanding that "difference equations"
are "integration" ( i.e. you compute the integral over a
specified dt rather then "differentiation". )

Am I mistaken in this belief?

Marc

[From Bill Powers (980908.0-834 MDT)]

Marc Abrams (980907.1543)--

I wish you and Mary a long and healthy life. You spend too
much time talking out of your ass though for my taste. I am
_not_ an expert in systems analysis or math, but unlike you
I am smart enough to know that and know where my limitations
are. You are one of the more self-righteous pompous asses I
have ever encountered.

This really doesn't sound like you. I can't imagine what has driven you to
all these excesses of vituperation in the last few days -- I have given in
to the temptation to strike back, and that was stupid. I apologize for that.
The problem is that I don't understand what you want. Perhaps you should
explain what this "Systems Dynamics Paradigm" is, that I seem to be
ignoring or avoiding talking about. I haven't so far seen anything
different between what the SD people say they're doing and what I have
always done in my modeling and engineering career (and what other modelers
and engineers I know have done). But maybe I've missed something, or
everything, important. If you'll explain what it is, even if you're
repeating yourself, I might understand this time.

Best,

Bill P.

Hi,

This is Bob Eberlein - the author of Vensim. I have been listening in on this
conversation and thought I might interject my own two cents worth.

One of the issues at hand is the best notation to use in representing PCT
models - another is the overall usefulness of this approach. I am attahing a
model speak.mdl that, I hope sheds a little light on both.

This model is mean to be the same (conceptually) as Bill's pct2.mdl. It does
not look very similar and there are some reasons for that:

1. It is written as a concrete example instead of a general theory. For the
most part that is the kind of models I do. More abstract models are difficult
to make much sense of once they become big. And for small models the comments
about System Dynamics being retarded, though excessive, are not completely out
of line. For little general models analytics have an awful lot to offer
relative to just simulation.

2. There are no manifest constants in this model. If a number shows up it
shows up attached to a name. It is important to do this for point 3 below, but
also to make concrete what the meaning of the number is.

3. All equations have units of measure and the units of measure balance. For
this simple model there are basically two types of units volume - measured in
decibels - and effort - measured in breath. Keeping units straight is
extremely valuable.

4. I am using boxes to represent Levels or state variables. Consistency is
real important here and it would be hard for me to change that. The rate
symbols are used whenever there is a physical interpretation to something -
such as speaking effort - that can be changed over time.

5. I have used a DELAY3 function not a DELAY FIXED function. There is a great
chapter in Industrial Dynamics on the nature of delays. In general for messy
aggregate processes the lower order (fuzzy) delays are more appropriate which
brings me to my final point.

6. My understanding of PCT is pretty limited but it may be that Vensim style
models are really only appropriate for the more big picture issues. Vensim is
not good for heirarchical representations (the value of which is a completely
different religious discussion) and, if you want to dig down to things like
synaptic response and then build back up, I would not recommend Vensim over a
programming language.

I hope this is helpful. I will keep watching to see what happens.

Bob Eberlein

speak.mdl (58 Bytes)

[From Bill Powers (980909.1004 MT)]

This is Bob Eberlein - the author of Vensim. I have been listening in on
this conversation and thought I might interject my own two cents worth.

One of the issues at hand is the best notation to use in representing PCT
models - another is the overall usefulness of this approach. I am

attaching >a model speak.mdl that, I hope sheds a little light on both.

Just to get the ball rolling, I'm attaching a small modification of your
"speak" simulation. I've just changed the form of what we would call the
"output function", to give the optimum performance -- adjustment of the
volume in the minimum possible time without overshoot (you can get within,
say, 5% in a slightly shorter time by allowing one overshoot). The delay
function is still the same, as are all the other functions except "Speaking
Effort".
Part of my reason for starting out this way is to find out how familiar you
are with control systems and their capabilities. Are you surprised that the
control system doesn't have to oscillate to its final state?

Later, we can get into the other interesting subjects you bring up.

Best,

Bill P.

This model is mean to be the same (conceptually) as Bill's pct2.mdl. It does
not look very similar and there are some reasons for that:

1. It is written as a concrete example instead of a general theory. For the
most part that is the kind of models I do. More abstract models are

difficult

to make much sense of once they become big. And for small models the

about System Dynamics being retarded, though excessive, are not completely

out

of line. For little general models analytics have an awful lot to offer
relative to just simulation.

2. There are no manifest constants in this model. If a number shows up it
shows up attached to a name. It is important to do this for point 3

below, but

also to make concrete what the meaning of the number is.

3. All equations have units of measure and the units of measure balance.

For

this simple model there are basically two types of units volume - measured in
decibels - and effort - measured in breath. Keeping units straight is
extremely valuable.

4. I am using boxes to represent Levels or state variables. Consistency is
real important here and it would be hard for me to change that. The rate
symbols are used whenever there is a physical interpretation to something -
such as speaking effort - that can be changed over time.

5. I have used a DELAY3 function not a DELAY FIXED function. There is a

great

chapter in Industrial Dynamics on the nature of delays. In general for messy
aggregate processes the lower order (fuzzy) delays are more appropriate which
brings me to my final point.

6. My understanding of PCT is pretty limited but it may be that Vensim style
models are really only appropriate for the more big picture issues.

Vensim is

speak2.mdl (59 Bytes)

···

not good for heirarchical representations (the value of which is a completely
different religious discussion) and, if you want to dig down to things like
synaptic response and then build back up, I would not recommend Vensim over a
programming language.

I hope this is helpful. I will keep watching to see what happens.

Bob Eberlein

Attachment Converted: "c:\eudora\attach\speak.mdl"

Hi Bill,

[From Bill Powers (980909.1004 MT)]

Two points on this. The first is conceptual. You can get almost the same results
you have by changing "time to adjust effort" in the original model to 8 minutes.
It is, in fact, pretty typical to see such adjustment slowing reduce or remove
oscillation in a system such as this. But that change is a statement about the
individuals responsiveness to their environment. If your assertion is that people
respond optimally in some sense to all stimuli than I disagree. Jay Forrester
always asserted that people respond sensibly and locally with globals consequences
that are quite unforseen and often bad. I agree with the second part but my
experience in modeling business situations suggests that even locally many
decisions are not sensible let alone optimal.

The second point is more mechanical but may actually be of importance. The model
you sent back has changed the formulation for Speaking Effort, but using the
terminology in the model we really should change the formulation for effort
adjustment. The new formulation for this becomes:

Effort)*0.002718/5

With this formulation in place the model fails units checking (Ctrl+U) and there
are also 3 manifest constants that are not transparent.

More importantly this equation gives the behavior the property that in a steady
state condition where a person is speaking at the right volume and receiving no
signals that a change is required they will slowly decrease their speaking
effort. This is something that is true for any parameterization and I would
normally treat this as a potential error in the model. A controller that includes
Speaking Effort should also include a perception of the required speaking effort
so that the steady state condition can exist.

I hope this is interesting.

Bob Eberlein

[From Bill Powers (980909.1412 MDT)]

Two points on this. The first is conceptual. You can get almost the same

results

you have by changing "time to adjust effort" in the original model to 8

minutes.

In my experience with low-level human control systems, the delays are
parameter (although none of the parameters seem to vary much once learning
is complete). One of my colleagues, Tom Bourbon, fit a control model to
data on his own performance in a tracking task about 15 years ago. At the
time, he generated a number of predicted behavior patterns for different
random disturbances, and saved them. Every five years, he does another run
of the experiment using one of the old patterns, and the model parameters
determined in the 1980s fit his current performance within a few percent.
The correlation between the model's behavior and the real behavior remains
above 0.99. So at that level of organization, I think we can claim that
human control processes are pretty stable over time.

If your assertion is that people
respond optimally in some sense to all stimuli than I disagree. Jay

Forrester

always asserted that people respond sensibly and locally with globals

consequences

that are quite unforseen and often bad. I agree with the second part but my
experience in modeling business situations suggests that even locally many
decisions are not sensible let alone optimal.

I don't agree that people respond to stimuli at all, so I guess we have to
back up a bit! However, I'm not very concerned with the kinds of cognitive
decisions people make, and can readily agree that they are likely to be
sub-optimal. Most of my modeling has been concerned with simple human
control processes that don't involve any reasoning and can usually be
accurately simulated with a simple PID + transport lag model.

The second point is more mechanical but may actually be of importance.

The model

you sent back has changed the formulation for Speaking Effort, but using the
terminology in the model we really should change the formulation for effort
adjustment. The new formulation for this becomes:

Effort)*0.002718/5

With this formulation in place the model fails units checking (Ctrl+U) and

there

are also 3 manifest constants that are not transparent.

The problem with doing it there is that you introduce a whole extra
iteration of lag in the Speaking Effort variable. I have changed your pure
integrator into a leaky integrator with gain, a fairly standard kind of
analog computing block that Vensim doesn't have but which is easily
synthesized. The leaky integrator is

Speaking Effort = INTEG[500*effort adjustment - Speaking Effort)*0.002718/5]

This was done in a hurry, with the numbers adjusted for high gain and
stability, but no attention paid to details or neatness.

Attached is a better job of it, with explicit constants with proper units.
The GAIN is in units of Breath/(Breath/minute) or Minute, and the slowing
factor SLOW is dimensionless. Now the units check out. This design makes
the stability independent of GAIN over a wide range. The gain is set to 500
now; change it to 5000, and there will be no material change in the results.

More importantly this equation gives the behavior the property that in a

state condition where a person is speaking at the right volume and

receiving no

signals that a change is required they will slowly decrease their speaking
effort.

This is something that is true for any parameterization and I would
normally treat this as a potential error in the model.

Not true. Expand the duration of the run; the Effective Speech Volume will
remain matching the Required Speech Volume as long as you please. There is
no "slow decrease" in the speaking effort. The speaking effort comes to an
asymptote and stays there. Please satisfy yourself that this is true by
using the Table tool.

A controller that includes
Speaking Effort should also include a perception of the required speaking

effort

so that the steady state condition can exist.

Sorry, I disagree. All that is necessary to perceive is the actual speaking
volume, for comparison with the required (i.e., intended) speaking volume.
There is no need to perceive the speaking effort. Look at the model. It
does not behave the way you seem to expect it to behave.

If we're going to argue about how control systems work, let's be careful
and stick to the modeling -- no sweeping generalizations. All assertions to
be proven by demonstration in Vensim.

Best,

Bill P.

speak3.mdl (59 Bytes)