The question we get asked most frequently by just about anyone who wants to know more about our modeling software is “What is the difference between STELLA and iThink?” From a functional perspective, there are no differences between the STELLA and iThink software — they are two different brands of the same product. The STELLA …
There are times when it is helpful to calibrate, or fit, your model to historical data. This capability is not built into the iThink/STELLA program, but it is possible to interface to external programs to accomplish this task. One generally available program to calibrate models is PEST, available freely from www.pesthomepage.org. In this blog post, I will demonstrate how to calibrate a simple STELLA model using PEST on Windows. Note that this method relies on the Windows command line interface added in version 9.1.2 and will not work on the Macintosh. The export to comma-separated value (CSV) file feature, added in version 9.1.2, is also used.
The model and all files associated with its calibration are available by clicking here.
The model being used is the simple SIR model first presented in my blog post Limits to Growth. The model is shown again below. There are two parameters: infection rate and recovery rate. Technically, the initial value for the Susceptible stock is also a parameter. However, since this is a conserved system, we can make an excellent guess as to its value and do not need to calibrate it.
The Data Set
We will calibrate this model to two data sets. The first is the number of weekly deaths caused by the Hong Kong flu in New York City over the winter of 1968-1969 (below).
The second is the number of weekly deaths per thousand people in the UK due to the Spanish flu (H1N1) in the winter of 1918-1919 (shown later).
In both cases, I am using the number of deaths as a proxy for the number of people infected, which we do not know. This is reasonable because the number of deaths is directly proportional to the number of infected individuals. If we knew the constant of proportionality, we could multiply the deaths by this constant to get the number of people infected.
The Shifting the Burden Systems Archetype shows how attacking symptoms, rather than identifying and fixing fundamental problems, can lead to a further dependence on symptomatic solutions. This Systems Archetype was formally identified in Appendix 2 of The Fifth Discipline by Peter Senge (1990). The Causal Loop Diagram (CLD) is shown below.
When a problem symptom appears, two options present themselves: 1) apply a short-term fix to the symptom, or 2) identify and apply a longer-term fix to the fundamental issue. The second option is less attractive because it involves a greater time delay and probably additional cost before the problem symptom is relieved. However, applying a short-term fix, as a result of relieving the problem symptoms sooner, reduces the desire to identify and apply a more permanent fix. Often the short-term fix also induces a secondary unintended side-effect that further undermines any efforts to apply a long-term fix. Note that the short-term fix only relieves the symptoms, it does not fix the problem. Thus, the symptoms will eventually re-appear and have to be addressed again.
Classic examples of shifting the burden include:
- Making up lost time for homework by not sleeping (and then controlling lack of sleep with stimulants)
- Borrowing money to cover uncontrolled spending
- Feeling better through the use of drugs (dependency is the unintended side-effect)
- Taking pain relievers to address chronic pain rather than visiting your doctor to try to address the underlying problem
- Improving current sales by focusing on selling more product to existing customers rather than expanding the customer base
- Improving current sales by cannibalizing future sales through deep discounts
- Firefighting to solve business problems, e.g., slapping a low-quality – and untested – fix onto a product and shipping it out the door to placate a customer
- Repeatedly fixing new problems yourself rather than properly training your staff to fix the problems – this is a special form known as “shifting the burden to the intervener” where you are the intervener who is inadvertently eroding the capabilities and confidence of your staff (the unintended side-effect)
- Outsourcing core business competencies rather than building internal capacity (also shifting the burden to the intervener, in this case, to the outsource provider)
- Implementing government programs that increase the recipient’s dependency on the government, e.g., welfare programs that do not attempt to simultaneously address low unemployment or low wages (also shifting the burden to the intervener, in this case, to the government)