Lessons from a Massive Model

Sometimes you have to take a leap of faith when taking on a new project. Last year I had the opportunity to develop a FlexSim model of a 1,000,000 square-foot, multi-story distribution center operation. The client wanted a comprehensive model that could emulate all of their major operations, from receiving, put-away and picking to sorting, packaging and shipping. It was a major undertaking so, although I was comfortable completing the project, I was still nervous about FlexSim’s ability to effectively handle such a large system.

Through the completion of this project, I gained a good understanding of some of the challenges and solutions for working with large FlexSim models that I would like to share at this time.

Massive Simulation Model

The bigger the model, the trickier it becomes to make changes.

System Memory is a Big Deal

Although FlexSim is a 64-bit software package, it is absolutely key to find ways to be “frugal” with your computer memory usage for larger models.

  • I used data bundles versus tables, for example, to store model information. This helped considerably since data bundles use far less memory space than tables and can dynamically grow/shrink as necessary to hold the required data.
  • An example of where this helped was in the storage of order wave information. At the beginning of a simulated day, the model would randomly generate up to 1.3MM lines (11 columns) of order information based upon user-defined order characteristics. Using a table to store this amount of data generated a huge memory overhead for the model.
  • One thing to note is that it is more difficult to review data in bundles (vs. tables). One solution is to create scripts that will export the bundle data to an external file for review as needed.

Model Editing Challenges

It is progressively more difficult to make model changes as the model size/complexity grows.

  • One thing that I did to counteract this potential issue was to create Object Groups for similar model elements. This enabled me to select and modify multiple elements simultaneously during the development and experiment phases of the project.
  • In my model, for example, I had Object Groups for Order Sorting Locations (5,000+), Shipping Positions (350+), VAS Stations (350+) and Buffer Lanes (120+) which allowed me to quickly make changes based upon revised information.
  • In addition to Object Groups, I also used User Commands extensively so that most of the model logic could be accessed/modified from a few places. This became an efficient way to debug the model during the development phase and modify the logic to run experiment alternatives towards the end of the project.

Distribution Center Model Characteristics

  • 90,000+ different SKU’s stored in +3MM rack locations
  • 35,000+ orders to pick, sort, package and ship per day
  • 5,000+ order sorting locations
  • 1,200+ conveyors
  • Areas Modeled: trailer receiving, inbound material operations, put-away, wave picking, staging, wave sorting, value-added services, outbound QA, manifesting, manual packaging, and shipping

Comments, Comments, Comments

Finally, it’s more important than ever to use comments to document your model logic in a large model. As complexity grows, it gets harder to remember how individual elements work together within the system.

In the end, the project was considered a success and a great investment by the client. The project team was able to use the model to validate the concept design performance over the planning period, identify opportunities for design improvement, and clarify/refine a shared understanding of how the system will actually work.