Find and easily resolve modeling issues.
| Test as You Go Don’t wait to the end of model development to start testing. Test as you build. If you wait until the end to verify the model works correctly, it will take much longer to find bugs because you have to search through the entire model. Build the model in small chunks and test thoroughly as you go. If you test as you go, the new bugs will be in the constructs you have just built. You will be focused on a smaller construct to look for the bug while that logic is fresh on your mind. This is such a crucial aspect of the modeling process that it deserves mentioning more than once! |
| Snipping Tool or Print Screen Get access to a screen capture tool and keep it handy. When an error message pops up, take a screenshot of it. Don’t be click happy and absent-mindedly click the Okay button when errors appear. If you don’t document what the errors are, you will have to rerun the model again because you will quickly forget the exact details of the error message. A snipping tool is installed with Windows, but there are other options such as SnagIt. |
| Logging Exceptions No one can or should constantly look for every potential bad event each time they run the model. For example, if an item stays in the system 10x longer than you expect, there might be a potential problem. Or if item type x never goes through a specific construct, you know you have a potential problem. You can and should continue to monitor that event in case another bug shows up. There are many more instances that require monitoring, but they shouldn’t consume our attention. These are events where you need to set up a construct to log the exception events to an error log table in the database when they occur. You should also report the number of these exceptions on the main model worksheet when and if they occur, so they are sure to grab your attention. Once you have finished verifying and validating your model, then you can take the exceptions out or have a flag that turns them off. You may also want to leave them in just to reduce your worry. Logging error events or exception events is a great way to monitor the system. Note, however, that if you put error events in that are really warnings, you might overlook real errors when they occur. |
Find Dialog If you have an error message and it refers to an object number, you can use the menu shortcut Control + F or click the icon in the toolbar to open the Find dialog in order to find the object number. |
Global Random Seed If you need to debug your model and want a repeatable result from run to run, you can fix the Global Random Seed. Debugging can be difficult if the bug appears at different simulation times from run to run. Fixing the global random seed can be done in the Random Number tab of the Simulation Setup dialog. If you want to repeat the last model run, set the Random Seed to the Starting seed used in the last model run. Setting the seed to any positive number will allow the model to run with a repeatable stream of random numbers, thus giving repeatable results. Setting the seed to 0 or blank provides a random starting seed. |
| Releasing Resources Be careful when you release resources. The Resource Pool Release block is used to return the resource back to the appropriate pool when the resource is no longer required. If the block immediately downstream from the Resource Pool Release block has a capacity limit and is full, the resource won’t get released when it is finished with the upstream task. The resource won’t get released until the item with the resource can move past the Resource Pool Release block and into the next residence block downstream. This issue is easy to overlook. It will prevent the resource from being used elsewhere even though it is done with its current task. The Resource Pool will overly estimate its utilization. Specifically look for this issue at the end of model development on every model.  This construct is one way to eliminate the issue. In this construct, when the Activity for Task X is busy, the item will be in the Activity labeled Task X Busy. When the Activity for Task X is blocked, it will wait in the queue labeled Task X Blocked while the Gate prevents anything new from arriving into the Activity block. |
| Debugging Infinite Loops Where the Simulation Time Never Progresses Past a Certain Point Occasionally your model might have a bug which causes it to go into an infinite loop. This loop could be due to several reasons. The reasons could involve either creating an infinite number of items, an item looping continuously in a circle, from an unending for loop, or from several other reasons. There is an easy way to figure out where the loop is occurring. Turn on the profiler and run the model again well into the infinite loop. After a while, you must manually stop the model but it should show you the block (S) where the excessive time has been spent. The blocks with excessive times should be where the infinite loop is occurring. |