In this month’s case study, one of the chief goals of the simulation model was to test several potential operational modifications. When there are several changes to test, the questions arise:

• Should the potential options all be built into one large flexible model?
• Is it better to create several models of the system, each focused on one way that the process could happen? 

It may also be possible to break a large system down into components and model different aspects of the system separately. Like all simulation questions, there are no easy one-size-fits-all answers for the best way to model a system.

Creating one large model is certainly easier for handing over to another user who is unfamiliar with the specifics of the model logic. It also limits the number of model and data input files that the user has to manage.

With the model we built for the Cancer Research Institute, one change involved which clinic worker should be responsible for taking the patients’ vital signs. This was done using a drop down selection in the input data spreadsheet – the model then read that selection and depending on the value of that field, the vitals check would happen in different parts of the patient process. This was easy to include in the Arena model since it only required two Decide modules at the potential points where the check could occur. Simple decisions like this are well worth capturing in one single model.

Other changes that may seem more complex to the system design team may actually be straightforward from the perspective of the Arena modeler. For example, an operational option may be to batch parts or process them individually. In this case, a single model can still be used; testing individual processing would simply use a batch size of one. Depending on what the user has selected for the batch option, a spreadsheet input data sheet can then adjust the processing time for the operation. When operational changes are really just data changes, designing smart input data files can make it possible to create flexible logic without much extra modeling effort required.

Elegant and Flexible or Concise and Rigid?

While keeping all the options in one model may seem preferable, there are times when it may not be possible. Constructing an elegant, flexible model can often take more coding time and planning up front. If a project timeline is tight, it may be faster to create several rigid models rather than trying to build a single model that can handle every possibility. If the project plans are in constant flux, this may also provide a reason to keep multiple models separate.

For example, it might be possible to model a packaging operation separately from the manufacturing part of the system and make decisions on changes without having to track exactly which options for each operation are implemented in the version that has a comprehensive view of the system.

Building a single model can also increase the complexity of the model logic and concepts needed, which may be overwhelming to a new modeler. Most of us probably look back on the first models we created and realize now that we could have been much smarter in our modeling decisions. Building multiple models can help us learn the advantages and disadvantages of different approaches to model design, paving the way to building better models in future projects. If the final model will eventually be passed off to an inexperienced user to maintain, this can be another justification for keeping the models simple and avoiding concepts that are too complex or difficult to follow.

Finally, the different model options to be tested may just be too distinctive to put into one model. If the differences are so massive that they will require large sections of different logic to manage, creating a unified model may not be the best option. However, if there are dependencies between the changes or you intend to use OptQuest or other tools to select the best methods, you may have no choice but to keep all the options in one model.

Regardless of the number of models, keeping one consistent input data file structure and having a standardized naming plan for all the model versions can help to keep all the branches clearly defined and easier to manage.