Should we use 0-off, 1=on to indicate an on-off switch in a thermostat?
To what extent does this require incorporating DT into the equation?
Is this good SD practice?
Wayne W and I have discussed this issue in the past and have never quite
resolved it. But this discussion rekindles some thoughts.
In the normal residential heating system we dont want the thermostat to
detect room temperatures to within 0.1 degrees, thus turning the furnace on
and off minute by minute. The average "system" is therefore designed to
maintain the temp within +/1 one or two degrees of the "set point". Any
more than this becomes noticeably uncomfortable.
Traditional thermostat:
Consider a traditional thermostat with a bi-metallic coil. Start with a
cool room. The coil contracts, hits a contact, turns on the furnace, and
the room begins to warm. With some delay, the coil begins to warm and
expand, releasing the contact and turning off the furnace. The room begins
to cool, starting the cycle again.
Rather than model one stock (room temp) and one on-off switch, I would use
two stocks. One illustrates room temp, the other illustrates the temp of
the bi-metallic coil.
The size of the coil, the amount of expansion per degree, etc. will
contribute to the "lag" in the system, thus damping the response of the
furnace to very small changes in room temp.
We could demonstrate this (physically, and in the SD model), by placing a
paper cup over the thermostat. The furnace heats the room, but additional
time is required for this information to get to the sensor. This lag leaves
the furnace on too long, and the room overheats before the coil gets warm
enough to turn it off. Once the furnace is turned off the room cools below
the desired temperature. Heat is trapped within the cup and the coil does
not turn the furnace on again until the room is well below the desired
temperature.
We have thus converted a comfortable system with a +/- 1 degree "dead zone"
into an uncomfortable system with a +/- 5 degree dead zone. More
importantly, we have captured the true dynamic structure of the system if
we model it in this way, rather than by using a mathematical on-off switch
to simulate the thermostat switch.
Question: Before continuing below, does the above analysis make sense?
High Tech thermostat:
We now have a digital thermostat at home. It has a semi-conductor
temperature probe rather than a bi-metallic coil.
(It is possible that this probe was designed with a very small mass and
therefore a very rapid time constant. If undamped this would lead to rapid
on-off cycles. OR the mass of the probe might be designed to take this into
account. I am ignorant about this design issue. Does anyone know the
answer?)
I bring this up because if the temperature sensor indeed has a very rapid
time constant, the damping might be introduced in software (or rather,
firmware). The damping might literally be produced by an IF-THEN statement
within the thermostat controller!
e.g. Algorithm says --> If the temp is rising, turn OFF at 71 degrees; if
the temp is falling, turn ON at 69 degrees.
These logic statements would create a dead band of +/- 1 degree around the
desired temperature of 70 deg.
Back to the philosophy and practice of SD modeling and simulation:In this
case the "correct" model would explicitly -require- the use IF-THEN
statements!
{BTW, I bought a "cheap" ($19.95) digital thermostat several years ago. It
was quite uncomfortable, with a dead band of at least +/- 2 degrees. After
a year or so I upgraded to a "deluxe" version ($29.95). Much better!}
This is an intriguing question, because I often use descriptions of the
familiar (and reasonably intuitive?) home heating system as an introduction
to mammalian thermoregulation. If my students are not familiar with
bi-metallic coils then the introduction becomes a bit strained.
Ed Gallaher
Oregon Health Sciences University
From: Ed Gallaher <gallaher@mail.teleport.com>
(PS As an aside, technology is creating a new set of generation gaps.)
Example I.
School children were asked to form a circle and then rotate the circle
clockwise.
Kids: "Whats clockwise?"
Teacher: "Thats the way the hands turn on the clock."
Kids: "What are hands?"
Example 2.
Mom: "Would you tie a bow on that package?"
Billie: "Whats a bow?"
Mom: "Thats what you use to tie your shoelaces."
Billie: "What are shoe laces?" (looking down at his Velcro . . . )
DT and furnace/thermostat models
-
Ed Gallaher
- Junior Member
- Posts: 2
- Joined: Fri Mar 29, 2002 3:39 am
-
"Jim Hines"
- Senior Member
- Posts: 88
- Joined: Fri Mar 29, 2002 3:39 am
DT and furnace/thermostat models
Ed Gallahers note on thermostats is a terrific example of how most modeling
difficulties are resolved when the real-world "policies" are understood. I
have noticed that its much easier to model after asking people how they
really make decisions, than it is after simply thinking about either how
they **ought** to make the decisions or how I **imagine** I might make the
decision. The same obviously applies to physical systems, such as
thermostats.
Jim Hines
jhines@mit.edu
difficulties are resolved when the real-world "policies" are understood. I
have noticed that its much easier to model after asking people how they
really make decisions, than it is after simply thinking about either how
they **ought** to make the decisions or how I **imagine** I might make the
decision. The same obviously applies to physical systems, such as
thermostats.
Jim Hines
jhines@mit.edu
-
Tom Fiddaman
- Senior Member
- Posts: 55
- Joined: Fri Mar 29, 2002 3:39 am
DT and furnace/thermostat models
>Should we use 0-off, 1=on to indicate an on-off switch in a thermostat?
Thats what I would do, because of the binary switch analogy.
>To what extent does this require incorporating DT into the equation?
You still need DT (TIME STEP in Vensim) on the RHS of an equation:
Switch State = INTEG( Switch Change Rate, Initial Switch State )
Switch Change Rate = (Indicated Switch State - Actual Switch State)/TIME STEP
you can seemingly get out of this with a special function, e.g.
Switch State = DELAY FIXED( Switch Change Rate, 0 )
Really this is just a trick, because infinite-order delays (like DELAY
FIXED or DELAY MATERIAL in Vensim) and other discrete functions implicitly
use DT on the RHS.
>Is this good SD practice?
Since good SD practice is to model things the way they work, I think the
answer is yes, subject to the earlier comments of Geoff Coyle, Jack Homer,
Nelson Repenning, Jim Hines, et al. The key questions to consider are
whether the underlying time constant of the switch is very fast with
respect to the rest of the model behavior and whether were modeling one
thermostat or a neighborhood full. Clearly the thermal interaction between
a house and its environment is continuous, so in this case a discrete event
simulation would be a poor alternative to a continuous model with some
discrete switching.
>In the normal residential heating system we dont want the thermostat to
>detect room temperatures to within 0.1 degrees, thus turning the furnace on
>and off minute by minute.
...
>Traditional thermostat:
>Consider a traditional thermostat with a bi-metallic coil. Start with a
>cool room. The coil contracts, hits a contact, turns on the furnace, and
>the room begins to warm. With some delay, the coil begins to warm and
>expand, releasing the contact and turning off the furnace. The room begins
>to cool, starting the cycle again. ...
Its been a while since I had a bimetallic thermostat to fool with, but I
wonder if theres a second mechanism - in addition to the slow-changing
state of the coil - that creates a deliberate dead zone around the desired
temperature. I remember the coil having a pointer on it, which would meet a
contact to the right when warm (switching the furnace off) and to the left
when cool (switching it on), creating the same logic as in a digital
thermostat. Perhaps someone in an old classroom can check.
>Rather than model one stock (room temp) and one on-off switch, I would use
>two stocks. One illustrates room temp, the other illustrates the temp of
>the bi-metallic coil.
>
>The size of the coil, the amount of expansion per degree, etc. will
>contribute to the "lag" in the system, thus damping the response of the
>furnace to very small changes in room temp.
...
>We have thus converted a comfortable system with a +/- 1 degree "dead zone"
>into an uncomfortable system with a +/- 5 degree dead zone. More
>importantly, we have captured the true dynamic structure of the system if
>we model it in this way, rather than by using a mathematical on-off switch
>to simulate the thermostat switch.
>
>Question: Before continuing below, does the above analysis make sense?
The analysis is very sensible, however it seems you still need to compare
the thermostat temperature to the desired temperature, which will require a
logical switch, unless you want to get really complicated and model the
physics of the electrical and mechanical systems of the switch and furnace.
The only way out of IF-THEN logic seems to me to be a furnace that runs at
a variable rate, proportional to the gap between the desired and actual
temperature.
>High Tech thermostat:
...
>(It is possible that this probe was designed with a very small mass and
>therefore a very rapid time constant. If undamped this would lead to rapid
>on-off cycles. OR the mass of the probe might be designed to take this into
>account. I am ignorant about this design issue. Does anyone know the
>answer?)
It seems quite likely that it does have a small mass. There are probably
still delays in the measurement process because the house isnt really a
well-mixed, first-order box of air (or heat). It takes a while for warm air
to move around. Also, theres a delay between the firing of burners and the
startup of blowers or pumps - so the system has a fairly high order if you
get into detail.
...
>e.g. Algorithm says --> If the temp is rising, turn OFF at 71 degrees; if
>the temp is falling, turn ON at 69 degrees.
The algorithm probably actually reads "if the furnace is on, turn it off
above 71 degrees; if the furnace is off, turn it on below 69 degrees."
Theres no way in principle for the thermostat to directly measure the rate
of change of the temperature in the room; this would have to be estimated
by some kind of smoothing or data storage and trend estimation process,
which would be complicated and sensitive to noise. Its much easier for the
thermostat to work with the switch state, which it already knows. Also,
its a good bet that when the furnace is on, the temperature is rising, and
when its off its falling.
>These logic statements would create a dead band of +/- 1 degree around the
>desired temperature of 70 deg.
>
>Back to the philosophy and practice of SD modeling and simulation:In this
>case the "correct" model would explicitly -require- the use IF-THEN
>statements!
Right. The reason IF-THEN logic is frequently shunned in SD practice is
that it is often misused when a decision is heterogeneous. For example, an
IF-THEN statement would be a poor model of the behavior of a neighborhood
of thermostats, as not all of them would be set to the same temperature,
have the same tolerances, etc. If the congregation will now turn to
Industrial Dynamics 5.5,
"Even major executive decision represent a rather continuous process; they
are reached after a period of consideration; advance actions may be taken
in anticipation of the probable outcome; action is not taken immediately
after the decision; and the decision is interpreted and smoothed and
produces gradual change as it overcomes resistance and the inertia of other
persons in the organization."
(See the book for more good details on this).
A traditional alternative would be to create a table function, continuous
between 0 and 1, representing the distribution of on and off thermostats in
the neighborhood at each temperature. A more accurate method would be to
disaggregate the neighborhood, representing each individual thermostat,
with diversity in their target temperatures and physics, but this would be
overkill in most cases.
I think Im overkilling this topic as well, so all for now.
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
****************************************************
Thats what I would do, because of the binary switch analogy.
>To what extent does this require incorporating DT into the equation?
You still need DT (TIME STEP in Vensim) on the RHS of an equation:
Switch State = INTEG( Switch Change Rate, Initial Switch State )
Switch Change Rate = (Indicated Switch State - Actual Switch State)/TIME STEP
you can seemingly get out of this with a special function, e.g.
Switch State = DELAY FIXED( Switch Change Rate, 0 )
Really this is just a trick, because infinite-order delays (like DELAY
FIXED or DELAY MATERIAL in Vensim) and other discrete functions implicitly
use DT on the RHS.
>Is this good SD practice?
Since good SD practice is to model things the way they work, I think the
answer is yes, subject to the earlier comments of Geoff Coyle, Jack Homer,
Nelson Repenning, Jim Hines, et al. The key questions to consider are
whether the underlying time constant of the switch is very fast with
respect to the rest of the model behavior and whether were modeling one
thermostat or a neighborhood full. Clearly the thermal interaction between
a house and its environment is continuous, so in this case a discrete event
simulation would be a poor alternative to a continuous model with some
discrete switching.
>In the normal residential heating system we dont want the thermostat to
>detect room temperatures to within 0.1 degrees, thus turning the furnace on
>and off minute by minute.
...
>Traditional thermostat:
>Consider a traditional thermostat with a bi-metallic coil. Start with a
>cool room. The coil contracts, hits a contact, turns on the furnace, and
>the room begins to warm. With some delay, the coil begins to warm and
>expand, releasing the contact and turning off the furnace. The room begins
>to cool, starting the cycle again. ...
Its been a while since I had a bimetallic thermostat to fool with, but I
wonder if theres a second mechanism - in addition to the slow-changing
state of the coil - that creates a deliberate dead zone around the desired
temperature. I remember the coil having a pointer on it, which would meet a
contact to the right when warm (switching the furnace off) and to the left
when cool (switching it on), creating the same logic as in a digital
thermostat. Perhaps someone in an old classroom can check.
>Rather than model one stock (room temp) and one on-off switch, I would use
>two stocks. One illustrates room temp, the other illustrates the temp of
>the bi-metallic coil.
>
>The size of the coil, the amount of expansion per degree, etc. will
>contribute to the "lag" in the system, thus damping the response of the
>furnace to very small changes in room temp.
...
>We have thus converted a comfortable system with a +/- 1 degree "dead zone"
>into an uncomfortable system with a +/- 5 degree dead zone. More
>importantly, we have captured the true dynamic structure of the system if
>we model it in this way, rather than by using a mathematical on-off switch
>to simulate the thermostat switch.
>
>Question: Before continuing below, does the above analysis make sense?
The analysis is very sensible, however it seems you still need to compare
the thermostat temperature to the desired temperature, which will require a
logical switch, unless you want to get really complicated and model the
physics of the electrical and mechanical systems of the switch and furnace.
The only way out of IF-THEN logic seems to me to be a furnace that runs at
a variable rate, proportional to the gap between the desired and actual
temperature.
>High Tech thermostat:
...
>(It is possible that this probe was designed with a very small mass and
>therefore a very rapid time constant. If undamped this would lead to rapid
>on-off cycles. OR the mass of the probe might be designed to take this into
>account. I am ignorant about this design issue. Does anyone know the
>answer?)
It seems quite likely that it does have a small mass. There are probably
still delays in the measurement process because the house isnt really a
well-mixed, first-order box of air (or heat). It takes a while for warm air
to move around. Also, theres a delay between the firing of burners and the
startup of blowers or pumps - so the system has a fairly high order if you
get into detail.
...
>e.g. Algorithm says --> If the temp is rising, turn OFF at 71 degrees; if
>the temp is falling, turn ON at 69 degrees.
The algorithm probably actually reads "if the furnace is on, turn it off
above 71 degrees; if the furnace is off, turn it on below 69 degrees."
Theres no way in principle for the thermostat to directly measure the rate
of change of the temperature in the room; this would have to be estimated
by some kind of smoothing or data storage and trend estimation process,
which would be complicated and sensitive to noise. Its much easier for the
thermostat to work with the switch state, which it already knows. Also,
its a good bet that when the furnace is on, the temperature is rising, and
when its off its falling.
>These logic statements would create a dead band of +/- 1 degree around the
>desired temperature of 70 deg.
>
>Back to the philosophy and practice of SD modeling and simulation:In this
>case the "correct" model would explicitly -require- the use IF-THEN
>statements!
Right. The reason IF-THEN logic is frequently shunned in SD practice is
that it is often misused when a decision is heterogeneous. For example, an
IF-THEN statement would be a poor model of the behavior of a neighborhood
of thermostats, as not all of them would be set to the same temperature,
have the same tolerances, etc. If the congregation will now turn to
Industrial Dynamics 5.5,
"Even major executive decision represent a rather continuous process; they
are reached after a period of consideration; advance actions may be taken
in anticipation of the probable outcome; action is not taken immediately
after the decision; and the decision is interpreted and smoothed and
produces gradual change as it overcomes resistance and the inertia of other
persons in the organization."
(See the book for more good details on this).
A traditional alternative would be to create a table function, continuous
between 0 and 1, representing the distribution of on and off thermostats in
the neighborhood at each temperature. A more accurate method would be to
disaggregate the neighborhood, representing each individual thermostat,
with diversity in their target temperatures and physics, but this would be
overkill in most cases.
I think Im overkilling this topic as well, so all for now.
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
****************************************************
-
Jim Thompson
- Junior Member
- Posts: 8
- Joined: Fri Mar 29, 2002 3:39 am
DT and furnace/thermostat models
Jim Hines wrote that Ed Gallahers note on thermostats is "a terrific example of
how most modeling difficulties are resolved when the real-world policies are
understood." Hines says, "I have noticed that its much easier to model after
asking people how they really make decisions, than it is after simply thinking
about either how they **ought** to make the decisions or how I **imagine** I
might make the decision."
Theres at least one more step worth considering. System participants bias
their descriptions, too. After building a model of what the system participant
says about decision-making, its worthwhile to compare model output with
measured data.
I worked with a team of Italian health care system experts to develop a
simulation of how certain hospital bed capacity changed over a thirty year
period. The system participants gave me an elaborate argument to model for how
decisions are made to change capacity. We acquired time series data (hospital
beds are easy to count so there was plenty of reliable data) and compared this
to the output of their model. They were surprised to see that the measured data
didnt match well with simulation results from their description. We modeled a
simpler decision-making structure, were able to track down important reasons for
the data mismatch, and went on to develop a more robust capacity planning
policy.
From: Jim Thompson <jim@globalprospectus.com>
how most modeling difficulties are resolved when the real-world policies are
understood." Hines says, "I have noticed that its much easier to model after
asking people how they really make decisions, than it is after simply thinking
about either how they **ought** to make the decisions or how I **imagine** I
might make the decision."
Theres at least one more step worth considering. System participants bias
their descriptions, too. After building a model of what the system participant
says about decision-making, its worthwhile to compare model output with
measured data.
I worked with a team of Italian health care system experts to develop a
simulation of how certain hospital bed capacity changed over a thirty year
period. The system participants gave me an elaborate argument to model for how
decisions are made to change capacity. We acquired time series data (hospital
beds are easy to count so there was plenty of reliable data) and compared this
to the output of their model. They were surprised to see that the measured data
didnt match well with simulation results from their description. We modeled a
simpler decision-making structure, were able to track down important reasons for
the data mismatch, and went on to develop a more robust capacity planning
policy.
From: Jim Thompson <jim@globalprospectus.com>
-
"Jim Hines"
- Junior Member
- Posts: 15
- Joined: Fri Mar 29, 2002 3:39 am
DT and furnace/thermostat models
Further to Jim Thompsons comments about how to find out how folks really
make decisions.
I recently was involved in a situation where folks just couldnt put their
finger on how they allocated people between the different stages of their
product development process. (Note: These were the folks who actually made
the allocation decisions). We created a small system dynamics model with
the proper stock and flow, but without the policies in it. Then using the
gaming features of our software (Vensim) we met and "actually" managed the
process. The experience was inexpensive, enjoyable, and provided what we
needed to model the essence of the allocation policy.
Regards,
Jim Hines
jhines@mit.edu
make decisions.
I recently was involved in a situation where folks just couldnt put their
finger on how they allocated people between the different stages of their
product development process. (Note: These were the folks who actually made
the allocation decisions). We created a small system dynamics model with
the proper stock and flow, but without the policies in it. Then using the
gaming features of our software (Vensim) we met and "actually" managed the
process. The experience was inexpensive, enjoyable, and provided what we
needed to model the essence of the allocation policy.
Regards,
Jim Hines
jhines@mit.edu