MODELS: Producing exact amount

[From Bill Powers (980918.0803 MDT)]

To Bob Eberlein et. al --

Attached is a model that solves a sub-problem within the problem, "How can
I tell when I'm done?" The sub-problem concerns how a production line with
continuous re-working of defective parts can be controlled to produce an
exact amount of acceptable goods without overshooting and without leaving
un-reworked goods in the pipeline.

The model is divided into two parts: the production/repair process, and the
control system that varies the rate of production to bring the total good
items produced to a specified amount. The goods from the production line
have a certain fraction that are defective, and of the defective ones a
certain fraction has to be discarded, the remainder being reworked and
returned to the production line output to be inspected again. It's assumed
that the fractions of defective items are the same after reworking as they
were initially (they could be made different by modifying the model).

The control system perceives the total goods in "OK Goods" and "Goods being
reworked", and tries to keep the total equal to the specified total. At
first, the error is very large, and the output is sufficient to drive the
production line to operate at maximum capacity. Then, as the total items
produced approaches the reference level, the rate of production is slowed
and the reworking catches up to the backlog of items to be reworked. The
production line is slowed to a stop just as the goods to be reworked run
out, and the total number of good items equals the specified amount
(reference level). If the graph parameters don't get transmitted with the
model, plot "Goods OK" and "Goods to be reworked", the two Level variables.

I'm sure I've violated all sorts of conventions, as in converting a rate
variable into a succession of auxiliary variables, but the units check out
so I guess we're basically legal. I haven't used "NSU" in this model, since
Bob seemed dubious about them, but inside the control system I'm THINKING
in NSU, so there.

I think knowing when you're done in this model is pretty simple: you're
done when the error signal or "difference" is zero.

Best,

Bill P.

exact.mdl (58 Bytes)

THIS IS REALLY AMAZING---TRY IT!!! MIND READER BRAIN TEASER
DON'T CHEAT BY SCROLLING DOWN FIRST!!!
It only takes 30 seconds.
And it really works!
Work this out as you read.
Don't read the bottom until you have worked it out!!!
**Follow these 6 steps and this will amaze you...
1.First of all, pick the number of days a week that you would � like
to go out (see a movie, eat pizza, whatever).
2.Multiply this number by 2.
3. Add 5.
4.Multiply it by 50.
5. If you have already had your birthday this year, add
����� 1748. If you haven't, add 1747.
6.Last step: Subtract the four digit year that you were born.
SEE BELOW:
RESULTS:
You should now have a three digit number:
The first digit of this was your original number (i.e. how many times
you
wanted to go out each week.)
The second two digits are your age!!!
It really works!!!
** This is the only year (1998) it will ever work, so spread the � �
joy around by mailing this to everyone you know!!!

[From Rick Marken (980918.0800)]

Bill Powers (980918.0803 MDT) --

To Bob Eberlein et. al --

Attached is a model that solves a sub-problem within the problem,
"How can I tell when I'm done?"

Very nice!

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken

[From Rick Marken (980918.0815)]

Mark Lazare:

THIS IS REALLY AMAZING---TRY IT!!!...

** This is the only year (1998) it will ever work, so spread the � �
joy around by mailing this to everyone you know!!!

Actually, it will work next year if you change step 5 to:

5. If you have already had your birthday this year, add

����� 1749. If you haven't, add 1748.

For each year after 1999 just add 1 to 1749 and 1748, respectively.

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken

[From Bob Eberlein (19980922.1500 EDT)]

Hi Bill,

My apologies for not getting back to you sooner. My normal email service has
been down for about a week.

You were right that the model I sent was a pretty abstract one. I have taken
the model you sent back an changed some things - many of which are just
cosmetic. The model I am attaching is not quite the same, but it is similar.

The cosmetic changes relate to the use of flows that flow into stocks - sort of
standard system dynamics notation. You had some flows that were just added up
to another value.

The more interesting thing is the whole concept of undiscovered defects. These
are things that exist in nature but, because they are undetected, cannot be
acted upon. This model, like the original, has the property that things may
lurk that would require you to go back and do more work. If you make gain
bigger you can get this to happen in a significant way (you need to make
SAVEPER=TIME STEP to really see it).

In this reformulation two interesting things jump out. The first is "defect
discovery," where does this come from? There is a mechanical formula for it
but it is not clear what this means. In parallel to this is "rate of fixing"
- this is more of a conscious decision since there is a tradeoff between fixing
and building. I did not put that tradeoff in - capacity still only impact rate
of production - but we can. When we do we need to decide how to allocate the
resources between the two activities. Is this another control system?

Looking forward to your reponse.

      Bob Eberlein

Bill Powers wrote:

exact2.mdl (59 Bytes)

···

[From Bill Powers (980918.0803 MDT)]

To Bob Eberlein et. al --

Attached is a model that solves a sub-problem within the problem, "How can
I tell when I'm done?" The sub-problem concerns how a production line with
continuous re-working of defective parts can be controlled to produce an
exact amount of acceptable goods without overshooting and without leaving
un-reworked goods in the pipeline.

The model is divided into two parts: the production/repair process, and the
control system that varies the rate of production to bring the total good
items produced to a specified amount. The goods from the production line
have a certain fraction that are defective, and of the defective ones a
certain fraction has to be discarded, the remainder being reworked and
returned to the production line output to be inspected again. It's assumed
that the fractions of defective items are the same after reworking as they
were initially (they could be made different by modifying the model).

The control system perceives the total goods in "OK Goods" and "Goods being
reworked", and tries to keep the total equal to the specified total. At
first, the error is very large, and the output is sufficient to drive the
production line to operate at maximum capacity. Then, as the total items
produced approaches the reference level, the rate of production is slowed
and the reworking catches up to the backlog of items to be reworked. The
production line is slowed to a stop just as the goods to be reworked run
out, and the total number of good items equals the specified amount
(reference level). If the graph parameters don't get transmitted with the
model, plot "Goods OK" and "Goods to be reworked", the two Level variables.

I'm sure I've violated all sorts of conventions, as in converting a rate
variable into a succession of auxiliary variables, but the units check out
so I guess we're basically legal. I haven't used "NSU" in this model, since
Bob seemed dubious about them, but inside the control system I'm THINKING
in NSU, so there.

I think knowing when you're done in this model is pretty simple: you're
done when the error signal or "difference" is zero.

Best,

Bill P.

  ------------------------------------------------------------------------

   exact.mdl Name: exact.mdl
               Type: Plain Text (text/plain)

[From Bill Powers (980923.0935 MDT)]

Bob Eberlein (19980922.1500 EDT)--

You were right that the model I sent was a pretty abstract one. I have taken
the model you sent back an changed some things - many of which are just
cosmetic. The model I am attaching is not quite the same, but it is similar.

It seems to behave the same, which is the bottom line, I guess.

The cosmetic changes relate to the use of flows that flow into stocks -

sort of

standard system dynamics notation. You had some flows that were just

added up

to another value.

I don't quite understand what you're modeling in some of these details. For
example, you have a basic production flow, which enters Goods Produced. But
a fraction, 10%, of the production flow also goes into Goods with
Undiscovered Defects, which actually duplicates some of the goods in Goods
Produced. So we have the same physical objects appearing in two different
parts of the model at the same time.

I think I understand what you're getting at here: the inspection process
that declares some goods as defective doesn't discover all bad goods, so in
the final output some of the goods still carry undiscovered defects and are
sold that way. But I think it's counterintuitive to allow the same goods to
appear twice in the diagram at the same time, when physically they can only
exist once. How do you coordinate the two separate pathways so the same
goods are treated in EXACTLY the same way, as they must be? There has to be
a way to express the condition you're trying to describe without such risky
duplications.

I think what we need is something like this:

goods produced ---> stockpile of goods ---> fraction actually bad ---->
fraction discovered to be bad ---> sent for reworking ---> etc.

In this way, we have a given item appearing only once at any stage of the
process. The items accepted as good (but actually bad) during inspection
are "undiscovered defects" and remain in the output. Only the _discovered_
defects are sent for reworking, where they can be discarded as hopeless or
returned for re-inspection. So an item with an undiscovered defect on the
first pass through the process ends up in the output bin and is sold.

The more interesting thing is the whole concept of undiscovered defects.

These

are things that exist in nature but, because they are undetected, cannot be
acted upon. This model, like the original, has the property that things may
lurk that would require you to go back and do more work. If you make gain
bigger you can get this to happen in a significant way (you need to make
SAVEPER=TIME STEP to really see it).

If you do that, you're in danger of inducing artifacts, oscillations that
are caused by using too large a value of dt (TIME STEP) for the loop gain
(or vice versa -- too large a loop gain for the existing value of dt). No
phenomenon that depends on the size of the time step can be considered
real, in the sense that it's a proper aspect of the simulation. What is
required is a small enough value of dt that reducing it further makes no
discernible difference in the behavior of the model. Then you know that
there are no artifacts due to trying to represent a continuous process on a
digital machine.

Another thing to watch out for is the existence of two or more integrations
in a closed loop. This can easily lead to instabilities even though the
feedback is nominally negative. Of course if the real system is designed
that way, it _will_ be prone to instabilities, so you should model it that
way. But if you're looking for a workable design, you want to keep the
"level" variables down to one per closed loop.

This is why I stayed with auxiliary variables in my model through the
production and inspection phases -- effectively saying that inspection was
happening in real time. Each auxiliary variable depended on a rate
variable, and so still represented a rate or flow. The only actual
integrations occured in the places where the final output was being
accumulated, and where goods to be reworked accumulated. I think that if
you terminate every flow with a Level variable, from which the next flow
departs, you run the risk of producing oscillations by having too many
integrations in one loop. Again, this is OK if there are actually these
accumulations appearing in the real system, but if you're designing a
system to work as well as possible they have to be treated with care.

In this reformulation two interesting things jump out. The first is "defect
discovery," where does this come from?

It happens either during inspection, or when the customer returns the goods
under warrantee. Otherwise, it seems to me that the defects simply go
undiscovered, forever.

There is a mechanical formula for it
but it is not clear what this means. In parallel to this is "rate of fixing"
- this is more of a conscious decision since there is a tradeoff between

fixing

and building. I did not put that tradeoff in - capacity still only impact

rate

of production - but we can. When we do we need to decide how to allocate the
resources between the two activities. Is this another control system?

Yes, I think it is. After all, MOST of the processes in this system have to
be carried out by control systems -- workers and managers. We're just
taking some of them for granted, such as the production line.

Somebody must perceive the rate at which good items are being produced and
the rate at which defects are being discovered, and try to allocate enough
manpower to repairing defective items to keep the backlog from increasing
"too much", whatever that is. The more manpower that is allocated to
repairing defects, the lower the productive capacity is. In effect, the
time to repair depends on the number of people assigned to repairing, while
the rate of production of defective (discovered) goods depends on the
number of people working the production line.

One way to handle the repair rate problem is to set a reference level
(goal) for the repair backlog. This could be a one-way control system: the
backlog is not to exceed N items, and if it does, enough workers are
allocated to repairing items to keep the backlog close to N. If the backlog
falls below N, workers are sent back to production, with some minimum
number staying in the repair department.

Do you want to take the next hack, or shall I?

Best,

Bill P.

[from Bob Eberlein [1998.0923.1522 EDT]]

Hi Bill,

Thanks for your comments. You are right that the conservation of items
is hard to follow. I have rewritten the model to make this cleaner.
Note that in this model only "goods apparently done" is observable.
Both of the Levels are hidden.

I have left in the "rate of fixing" as it was but used that to take away
from capacity for new production. The formulation is actually
consistent with your description of the process for getting fixing done
but could possibly use some reformulation.

This is intended as a descriptive not a prescriptive model. Thus the
actual behavior of the model is not something I am trying to control.
My real purpose here is to understand how you might break out and
represent some of the decision making that is inherently going on. If
we can do this without getting too much more granular on different
pieces of the model that would be great.

    Bob Eberlein

PS Levels are put in boxes because they look like tanks and the rates
like pipes with valves. The identification of Levels is an important
part of the pedagogy (an also religion) of system dynamics.

exact3.mdl (59 Bytes)

[From Bill Powers (980924.0249 MDT)]

Bob Eberlein [1998.0923.1522 EDT] --

Hi, Bob --

Thanks for your comments. You are right that the conservation of items
is hard to follow. I have rewritten the model to make this cleaner.
Note that in this model only "goods apparently done" is observable.
Both of the Levels are hidden.

Excellent, much clearer. "Conservation", eh? Good way to look at it.

Your new diagram teaches me how to handle flows better. I see that it's
possible to split flows. To make this even more explicit (I always like
that because if it ain't explicit, I'm going to forget it) we could take
"fraction defective" and create another parameter, "fraction OK", with
fraction OK being 1 - fraction defective -- conservation of flow. Then the
flow into Goods with Undiscovered Defects plus Non Defective Goods would
always equal total throughput.

But ...

I would now like to propose deleting "Goods with Undiscovered Defects" in
the interests of simplifying the diagram even further. The problem with the
model as it stands is that there is a division of total throughput into a
flow of goods with no defects and a flow of goods with undiscovered
defects. But there is no physical place where Goods with Undiscovered
Defects, in particular, can accumulate. There is, in fact, only one flow of
goods, containing both good items and defective items. Until inspection
takes place, these goods are not differentiated from each other into
physically distinct flows: the flows in your diagram are conceptual rather
than physical. Or rather, conceptual and physical flows are mixed together.
I think we should stick strictly with physical flows, because conceptual
flows are in the mind of the observer.

I believe that the problem of "undiscovered defects" can be handled much
more simply. Start with the total throughput of goods off the production
line.
Some of these goods are actualy defective, the rest are actually OK, but
until there is an inspection there is no difference.

An inspection process now picks items out of the total flow and sends them
to two Level destinations: Apparently Non Defective Goods and Goods To Be
Fixed.
The inspection process has four outcomes:

Flow 1. Actually OK, passed as OK
Flow 2. Actually bad, passed as OK
Flow 3. Actually OK, sent for rework
Flow 4. Actually bad, sent for rework

Conservation says that the fractions of goods in all four categories must
add up to 1. It is to be hoped that the fractions in 2. and 3. are small,
but we have to allow that they may be nonzero. There is conservation
between 1 and 3 for actually OK items, and between 2 and 4 for actually bad
items. The goods with permanently undiscovered defects are those in 2,
which flow into Apparently Non Defective Goods, ANDG. Ultimately, all
produced goods that are not discarded end up in ANDG.

I have left in the "rate of fixing" as it was but used that to take away
from capacity for new production. The formulation is actually
consistent with your description of the process for getting fixing done
but could possibly use some reformulation.

Yes, let's do it. Let's say there is a Total Workforce, with a variable
number of "producers" that works on the production line, and "fixers" that
work on the repair line, with producers = Total Workforce - fixers. We have
a controller whose job is to vary the value of "fixers" to keep the backlog
in Goods To Be Fixed at zero. The gain of this control loop can be rather
small, because it's not important if the backlog grows to some modest
number of items. The rate of fixing items will be some constant times the
number of fixers, and the rate of production will be some constant times
the number of producers.

We can do an elegant thing with these two control systems. The manager who
is concerned with meeting the contract goal of N total items perceives the
variable that is the sum of the two Goods level variables. This manager's
action consists of varying the fraction of the Total Workforce that is
available for work; as the production goal is approached, temporary help is
laid off or workers are reassigned to other projects, so the rate of
production slows down. Production rate is number of producers times
productivity per producer in items per month.

The manager who is concerned with keeping the backlog at zero has available
an Effective Workforce, from which workers can be shifted to the repair
line as this manager's means of trying to keep the backlog at zero. The
first manager is not concerned with where the Effective Workforce is
actually working; the individuals are sending items to the final output no
matter which line they are working on. So these two managers can work
independently but without conflict, because they are controlling different
perceptions.

Over to you.

Best,

Bill P.

[ From Bob Eberlein [19980924.1436 EDT]]

Hi Bill,

But ...

I would now like to propose deleting "Goods with Undiscovered Defects" in
the interests of simplifying the diagram even further. The problem with the
model as it stands is that there is a division of total throughput into a
flow of goods with no defects and a flow of goods with undiscovered
defects. But there is no physical place where Goods with Undiscovered
Defects, in particular, can accumulate. There is, in fact, only one flow of

I think you are mixing up "observable" with "physical." While it is
true that in the warehouse the not-so-goods are jumbled up with the
just-fine-goods this does not mean that there are not two seperate
quantities. If you were two stop time and, omnisciently, go in and
inspect every item you could count the number of good items and the
number of defective items. This is one of the tests for a Level - both
are. The fact that they are intermingled does mean that the diagram is
a weak physical anology to the operating real world system. This is one
of the reasons system dynamics and PCT are not things that everyone
instantly understands. Any decent conceptual representation of almost
any system needs to include stuff that is not directly observable.

I believe that the problem of "undiscovered defects" can be handled much
more simply. Start with the total throughput of goods off the production
line...

To change the model so that the inspection is done as part of the
manufacturing process is a something that is done to reflect how things
actually work. We can't do it because the model seems too messy as it
stands. Given the genesis of this model we don't really have a real
system against which to refer it. The model started out as a project
model and was transformed into a production model for pedagogical
reasons.

Yes, let's do it. Let's say there is a Total Workforce, with a variable

OK - I have attached exact4 that more or less does this. Take a look at
the control systems and the way their output is used to see if you like
it. I have the control systems being used to set targets - perhaps you
would like to see them act directly on changes in the values for
workforce and the fraction fixing.

The behavior of this model is probably not what you expect. The
fraction fixing goes constant early on, and it takes a long time to
finish the production run. What are your thoughts on this?

           Bob Eberlein

exact4.mdl (59 Bytes)

[From Bill Powers (980925.0035 MDT)]

Bob Eberlein [19980924.1436 EDT]--

I think you are mixing up "observable" with "physical." While it is
true that in the warehouse the not-so-goods are jumbled up with the
just-fine-goods this does not mean that there are not two seperate
quantities. If you were two stop time and, omnisciently, go in and
inspect every item you could count the number of good items and the
number of defective items. This is one of the tests for a Level - both
are.

Both are levels, right. I'll go along with all this. I think I understand
how "Goods with undiscovered defects" ends up going into "Goods apparently
done" -- it's a bit tricky to see that the arrow from the undiscovered
defects to goods apparently done is what's left over after the discovery
rate is subtracted, so it represents the goods that have defects that
escaped detection.

The meaning of "capacity" has changed since I used it in an earlier model.
When the manager was simply determining production rate, I used "capacity"
as the limit, the maximum possible production rate with the line running at
100% capacity. If the manager called for a higher production rate,
production simply stayed at the limiting rate. This is why the number of
items increased along a straight line at first: production rate was constant.

In the present model, "capacity" is now determined by the number of workers
and their productivity. There's no limit corresponding to my earlier use of
the term "capacity." I think, however, that we can put an appropriate limit
in, by saying that higher management limits the total workforce to (let's
say) 200 workers. If the manager of the production line sees a very large
difference between total goods desired and the total produced so far, his
control system would call for many more workers than the maximum --
however, the maximum is 200, and the total number of workers will remain at
200 until that manager's error is small enough that he starts calling for
fewer than 200 workers.

I now realize that there's something I don't know how to do in Vensim. I'll
go along with your making Total Workers into a level variable, but we need
a way to limit the integration to a value of 200 workers (like a tank
that's brim full and can't hold any more). How would you do this? Would the
limit have to be put on the "target workforce?" I'll assume that's the answer.

The reason we need this limit is so the line will work at nearly the
maximum possible speed until the total production comes close to the
desired number of items. There is no need for the approach to the final
amount to be so slow. The slowness is caused by the fact that the error
which is determining the number of workers starts to fall as soon as the
goods begin to accumulate, slowing production. It's as though you started
to slow down for a stop sign as soon as you saw it six blocks away.

We can actually make the approach to the final number of goods as fast as
we like by increasing the gain of the control system. Right now, it's 0.1.
If you raise it to 0.5, the approach to the final number will be five times
as fast. But the total number of workers will, at the peak, also be 5 times
as great, and production will still slow long before it needs to.

I think it's realistic to say that this manager does not have an unlimited
number of workers at his disposal. I'm proposing a limit of 200, although
you could use any number that is appropriate. So the maximum possible rate
of accumulation of goods, OK and not-OK together, is the productivity per
worker times 200 workers. When the total number of goods nears the final
number, this manager can call for fewer than 200 total workers, but can't
call for more than that.

Now the allocation of some of the total workers to repair work will
slightly decrease actual production below the maximum possible rate, but
this is unavoidable unless we decide to scrap all goods found to be
defective -- which, in effect, is a reduction in productivity and also
reduces the rate of production of good items. In fact, with a defect rate
of 10%, the number of repair workers for most of the time is 20, (or maybe
18?) while the number of building workers is 180.

The behavior of this model is probably not what you expect. The
fraction fixing goes constant early on, and it takes a long time to
finish the production run. What are your thoughts on this?

I've essentially covered this above. I'm attaching your exact4.mdl with a
few changes:

The target number of workers is limited to 200.

Productivity per builder is set to 1 (to make maximum production rate
faster, don't ask me why)

Gain is raised to 0.5

Fix Gain is raised to 5 (both gains up by a factor of 10)

Building and fixing workers are prevented from going negative (which they
could because of imposing the limits on number of workers)

The TIME STEP is reduced to 0.025 (to avoid artifactual oscillations)

Now the behavior of the system looks as speedy as possible.

Best,

Bill P.

exact41.mdl (60 Bytes)

[From Bob Eberlein (1998.0926.1030 EDT)]

Hi Bill,

In the present model, "capacity" is now determined by the number of workers
and their productivity. There's no limit corresponding to my earlier use of
the term "capacity." I think, however, that we can put an appropriate limit
in, by saying that higher management limits the total workforce to (let's
say) 200 workers.

We are actually converging on some pretty classical formulations here.
For clarity I would include "Workforce Cap" as a separate variable but
the results are the same. The two control structures are also
consistent with classical system dynamics formulations. The main
differnce being that you have:

target workforce = MIN(200,difference * gain) ~ worker ~|
gain = .5 ~ worker/item

And the system dynamics formulation would be

target workforce = MIN(workforce cap,target production / expected
productivity ~ worker ~|
workfoce cap = 200 ~ worker ~|
expected productivity = 1 ~ item/week/worker ~|
target production = difference / time to complete production ~ item/week
~~|
time to complete production = 2 ~ Week ~|

Essentially there is a lot more verbosity around how the information is
processed. The numbers, however, are identical.

Why don't we get started on a calibration problem for a simple and
classic PCT model. I can walk through the mechanics of executing this
and also try to see if there are ways to more clearly (at least from my
perspective) present the model using system dynamics diagramming
conventions.

      Bob Eberlein

[From Bill Powers (980927.1040 MDT)]

Bob Eberlein (1998.0926.1030 EDT)

Why don't we get started on a calibration problem for a simple and
classic PCT model. I can walk through the mechanics of executing this
and also try to see if there are ways to more clearly (at least from my
perspective) present the model using system dynamics diagramming
conventions.

Coming up. Got to work up a writeup to go with the program. Attached are
the Pascal source for a program that takes data and saves it as an ascii
comma-delimited file in c:\rundata.txt, and the runnable program
(tracker1.exe). Also attached are some Pascal units for graphics
(grutils.pas) and mouse reading (mouse.pas). If you can read Pascal (I
don't doubt that you can), maybe you can get a head start.

Best,

Bill P.

Tracker1.pas (61 Bytes)

Grutils.pas (60 Bytes)

Mouse.pas (58 Bytes)

Tracker1.exe (61 Bytes)