View source for Test and debug your model

[[Category:Analytica User Guide]]
[[Category: Models]]
[[Category: Testing]]

<breadcrumbs>Analytica User Guide > Building Effective Models> {{PAGENAME}}</breadcrumbs>


Even with Analytica, it is rare to create the first draft of a model without mistakes. For example, on your first try, [[definition]]s might not express what you really intended, or might not apply to all conditions. It is important to test and evaluate your model to make sure it expresses what you have in mind. Analytica is designed specifically to make it as easy as possible to scrutinize model structures and dependencies, to explore model implications and behaviors, and to understand the reasons for them. Accordingly, it is relatively easy to debug models once you have identified potential problems.

'''Test as you build''': With Analytica, you can evaluate any variable once you have provided a definition for the variable and all the variables on which it depends, even if many other variables in the model remain to be defined. We recommend that you evaluate each variable as soon as you can, immediately after you have provided definitions for the relevant parts of the model. In this way, you’ll discover problems as soon as possible after specifying the definitions that might have caused them. You can then try to identify the cause and fix the problem while the definitions are still fresh in your memory. Moreover, you are less likely to repeat the mistake in other parts of the model.

If you wait until you believe you have completed the model before testing it, it might contain several errors that interact in confusing ways. Then you must search through much larger sections of the model to track them down. But if you have already tested the model components independently, you’ve already removed most of the errors, and it is usually much easier to track down any that remain.

'''Test the model against reality''': The best way to check that your model is well-specified is to compare its predictions against past empirical observations. For example, if you’re trying to predict future changes in the composition of acid rain, you should try to compare its “predictions” for past years for which you have empirical observations. Or, if you’re trying to forecast the future profitability of an existing enterprise, you should first calibrate your model for past years for which accounting data is available.

'''Test the model against other models''': Often you don’t have the luxury of empirical measurements or data for the system of interest. In some cases, you’re building a new model to replace an old model that is out-of-date, too limited, or not probabilistic. In these cases, it is usually wise to start by re-implementing a version of the old model, before updating and extending it. You can then compare the new model against the old one to check for discrepancies. Of course, differences can be due to errors in the new model or the old model. When you have resolved any discrepancies, you can be confident that you are building on a foundation that you understand.

If the model is hard to test against reality in advance of using it, and if the consequences of mistakes could be catastrophic, you can borrow a technique that NASA uses widely for the space program. You can get two independent modelers (or two modeling teams) each to build their own model, and then check the models against each other. It is important that the modelers be independent, and not discuss their work ahead of time, to reduce the chance that they both make the same mistake. For a sponsor of models for critical applications in public or private policy, this multiple model approach can be very effective and insightful. The competition keeps the modelers on their toes. Comparing the models’ structure and behavior often leads to valuable insights.

'''Have other people review your model''': It’s often very helpful to have outside reviewers scrutinize your model. Experts with different views and experiences might have valuable comments and suggestions for improving it. One of the advantages of using Analytica over conventional modeling environments is that it’s usually possible for an expert in the domain to review the model directly, without additional paper documentation. The reviewer can scrutinize the diagrams, the variables, their definitions and descriptions, and the behavior of the model electronically. You can share models electronically on diskette, over a network, or by electronic mail.

'''Test model behavior and sensitivities''': Many problems become immediately obvious when you look at a result — for example, if it has the wrong sign, the wrong order of magnitude, or the wrong dimensions, or if Analytica reports an evaluation error. Other problems, of course, are not immediately obvious — for example, if the value is wrong by only a few percentage points. For more thorough testing, it is often helpful to analyze the model behavior by specifying a list of alternative values for one or two key inputs (see [[Analyzing Model Behavior]]), and to perform sensitivity analysis (see [[Statistics, Sensitivity, and Uncertainty Analysis]]). If the model behaves in an unexpected way, this can be a sign of some mistake in the specification. For example, suppose that you are planning to borrow money to buy a new computer, and the net value increases with the interest rate on the loan; you might suspect a problem in the model.

'''Celebrate and learn from unexpected behavior''': If analyzing the behavior or sensitivities of your model creates unexpected results, there are two possibilities:

* Your model contains an error, in that it does not correctly express what you intended.
* Your expectations about how the model should behave were wrong.

You should first check the model carefully to make sure it contains no errors, and does indeed express what you intended. Explore the model to try to figure out how it generates the unexpected results. If after thorough exploration you can find no mistake, and the model persists in its unexpected behavior, do not despair! It might be that your intuitions were wrong in the first place. This discovery should be a cause for celebration rather than disappointment. If models always behaved exactly as expected, there would be little reason to build them. The most valuable insights come from models that behave counter-intuitively. When you understand how their behavior arises, you can deepen your understanding and improve your intuition — which is, after all, a fundamental goal of modeling.

'''Document as you build''': Give your variables and modules meaningful titles, so that others — or you, when you revisit the model a year later — can more easily understand the model from looking at its influence diagrams. It’s better to call your variable <code>Net rental income</code> than <code>NRI23</code>.

It’s also a good idea to document your model as you construct it by filling in the '''Description '''and '''Units '''[[attributes]] for each variable and [[Modules and Libraries|module]]. You might find that entering a description for each variable and explaining clearly what the variable represents helps to keep you clear about the model. Entering units of measurement for each variable can help you avoid simple mistakes in model specification. Avoid the temptation to put documentation off until the end of the project, when you run out of time, or have forgotten key aspects.

Most models, once built, spend the majority of their lives being used and modified by people other than their original author. Clear and thorough documentation pays continuing dividends; a model is incomplete without it.

==See Also==
* [[Debugging Hints]]
* [[Analytica User FAQs/Modeling issues]]
* [[Error Message Types]]
* [[Help menu and documentation]]
* [[Example Models]]


<footer>Create a model / {{PAGENAME}} / Expand your model </footer>