During my time developing Arena models, I’ve greatly appreciated the speed at which the software runs and the typically short time that it takes to run multiple replications of models. However, I have run into one or two models that were large and complex enough that runtime became a concern. Based on those experiences, I’ve compiled a list of some of the top tips for how to reduce runtime in your simulation models.
These are options that many users are already aware of, but it’s still a good starting point. When you run your simulation model, Arena is tracking the position of animated entities and all the displayed statistics, even when the model is fast-forwarding. If you are only interested in the output values, you can use batch mode so that the model does not spend any time tracking the animation. If you’ve been debugging your model using the command line and have turned the trace option on, make sure that you turn it off when you are done as it slows the model run down since it is writing out all the steps as they occur.
While it’s possible to write directly to Excel spreadsheets, this can slow your model down if you are doing it frequently. Think about how long it takes you to manually open Excel and have it open a spreadsheet – Arena is going through the same process. For end-of-replication statistics, this is usually fine, but you may want to consider using the csv format for frequent writes. Most computers default to opening csv files in Excel anyway. If you have a newer version of Excel, you can also take advantage of its data connection features to allow you to set up a spreadsheet for doing your analysis and establish connections to your output files to simplify pulling in the latest output.
Arena automatically captures many performance measures and reports these statistics in the built-in reports. However, if you have a large number of elements (e.g. resources, entities, variables, stations) in your model, you may find that this can have an impact on your run time. In that case, you can turn off statistics reporting on individual elements that you do not need. If there is an entire category of statistics that you are not interested in recording, you can go to the Project Parameters section of the Setup options and uncheck that category of statistics. Setup is located on the Run tab, under the Settings group.
The Scan block or Hold module with Scan for Condition allows you to establish an expression to be evaluated that will block the entity’s progress while the expression is false. Arena evaluates this condition at the end of each event step and allows the entity to pass once the condition is true. While this is typically not an issue, this may add to the run time if you have a significant number of events and entities waiting in these modules. In this situation, you may want to use Hold and Signal or have entities delay and re-check the expression at a set time interval instead.
When performing a search using the Search module or FindJ block, Arena will start at the specified starting value and check the condition. If that first value does not satisfy the condition, Arena will continue searching until it finds a value that provides a true result. When searching an array, it is easy to set the starting value to 1 and the ending value to the number of rows in the array to search the entire array. However, if there are a significant number of rows in the array, this can result in wasted time searching rows that will never match the condition. If possible, it will always be faster to index directly into the array rather than doing a search. There may be cases where this is not an option, but it may still be possible to limit the search by setting a starting value for the first potential matching row (based on lookups from an external data source) to avoid searching rows that will never satisfy the condition.
If you have a model with a sizable number of entities and you are permanently batching large numbers of them, you may be better off using the Combine block instead of the Batch module. While the Batch module creates one representative entity from all the original entities, Arena still retains the original information on all the component entities even though they can no longer be removed from the batch. With the Combine block, Arena destroys the underlying entity information, so it reduces the amount of information that Arena is tracking. If you want to make this change and check on the impact, you can check on the number of entities in your model by using the NUMENT variable to find out how many entities are presently active in your model.
When creating a simulation, the modeler must determine what level of complexity they need to implement in their model. Ultimately, the model should capture detail at the level needed to produce results that are accurate enough to be useful. Determining what constitutes “accurate enough” is often as much an art as a science. If you can make simplifications of complexity without negatively impacting your results, this can often reduce your development time as well as the run time. For example, if you have parts moving on a conveyor that has plenty of capacity, it may be faster to model that as a simple delay or route rather than using the conveyor modules. While this decision will be driven by the specifics of the system you are modeling, it is critical to always be thinking about how much complexity is actually needed.
Another way that you may simplify modeling is to take a more data-driven approach to modeling. If you have a series of stations that your part needs to visit, you can build that sequence in an array rather than enumerating the specific stations within the model. That array (either from within the model file or in an external data source) is then used to determine which station the part visits next and when it is done. By storing the data separately from the logic, it allows you to create a model structure that is both simplified and flexible for later changes.
Arena’s modules are typically bundling together lower-level SIMAN blocks and elements to simplify modeling for the user. Most of the time, the runtime speed of models using these higher-level modules is sufficient. However, there are some instances where a model is extremely large and complex and it may be better to use the lower-level constructs. In this case, you could replace a Process module with a Seize and Delay action with the simpler Queue, Seize, and Delay blocks to speed up your model runtime.
Several Arena modules offer the ability to perform multiple actions in one module. For example, the Assign module can handle multiple assignments and the Record module can capture several statistics in one module. When possible, it is better to do several steps within one module rather than placing multiple individual modules, each handling one step or assignment.
If you are still struggling with model runtime after working through all the suggestions above, your best recourse may be to use Arena’s parallel replications feature. This is a new feature that was introduced in version 16.1 that allows you to distribute individual replications across your computer’s logical processers. While the individual replication runtimes may be longer than desired, running them in parallel versus serially can reduce the amount of time needed to complete all the replications needed for statistical validity.
If you are experiencing issues with the runtime of your model after following the previous tips, please feel free to reach out to technical support for assistance with examining your model and recommending approaches to help reduce the time needed to run your model.