co-flows

This forum contains all archives from the SD Mailing list (go to http://www.systemdynamics.org/forum/ for more information). This is here as a read-only resource, please post any SD related questions to the SD Discussion forum.
Locked
Jack Homer <70312.2217@CompuServ
Junior Member
Posts: 10
Joined: Fri Mar 29, 2002 3:39 am

co-flows

Post by Jack Homer <70312.2217@CompuServ »

In response to Phil Odences question about co-flows: Co-flows are a
perfectly fine and time-honored way to model the accumulation of attributes
(like age or experience) associated with some underlying physical flow (like
people or equipment). They do not conflict with Forresters vision of stocks
and flows, since the co-flow occurs concurrently with the main flow, and is
not causally separate from it. To understand more about the theory and
operation of co-flows, see Appendix Q ("Co-Flows") from my MIT doctoral
thesis:

Homer, J.B. 1983. A Dynamic Model for Analyzing the Emergence of New Medical
Technologies. MIT Sloan School of Management, Cambridge, Mass.

Regards, Jack Homer [70312.2217@compuserve.com]
GR383@albnyvms.Bitnet (George Ri
Junior Member
Posts: 10
Joined: Fri Mar 29, 2002 3:39 am

co-flows

Post by GR383@albnyvms.Bitnet (George Ri »

Mr Odence writes:

>Heres my question: Is there anything fundamentally wrong with a co-flow (a
>rate driven by another rate)? I believe the party line is that such a
>representation is a convenience, and that whats really going on is that both
>rates are being driven by the same stock. I recall that it used to be a
>little tricky in DYNAMO to do this, and that doing so introduced a DT lag,
>ergo there was storage going on, ergo there was really another stock there .
> But I believe that most of todays tools have overcome that issue.

The term "co-flow" usually stands for a formulation crafted to keep track
of an attribute of some quantity that flows and accumulates in the system,
e.g., the book value of inventory, the expertise of a workforce, or the
average interest rate of a banks loan portfolio. It involves a
rate-to-rate connection, but merely as a bookkeeping computation.

The rate-to-rate connection in a coflow is not the difficulty addressed in
Forresters principles of systems that says rates and levels must alternate
around a loop, or that rate-to-rate connections dont exist in reality.
Bookkeeping rate-to-rate connections are fine. But saying, for example,
that management "knows" the current instantaneous rate of production is a
no-no -- there must be information processing lags that mean that
management is basing its perception on information that has to be
accumulated (averaged) somehow, which we frequently capture in a SMOOTH.

>>My feeling is that there are times when a co-flow actuslly gives a more
>realistic or operational picture of the underlying reality than a stock-based
>representation.
>
>There are accounting examples where I think this holds. Isnt is more
>appealing to describe a rate of revenue as =shipments * $ per shipment, than
>to think of revenues as being driven by the level of guys in the shipping
>department? Or, suppose we are hiring and want to track payroll: Increase
>in payroll = hiring * average starting salary. Heres a softer example: To
>model the theory that people learn from experience, wouldnt the rate of
>learning be driven by the rate of experiencing?
>

Id say Mr. Odence is right on -- these are bookkeeping computations where
one flow is simultaneously creating a bookkeeping record directly related
to it. Nothing wrong with this sort of rate-to-rate connection.

But Forresters original prohibition (strong caution) against rate-to-rate
connections is still just as wise as it always ways.

...GPR

.............................................................................
George P. Richardson G.P.Richardson@Albany.edu
Rockefeller College of Public Affairs & Policy GR383@Albnyvms.bitnet
State University of New York at Albany Phone: 518-442-3859
Albany, NY 12222 FAX: 518-442-3398
.............................................................................
POdence@aol.com
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

co-flows

Post by POdence@aol.com »

Prof. Forrester, in his talk at the Power of ST conference, discussed the
fundamentals of System Dynamics. He articulated the elegant simplicity of
the paradigm--the world is made up of levels and rates (or stocks and flows
in STELLA/ithink parlance)...thats it. Levels can only change via rates;
rates are generated by levels.

Heres my question: Is there anything fundamentally wrong with a co-flow (a
rate driven by another rate)? I believe the party line is that such a
representation is a convenience, and that whats really going on is that both
rates are being driven by the same stock. I recall that it used to be a
little tricky in DYNAMO to do this, and that doing so introduced a DT lag,
ergo there was storage going on, ergo there was really another stock there .
But I believe that most of todays tools have overcome that issue.

My feeling is that there are times when a co-flow actuslly gives a more
realistic or operational picture of the underlying reality than a stock-based
representation.

There are accounting examples where I think this holds. Isnt is more
appealing to describe a rate of revenue as =shipments * $ per shipment, than
to think of revenues as being driven by the level of guys in the shipping
department? Or, suppose we are hiring and want to track payroll: Increase
in payroll = hiring * average starting salary. Heres a softer example: To
model the theory that people learn from experience, wouldnt the rate of
learning be driven by the rate of experiencing?

Id be interested in reactions. Or, if this has already been hashed over
somewhere, references.

Thanks,
Phil Odence, HPS
PODENCE@AOL.COM
Locked