Converting a Sector-based Model to Modules
I generally do not use modules to build very small models (only a couple of stocks and flows), which may then lead me to use sectors as the model grows because they are very convenient. By the time I have three sectors, though, it starts to become clear that I should have used modules. I will then need to convert my sector-based model into a module-based model. Historically, I also have a number of sector-based models that are crying to be module-based.
Converting from sectors to modules is not very difficult:
- Make sure there are no connections or flows between sectors. Replace any of these with ghosts in the target sector.
- In a new model, create one module for every sector.
- Copy and paste the structure from each sector into its corresponding module.
- Connect the modules: At this point, the model structure has been rearranged into modules, but none of the modules are connected. The ghosts that were in the sectors became real entities when they were pasted into the modules. Go back to identify all of these connections and reconnect them in the module-based model.
Stepping Through a Sample Model
Let’s walk through an example. A small sector-based model is shown below (and is available by clicking here).
This model violates what I would call good sector etiquette: there are connectors that run between the sectors. This is often useful in a small model such as this because it makes the feedback loops visible. However, in a larger model, this can lead to problems such as crossed connections and difficulty in maintaining the model because sectors cannot be easily moved.
Eliminating Cross-Sector Connections
To convert this sector-based model to modules, it is first necessary to remove these cross-sector connections. This is done with the ghost tool. The stock Population needs to be ghosted and placed in the Resources Sector and the stock Natural Resources needs to be ghosted and placed in the Population Sector. The end result is shown below.
Creating the Modules
We are now ready to create, in a new model, one module for each sector, using the Module tool. The result is shown below. Although you could manually draw the connections between these modules, we will let the software create the connections for us.
Each module needs to be associated with its own model file. This is done by double-clicking on each module and choosing “Create Model…”. Double-click Population, choose “Create Model…”, and name the model file “Population”. Repeat for Natural Resources, but name the model file “Natural Resources”.
Pasting Structure into the Modules
It is now a simple matter to paste the structure from each sector into each module. Using the selection tool in the sector frame, select all of the structure in the Population Sector and copy it by choosing Edit->Copy. Open the Population module in the new model and paste in the structure by choosing Edit->Paste. The module contents will appear as shown below. Note that Natural Resources is no longer a ghost; there is no connection to the other module.
Repeat this process with the Resources Sector and the Natural Resources module. The module contents will appear as shown below. Note that Population is no longer a ghost.
Connecting the Modules
All that remains is to connect the modules. Inside the Population module, the stock Natural Resources needs to be replaced with a ghost of the real stock. Inside the Natural Resources stock, the Population stock must be replaced with a ghost.
There are two ways to do this: manually or semi-automatically with the Ghost tool. I tend to use the Ghost tool most of the time. [The documentation chapter “Using Modules to Communicate Between Modules” (available by clicking here) explains how to forge these connections manually.]
To connect the modules, first go into the Natural Resources module and select the Natural Resources stock with the Ghost tool. Go up one level and then down into the Population module. The cursor should still be a stock. Click next to the existing Natural Resources stock to deposit the ghost. Run a connector from the ghost to resources\person (as the stock does) and then delete the stock. Drag the ghost over to approximately where the stock was. Open resources\person and press “OK”. An error will appear and “Natural_Resources” will be selected. This happens because Natural Resources is no longer connected to resources\person. Click on the ghost’s name (Natural Resources.Natural Resources) in the “Required Inputs” list and press “OK”. The Population module is now properly connected to the Natural Resources module.
Repeat this process to connect a ghost of the real Population stock to the Natural Resources module. After finishing, the Population module contents appears as shown below. Note that Population has a double border to signify it is providing its value to another module.
The contents of the Natural Resources module appears as shown below. Note the double border around the Natural Resources stock, signifying that it is providing its value to another module.
Finally, returning to the top-level, we see that the software automatically created the required connections between the modules. Below, the connections have been embellished with their polarity to make the balancing loop obvious. [The final model is available by clicking here.]
A Cautionary Tale
This mechanical process for converting a sector-based model to a module-based model is very appealing due to its simplicity. It works very well with models that have a small number of sectors (up to about five), but will fall apart beyond that.
Last summer, I helped Khalid Saeed (Worcestor Polytechnic Institute) convert a sector-based model of Jay Forrester’s Urban Dynamics model to modules. A direct translation using the above process led to the following top-level diagram:
It should be clear that everything is connected to almost everything else. There is no way to rearrange this diagram to clear up this mess. For a short time, I flirted with the idea of module ghosts as a solution, but it does not take too long to see that ghosts cannot solve this problem either (indeed, they make it worse).
Recently, I decided to follow my own advice on module hierarchy (see this post). I also remembered the famous article “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information” by G.A. Miller (1956). It explains that we cannot keep more than five to nine things simultaneously in our heads, depending on the person. So I may be able to absorb the meaning of a diagram with seven modules, but someone else may only be able to understand one with five modules. For this reason, we should strive to keep the number of modules in a diagram below seven (which also may help explain why the above method works well for a small number of sectors).
Rearranging the Urban Dynamics model into three levels, I was able to simplify the top-level of the diagram to the following, which shows all of the important high-level feedback loops:
There are also lower-level feedback loops within each of these modules. The one within workforce is just as complicated:
The model logic rests within these second-level modules. For example, the module underemployed mobility contains the following logic:
