question

Ben Wilson avatar image
2 Likes"
Ben Wilson asked Jason Lightfoot commented

Speed issues in a large, complex model

We are modeling a high-throughput widget factory. We would like to simulate one week of production, and have the simulation complete in a few hours or faster, but we've found that our large quantities of widgets significantly reduce the speed of our FlexSim model.

We have already gone through several rounds of trying to optimize the model, including incorporating all the suggestions found on the old and new FlexSim forum. For our latest attempt we converted all our logic to Process Flow so we can completely uncouple the Perspective View layer. We can essentially turn off all the flow items and have the model run only in Process Flow. Unfortunately the model is still very slow. We fear this may be a model that FlexSim won't be able to handle.

We are considering reducing the number of items with a factor, so that one token represents 10+ widgets. This may help, but could impact the model's accuracy.

So before we start reducing the model, is there anything else we can consider that would significantly increase the processing speed of the model? We submitted our model separately in a private question. The Process Flow is what runs the whole thing, and the global variable ShowModelVisuals, toggles the flow item generation. Keep in mind that there is supposed to be an additional production line in the model that is a copy of the current one, and a packing area after those. With those additional areas we are potentially facing a doubling of the item count that is already killing our model.

Furthermore, is seems that FlexSim is not utilizing the computer's processing power very well. We are aware that the software can only use one thread, but is also seems that its not fully using that thread either. CPU utilization never exceeds 18%.

FlexSim 16.2.0
process flowmodel speedmodel optimizationlarge modelmassive models
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

1 Answer

Phil BoBo avatar image
4 Likes"
Phil BoBo answered Jason Lightfoot commented

The problem is not necessarily in the number of items you have in your simulation. The problem is in the size of the event list at any given time.

For example, when this model gets to steady-state, you have roughly 42,000 events on the event list.

Testing This In Your Model

First, I opened the Statistics view of your Process Flow's Sink activity so that I could see how many widgets get completely processed.

Then, when you run the model, you can see this value slowly increase as the model runs.

Now, you can compare how many widgets per real second are being processed, rather than comparing how many simulation minutes are being processed per real second.

For example, on my computer with your model, the Sink's input after 30 seconds is 2,848. So 2,848 widgets got processed in 30 seconds.

Now adjust your inter-arrival time in your ModelParameters table from 0.3 to 300. Run the model at max speed and see how many widgets get processed in 30 seconds. On my computer, it processed 127,739 widgets in 30 seconds.

Unless I'm misunderstanding how your model works, the only thing that is changing between these two runs is the amount of widgets in the system simultaneously. Thus changing how many events are queued on the event list at a given time. With the inter-arrival time at 300, you have roughly 45 events on the event list at steady-state.

With less events on the event list at once, you can process about 250,000 widgets per real minute vs 6,000 widgets per real minute.

The Answer

So the answer to your question is that you need to adjust how your model is configured so that you have less pending events on the event list at any given time.

Here's a general example of how you could think about solving this problem:

Imagine you have a conveyor with 50,000 items on it at a time, with 1 item coming onto the conveyor and 1 item leaving the conveyor every 1 second.

If you model each item individually entering the conveyor and creating an event to leave the conveyor after the amount of time that it takes to convey it across the conveyor, then you will have 50,000 events pending for those items.

If instead, you kept a label that shows how many items are on the conveyor, and you created 1 event for the first item to leave, then in that event, created the next event for the next item leaving in 1 second, and so on, then you would only have 1 event on the event list at a time that represents when the next item will leave that conveyor.

(This example is actually quite similar to how the Conveyor module conveyor object works; it minimizes the number of events that are pending on the event list. You can see that in the attached model (giant-conveyor.fsm), which shows a conveyor with 13,822 items on it at once, but only 2 pending events on the event list at a time. The number of flow items going through the system per real minute is about 1,800,000 on my computer. FlexSim can handle simulating this system; you just need to adjust how you think about the problem so that you can model it efficiently.)

How To Fix This

So rather than having a token that represents each widget, that then has a pending event for each widget in your simulation, you should think about what problems you are actually trying to solve by running this simulation. Depending on what questions you are trying to answer, you should restructure your simulation's logic so that it is based on the actual process on the system and not necessarily based on processing each widget as a unique entity that has a pending event on the event list at all times. This is especially true where you have constant values and rates rather than stochastic values.

CPU Utilization

While FlexSim is running the model, the Windows task manager will show its usage at approximately 1 core of your processor. If you have a 1-core processor, it will show about 99%. If you have more cores, and if Hyper-Threading is enabled, it will show a lower percent.


giant-conveyor.fsm (16.9 KiB)
· 11
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.