Models with Sectors and Multiple Authors

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
Niall Palfreyman
Senior Member
Posts: 56
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by Niall Palfreyman »

Andy Ford schrieb:
> We managed to keep the sectors integrated in a
> manner that led to insights, not confusion...

I have long thought that object-oriented modelling and system dynamics
had much to learn from each other. In particular, several stocks in a
model are often attributes of a single "object", and several flows are
processes linked to a single "object".

What Andy describes here are precisely the fundamentals of OO modelling:
First analyse the model as a set of use-cases which thread through the
model as it is seen by actors lying outside the system, then seek the
classes of objects which must communicate with each other to support
these use-cases.

In the context of system dynamics modelling, the use-case corresponds to
the reference mode which drives the entire modelling process. Also, at
the heart of object-oriented modelling lies the idea of an ADT (Abstract
Data Type). An ADT defines the communications processes between objects
in a system, while leaving the internal implementation of the objects
undefined. This means that separate developers can work simultaneously
on the design of separate objects in the system, knowing that they share
a common understanding of the interface between their separate
components. Larger scale modelling is supported in UML (Unified
Modelling Language) by "packages", which would broadly correspond to
"sectors".

There is a new journal starting from Springer in September called
"Software and Systems Modeling". My hope is that this will bring several
groups of modellers together to learn from each other. You can find out
more about this journal at:
http://www.sosym.org/

Best wishes,
Niall.
From: Niall Palfreyman <niall.palfreyman@fh-weihenstephan.de>
"Andy Ford"
Junior Member
Posts: 10
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by "Andy Ford" »

Jim,

This is Andy Ford responding to Jim Hines question about how to put a
team of people to work effectively on a large model without assigning a
different person to each "sector" of the model. Jim is properly worried
that the final assembly of the sectors will be difficult and confusing. He
invites "defenders of sectors" to get their licks in. This message speaks
"in defense of sectors."

I have worked on several modeling projects in the energy business
with teams of people. A typical team might be 3 people, with the model
conceived as 3 sectors. We managed to keep the sectors integrated in a
manner that led to insights, not confusion. In relecting on our approach
(in light of Jims question), I believe the key to our approach was a
working model at the outset of the project. We always had a small,
demonstration version of a model that was shared with the client and among
the members of the team. The "demo model" might have 3 sectors, and the key
feedback loops that tied the three sectors together were closed. When the
team of 3 individuals went to work expanding each of the 3 sectors, they
launched their work with a shared understanding of how the 3 sectors would
be tied together. They also had a shared understanding of the unit of time
(ie, days, months, years?), the time horizon, and the "reference mode" for
the integrated model.

I think the collection of global models (from "World Dynamics" to
"Limits to Growth") provides another example of a productive team with
members assigned to different sectors. The "World3" model described in
"Limits to Growth" was constructed by a team of people with different
members assigned to different sectors (ie, the resources sector, the
demographics sector). This team had the benefit of Forresters "World
Dynamics" model as a starting point which contributed to their success.
The approach taken in world modeling projects is documented and interpreted
by Jorgen Randers in his doctoral thesis.

Andy Ford
Program in Environmental Science & Regional Planning
Washington State University
Pullman, WA 99164-4430

Phone: 509 335 7846
Email: FordA@mail.wsu.edu
Web: http://www.wsu.edu/~forda
"Raymond T. Joseph"
Junior Member
Posts: 17
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by "Raymond T. Joseph" »

Heres one for the sectored approach. (I hope I have the same concept of
sectored as previously presented.)

I have facilitated the development of many large-scale industrial models
utilizing many modelers operating in parallel to shorten the overall project
duration. There are a few advantages to this approach that I would like to
point out:
1) With the model broken up into smaller blocks, it is easier for a modeler
to understand what is going on in their block.
2) The block model facilitates overall understanding of the model. Rather
than trying to comprehend the vast interactions of the individual, basic
components of the model, an analysis now can be viewed with many fewer
interactions between dynamic blocks.
3) Management (maintenance) of the model is facilitated with the block mode
because documentation can be focused on smaller objects. Similarly, tuning
of block parameters for calibration and model validations are simplified by
addressing smaller subsystems. Management tools can be configured to
individually address the smaller blocks.

Model development using blocks suggests that there is some underlying
segregation of the components and connections that should be followed in
defining the blocks. This is typically done with a few people (as compared
to the entire modeling team), some domain experts and at least one modeling
facilitator.

If the segmentation is not obvious or was initially inappropriate, new
knowledge gathered during the detailed modeling process may be utilized to
redefine the block structure and definitions.

If the underlying blocks for the model are not readily discernable, linear
graph theory may be utilized to help characterize the segmentation. This
involves building a network of the known components and connections for the
overall model. Such a network has an associated adjacency matrix that
defines which nodes (connections) are next to each other. The structure of
the adjacency matrix provides a picture as to the distance between
connections. Thus blocks may be defined for groups of connections which are
close.

Once a model is segregated into appropriate blocks, the rest of the process
is well defined and progress can be readily tracked to assure successful
project completion.


Raymond T. Joseph, PE
rtjoseph@ev1.net
Aarden Control Engineering and Science
"Jim Hines"
Senior Member
Posts: 88
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by "Jim Hines" »

Andy,

Very interesting! Starting with a demo model that has "mini" versions
of the sectors all tied together with the major feedback loops is neat.
I can see how that would work.

How do you coordinate the sectors. For example, as sectors get
built-up, do you update (what was) the "mini" model from time to time
with the growing sectors? If so how frequently? Do the people
extending the sectors do so in a model that includes the (growing?)
"mini" model?

Jim
From: "Jim Hines" <jhines@MIT.EDU>
"Jim Hines"
Senior Member
Posts: 88
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by "Jim Hines" »

Raymond,

Its very nice to hear from someone as experienced as you. Is your
experience specifically with system dynamics models or with other kinds
of models? In reply to your points:

Of the three benefits you mention, the only one I wonder about as I try
to imagine what youre doing is the second one about sectors helping one
to get an understanding of the model. I actually agree with this one
too, but just want to recognize (as Im sure you do, too) that the
dynamics of interest will often be caused by one or more feedback loops
that cut through a number of sectors.

You mention that the approach you need requires some natural
"segregation" of the sectors (i.e. blocks). It sounds like youre
looking for a "sectorization" that minimizes connections between
sectors. That would help the problem that I mentioned in the earlier
email -- but the number of feedback loops that can be created even
through one or two links between each of a number of sectors can still
be huge, so my concern doesnt vanish.

You mention using an adjancy matrix to find the sectors. But, how can
you do that before you have the model? Do you create a simple version
of the full model that shows major variables and connections, but which
has no equations?

Jim Hines
jhines@mit.edu
"Jim Hines"
Senior Member
Posts: 88
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by "Jim Hines" »

Nail Palfreyman suggests that object-oriented modeling and SD have a lot
to learn from each other.

My guess at this point is that an object oriented modeling approach
might work well when you are building a model of a type you are already
quite familiar with.

I speak a little from experience: I built an object oriented SD model
(using smalltalk) some years back for a large telecom company. The
Object-oriented approach worked because Id built and analyzed similar
models before. (The model was a project model which I was lucky enough
to have learned about from the masters at Pugh Roberts).

Knowing about project models meant that I had a clear idea of the level
of aggregation for each object, and I knew the important loops that
would be cutting through each object. Without this knowledge, I dont
think the project would have been possible.

The problem in object oriented terms is that without knowledge of
project models, I wouldnt have been able define in advance the
interface to each object. When building an SD model "from scratch", you
typically want complete access to each "objects" internal state -- this
is sacrilege in object-oriented programming.

Interestingly, Andy Ford mentioned that the Limits to Growth (World3)
modelers (who took a sectoral approach) were quite familiar with Jays
earlier World Dynamics model and my guess is that Jays model served the
same purpose for those modelers as the project model did for me. Maybe
Andy can comment.

So: Right now Im thinking an object oriented approach to modeling is
an OK (or maybe even good) choice when creating a model of a type with
which one is already familiar.

Jim Hines
jhines@mit.edu
"Raymond T. Joseph"
Junior Member
Posts: 17
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by "Raymond T. Joseph" »

Jim,

<snip>
> that the dynamics of interest will often be caused by one or more feedback
loops that cut through a number of sectors.

There are numerous ways to present and represent a model. If the model can
be presented in such a way that others are able to comprehend the overall
connectivity of the model, then everyone may take a step forward. If we
cant present a comprehensible overview of the model to others, the forward
path is blurred. By minimizing the number of components and connections in
the model overview, we enhance the ability to communicate the essence of the
model to others.

This can be done with out knowing any equations. One only needs the
relative functional relationships between the components. This is a
prototype and should be used as such. As knowledge of the model is gained,
the prototype should be modified to keep track of the development. At some
point, this prototype will be part of the specifications to the modelers for
developing their components. Such a model should be converted to a linear
graph to keep track of the mathematics of the connections, at least. It can
also be used to reduce the computational complexity of a model.

I like to find ways to contract the block-overview to less than eight
components. Most all of us can conceive of eight items at once. If the
count is beyond that, few people can really comprehend it.

So, we use what ever tools are available to shrink the presented view of the
model to a limited number of components and connections. This limited
overview will be expanded later, but any such expansion is a map with no
intention of conveying an overall meaning.

The fact that a particular gain path (whether feedback or feedforward) cuts
through multiple sectors does not detract from the advantages of the
contraction process; it typically enhances the understanding. To fully
understand a system, a modeler should be able to present a model of the
system from a simple, one component input/output diagram, through various
expansions of detail to a fully detailed representation. As a modeler
expands the model detail such that a particular gain path appears at some
expansion level, this is typically the simplest level to explain/identify
the properties of the that gain path.

Yes, you are correct, minimizing the number of connections in a gain path
does not eliminate the path. But hopefully, one is able to simplify the
connections sufficiently to help others better understand their role in the
model development process.

Ray
From: "Raymond T. Joseph" <
rtjoseph@ev1.net>
"Raymond T. Joseph"
Junior Member
Posts: 17
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by "Raymond T. Joseph" »

I concur with Nail Palfreyman suggestion that object-oriented modeling and
SD have a lot
to learn from each other. One of the key lessons is that code should not be
jumped into. Any project should undergo a structured analysis.

UML can provide such structure (
www.uml.org). And it is well suited to the
discovery process such as when a system being described is unknown to the
modelers. There is a huge overhead to using UML. But the overhead is
quantifiable. Not using UML carries a huge risk. The risk is quantifiable.
Now doesnt this sound like the ideal SD problem - risk management!

The overhead with UML typically comes at the beginning of a project. And
depending upon the participants, can end up costing less overall due to the
built in capabilities of specification capture, team communication
requirements, and the ongoing ability of change management.

OK, so how much does one need to know before going into a project? One
should know everything - of course. But this is rarely the case and usually
not the preferred presentation. Lets say one comes into a group as a
consultant to facilitate the model development process. It is not even
necessary that this consultant know anything about the particular field. It
is up to the consultant to find the domain expertise in the group or to go
outside the group to get it. The consultant needs to consider the personal
dynamics of this situation. Just giving answers can undermine the perceived
position of domain experts with in the group. As such, the modeling
consultant should bring everyone along the discovery process. Let the team
discover and take ownership of the model structure. This may seem like a
contrivance at first (which it is) but it also forces the group to address
the entire model taking nothing for granted. This approach also allows the
UML documents to be filled out in total so there are no holes in the
development process and the resultant specifications.

If the initial pace of the development process can be pushed, there will be
a tendency to produce a high level view of the model. Hopefully, this pace
can be maintained to completely gloss over the top view of the model. As
time progresses more detail will be exposed. Either way, a model hierarchy
can be developed which will provide a sufficiently simple model for
presentations and appropriately detailed model for computation.

Ray Joseph
rtjoseph@ev1.net
"Chariya Peterson"
Junior Member
Posts: 7
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by "Chariya Peterson" »

Alan Graham
Member
Posts: 27
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by Alan Graham »

Jim, Niel, et al.

Two broad areas of comment: my empirical guidelines for multi-author work at
different phases of model maturity, and commonality with software
development concepts.

MULTI-CONTRIBUTOR WORK...

...based on a few less-than fun experiences and several good ones. The
overall concept is that collaborating model-builders need a far more
explicit and well-understood understanding and framework than will at first
seem apparent. Specifically:

1. Before coding, have a block diagram, most of the data, and a causal
diagram that emphasizes the major loops, and take these through multiple
iterations, checking assumptions against data and the experience of expert
participants in the problem domain. (See my Palermo paper with Carlos Ariza
for additional discussion). This lets individual model-builders know whats
supposed to be represented in each portion of the model, and at least
roughly how they interact.

2. Do a minimal model first (per Jim Lyneis SDR article "SD for strategy",
with its "phased approach), because among other things, multiple model
builders will discover more interconnections than was first anticipated.
Better to discover these early.

3. Test, calibrate and integrate sectors (10-30 equations) of the minimal
model one at a time. Use approximate data (real or assumed) to substitute
for inputs not created yet by dynamic structures. This allows several
people to be developing sectors, and one person at a time to be adding a new
sector to the emerging minimal model. The sectors are small, so adding each
piece of structure is the work of a day or two. For less-experienced
modelers, theres probably an argument for sequentially adding the feedback
loops within each sector. But experienced modelers tend to break tasks into
a size that experience says they can be confident in (and can test), which
in a minimal model is usually the whole sector. Note that with this
process, the model may be incomplete, but is always at least approximately
calibrated.

4. Exercise the hell out of the minimal model for policy analysis
(sensitivity, Monte Carlo, optimization under multiple scenarios), and
review these with domain experts. This is both a step for buy-in to
insights from the present model, and eliciting and prioritizing the policy
issues and model shortcomings that the model builders will need for the next
round. (This is model testing of the whole minimal model; individuals may
be tempted skip ahead to elaborating sectors, but this constitutes building
on top of structure not yet well-tested, validated or understood. I call
this "modeling beyond your knowledge", and try very hard to discourage it.
Its kind of like "driving beyond your headlights".)

5. Individuals can refine/elaborate different sectors, as always putting
them back into a tested base model each time, re-testing.

Note that under these guidelines, never do two individuals take untested
work product and hook them together "and then debug". In my 30 years of SD
experience, that has never worked efficiently. If there is time pressure,
its better to be hasty in constructing the little pieces, and be cautious
about testing and assembling them, so that flaws are discovered and
corrected in the simplest possible setting.



CONCEPTS THAT HAVE TRANSFERRED FROM SOFTWARE DEVELOPMENT...

...in at least PA/Pugh-Roberts. They include:

1. unit test (which I believe John Morecroft wrote about in the 1980s, under
a different name)
2. objects / modules (a.k.a. the traditional sectors, subsectors
subsubsectors in DYNAMO, or slightly younger atoms and molecules in various
packages, or the software-supported "groups" of Jitia)
3. integration (adding modules/objects one-by-one, in a systematic way,
testing as you go)
4. checkout from the software library ("Im working on this sector and
nobody else should make changes")
5. version control (all files with the same name are identical, and we know
exactly how successive versions differ, and who made the changes and why)
6. spiral development (first we do a "mini" model, then build on it)
7. block development (we build a basic model, then we add structures that
support additional functionality)
8. regression testing ("after we modify it, does it still pass the same set
of tests it did before?")
9. program stubs (known in MIT National Model days as "test generators" --
extremely simple structures to generate needed input, either an exogneous
input, or very high-level, simple feedback, like one table function)

cheers,

alan
From: Alan Graham <
Alan.Graham@paconsulting.com>
Khalid Saeed
Senior Member
Posts: 79
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by Khalid Saeed »

Dear colleagues,

As some one who has developed many "country-related" models, Id like to
say that one must start with a clear articulation of a problem to identify
the model boundary not with a model or submodels.

The model representing a country-specific problem might share generic
elements with another model, but Id strongly advise against starting from
a model or collection of submodels since these may not contain the decision
space relevant to the problem at hand.

I must add that problem articulation is also not a simple process and I
have struggled with describing this process over the past several years.
Following working paper is the most recent iteration of my attempts at it
and Ill be happy to make a pdf version available to any one interested on
request.

Saeed, K. 2002. Articulating developmental problems for policy
intervention: A system dynamics modeling approach. Prepared for IFORS
conference. Univ of Edinburgh. July 2002.

Khalid Saeed
saeed@wpi.edu
"Andy Ford"
Junior Member
Posts: 10
Joined: Fri Mar 29, 2002 3:39 am

Models with Sectors and Multiple Authors

Post by "Andy Ford" »

This is Andy Ford responding to Jim Hines questions about the coordination
of a team effort to expand a "mini" model. I can share my experiences based
on a long running project to develop a model of the electric power system in
the Pacific Northwest.

The team was comprised of model "developers" located in California and
Virginia and model "users" located at the Bonneville Power Administration in
Portland, Oregon. The initial model was comprised of 4 or 5 interconnected
"sectors. It was implemented in Dynamo and produced dynamic behavior of
interest to Bonneville. All members of the team had copies of the initial
model. We called it a "demo" model, but Jims "mini" model term is
descriptive. To be useful, Bonneville wanted to see the "mini" model grow
in complexity. Interestingly, the complexity Bonneville was looking for
might be called "categorical complexity." We added more and more categories
to make the policy simulations more relevant and more concrete. Along the
way, the feedback loop structure and the "dynamic complexity" was increased
in only a modest manner.

Are there good guidelines for managing such a process? Alan Grahams recent
message provides an excellent list. I wish we had his list when we started
the Bonneville project. I believe everyone on our team would endorse Alans
advice to "Exercise the hell out of the minimal model for policy analysis."

Jim Hines asks if team members should work on their individual sectors
within a common copy of the "mini" model. That was our approach in the
Bonneville project. Everyone had a working copy of the model, and it was
important to work with a carefully "frozen" version that matched
documentation shared among the team members. Model "developers" (in
California and Virginia) would work on expanded versions of different
"sectors" while the model "users" (in Oregon) worked with the frozen version
of the "mini" model. Around every 18 months or so, the entire team
"graduated" to a new, larger version of the model. The timing was
sometimes tied to the Bonneville planning cycle or funding cycle. At other
times, the team members all adopted a new version of the model to take
advantage of a major advance in system dynamics software.

Thats my story, told from the perspective of one of the model "developers."
The larger story should be told by Mike Bull, the Bonneville planner who saw
the power of system dynamics to complement Bonnevilles ways of thining
about the northwest power system.

Andy Ford
Program in Environmental Science & Regional Planning
Washington State University
Pullman, WA 99164-4430

Email: FordA@mail.wsu.edu
Web: http://www.wsu.edu/~forda
Locked