A Simple Discrete-Event Simulation: Part 74

Following yesterday’s work I had three tasks to complete. The first task was to fix the reporting for cases where a Process or Bag component is not the last item in a component group. The fix was to only run the reporting process for exiting a group when the entity leaving a Process or Bag component is going to a different non-Path component that’s in a different group. This involved embedding the report function at the end of the forwardEntity function in the if statement shown below.

The getComponentGroup function in Path components had to be modified so it actually returns the component group of its next component, so it always returns the component group of the next non-Path component.

The second task was to experiment with different ways of specifying the process time for certain components in a modular way. I originally passed in an array of values and called a fixed, external function to determine the array index to use base on the relevant entity’s user-defined properties. Later I added an additional index to the process so different Process or Bag components could generate lookup indices based on different properties or combinations of properties. I then realized that I could simply pass a custom function in for each case. The code for one way of doing this is here:

If we want to retain some additional form of external modularity of parameters we could do something like this:

The possibilities are many.

The third and final task was to allow the simulation to run until it is empty if a specific flag is set. I defined a global variable called runToEmptyFlag and modified two tests that control when to stop the simulation and when to stop recording data. The logic says to run to at least the minimum time and then stop if runToEmptyFlag is false, or keep going until there are no entities left in the system if runToEmptyFlag is true. Today’s version of the model has the flag set to true, so it will run beyond 630 time units as long as there are entities still in the system. If the first run doesn’t run past that time because it clears out then reset and rerun it until you see the desired behavior. The runtimes can vary quite a bit depending on how the type and routing dice fall.

I noticed that the final time increment would not be reported properly if the systems runs to empty beyond its allotted time. The fix was to add in an extra reporting increment if the global clock is greater than the number of reporting cycles run times the number of time units per cycle.

This entry was posted in Simulation and tagged . Bookmark the permalink.

Leave a Reply