You are here

running speed of large models

I have recently had a problem with a very large Simile model, now solved, and the conslusions might be of interest to other Simile users.
The CamFlores models, simulating relationships between people and their landscape at the edge of the central African humid forest, are probably the largest and most complex Simile models currently running. When saved, they are nearly 10 Mb each, and with such large models running speed can be a serious problem when trying to de-bug and fine-tune.
The first draft of my latest model, for Awae village in Cameroon, used to run one year in about 18 seconds (with no helpers) on a 2 Ghz laptop. A serious problem with labour alocations was discovered, and was fixed by a) changing the household model from a fixed membership model to a population model and b) Introducing a new sub-model inside the land tenure model linking land patches to households. This sub-model had a role link to the household decision making sub-model.
When I built and run this new model, I was horrified to find that it now required 4 minutes for each one year model run, a more than ten-fold decrease in speed. I thought first of all that this was due to conversion of a fixed membership sub-model for households to a population model, but Jasper then suggested that the new nested relational model in land tenure might be the culprit. He suggested that this relational model was actually redundant, and that information could be relaibly passed between households and the land patches owned by them using a satellite link with an "exclusive" role. I modified the model as he suggested, and speed shot up once more. A mere 30 seconds per year! It is now feasible to do multiple iterations for fine-tuning without sitting around all day twiddling thumbs.
The conclusion is therefore that substituting population models for fixed membership models is often esential, and does not involve a huge processing speed potential. Mis-use of relational models can however be bad for your model health!

Forums: 

Thank you very much, Christopher, for passing on this hard-earned insight. We get a lot of questions about how to speed up model execution, so I'd like to take the opportunity to expand on what you've written.

A pre-requisite to considering how to speed up models is to build in C++. Executing models in Tcl is terribly slow for even moderately sized models. It is useful either for those just getting started, or for its more informative error messages, should problems arise. Once you are working seriously with Simile, however, you should definitely install a C++ compiler, and configure it for use with Simile. For details of how to do this, please see http://simulistics.com/products/compiler.htm

Most features within Simile scale very well, so execution time grows only slightly as the model gets larger. As Christopher correctly points out, the exception to this is the association submodel.. As more instances of the base submodels are created, execution speed can fall off seriously. There are a number of work-arounds for this, and more will be available in version 4.0 (available soon). Please contact us to discuss these approaches, if you find this a problem.

Finally, the display tools can have a significant impact on execution speed. Since the display tools are generally designed to provide animated or dynamic feedback during the running of the simulation, they are necessarily quite computionally expensive. If you are running a large model, and are content to analyse the results afterwards, then use only the table display tool, and edit the "Table properties" so that the "Update at display intervals" checkbox is not checked. Add variables to the display as usual, and then, when the model has finished executing, refresh the display. Only now will the results be displayed, and you can save the table to a file, to plot in your favorite graphing package.

Hope this helps,
Alastair

Setting the "Table properties" so that the "Update at display intervals" checkbox is not checked sounded like a good idea. I've tried it and I get the message "Error: Invalid command name ".mre"' whenever I try to update the display. The details from the error message are:

invalid command name ".mre"
invalid command name ".mre"
while executing
".mre cget -cursor"
(procedure "Update" line 2)
invoked from within
"Update .helper5"
(in namespace inscope "::tabular11510" script line 1)
invoked from within
"::namespace inscope ::tabular11510 {Update .helper5}"
("uplevel" body line 1)
invoked from within
"uplevel \#0 $cmd"
(procedure "Button::_release" line 18)
invoked from within
"Button::_release .helper5.bbframe.buttonBox.b5"
(command bound to event)

Does anyone have any idea what is happening and how to get around this problem? I am using Simile 3.3 on Windows 2000.

Thanks.

Doug

Doug:

Unfortunately, this feature only works within the single-window run time environment. This was introduced in v3.0, and is the standard mode for all display tools now. To switch between the multiple windows and single window run time environments, use the Edit...Preferences menu item. On the Run tab, there is a "Use single-window manager" checkbox.

Apologies for not making this clear.

The single-window run time environment lets you add as many tabs as you like, to display the results of the simulation. Each tab can be subdivided to lay out displays in the screen in an extremely flexible manner. You can save the configuration for re-use with the model later.

Kind regards,
Alastair Davies