question

Stephanie Lombard avatar image
0 Likes"
Stephanie Lombard asked Logan Gold answered

Source creating inconsistent amount of items

Hi all,

I am currently struggling to understand why my model is generating a different amount of items between runs. It varies between 80 and 82 items. Furthermore, it generates a different amount of items when I change logic downstream in the model. I do not think this should happen.

I have attached the model. Boxes are generated by Source3 in the 3D environment as seen in the image below. Whenever a box is created, the event triggered source "Source 3 Creation" creates a token in processflow. I then assign labels to each token to keep track of the order in which I will create boxes and the processors they have to go to. I then create the boxes in the "Arrival" queue and change the visual of the box.

The box then goes through the first check. Queue5 in front of Check1 can only have 1 box in it at a time. I use a subflow on "Use Transport" to check the contents of Queue5 and make the box wait at Check1 if Queue5 is occupied as shown in the image below. If Queue5 is not occupied, I move the object into Queue5.

The boxes then go through Check2 and queue in Queue1 before going to the third check. Queue1 has a maximum capacity of 2.

Check3In and Check3Out share the same operator. I used the same subflow on "Use Transport" for both Check3In and Check3Out as shown below to achieve this. When a box in Check3In requires transport, the "ShareCheck" subflow starts at the "StartIn" activity. When a box in Check3Out requires transport, the "ShareCheck" subflow starts at the "StartOut" activity. Both activity blocks starting with "StartIn" and "StartOut" aqcuire the same resource linked to one operator in Group1.

After the third check boxes are sent to be processed by either Processor4, Processor3 or Processor5 depending on the Processor label I assigned in the beginning. All the processors must share the same operator. I used a dispatcher so I can later change the amount of operators.

After Check3Out is done, the LastCheck is done. I again use a subflow (as with Queue5) to ensure that only 2 boxes are in Queue9 at a time as shown below.

Lastly, 75% of the boxes have to be delayed in Queue9 while 25% to not have to be delayed further in Queue9. Furthermore, boxes have to leave in the order they came into Queue9. Thus if a box comes into Queue9 that does not have to be delayed, it has to wait for any box that came in before it to finish its delay before it can leave. To do this, I used an Event-triggered source (Box enter Queue 9) that creates tokens as boxes come into Queue9. All the tokens are pushed to a list with a max wait timer of 0 seconds. The entries are kept on early release. The tokens are then either delayed or not depending on a 75%, 25% split enforced by a decision activity. Lastly, before the tokens leave, they are pushed to another list (List2) before the box is destroyed.

I create s single token with the Keep box order schedule source in processflow that pulls from the first list to get the box number and pulls from List2 then later on according to box number. This ensures the boxes leave in the correct order.

I saw that if I unconstrain the content of Queue9 (if I take out the wait for event activity in my "Queue9 Capacity" subflow), Source3 creates a different amount of items for the same amount of runtime.

I also saw that if I should take out the logic that ensures boxes leave in the same order they come in at Queue9, Source3 generates a different amount of items for the same amount of runtime.

I do not think this should happen. Source 3 should generate the same amount of items for the same amount of runtime regardless of how I change the logic in the last step. I agree that more or less boxes should go through the system, but the amount that is generated in the beginning should stay the same.

Thank you for your help

arrivalmodelq-1.fsm

FlexSim 17.1.4
source
create-items.jpg (104.3 KiB)
check1.jpg (133.7 KiB)
check3.jpg (121.8 KiB)
operator.jpg (77.5 KiB)
queue9.jpg (95.3 KiB)
box-delay.jpg (78.0 KiB)
boxorder.jpg (89.6 KiB)
arrivalmodelq-1.fsm (44.2 KiB)
arrivalmodelq-1.fsm (44.2 KiB)
5 |100000

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

Logan Gold avatar image
3 Likes"
Logan Gold answered

The reason there is a variable number of items being generated from Source3 (even with Repeat Random Streams selected) is because your Operators do not have a Reset Position. Every time you reset and run your model, it's possible that your Operators are in a different starting positions, which will affect the rest of the variability in the model.

To ensure that your model is repeatable, you should follow the steps outlined in this article:

https://answers.flexsim.com/articles/21666/model-repeatability-15.html

As for the other issues you bring up - this is happening because you are using the same random stream for all your distributions. Due to how random streams work, using the same random stream on multiple objects (even ones that don't directly affect each other in the model) will affect the randomness in those objects. And the variability will be affected differently depending on how many distributions use the same random stream.

To counteract this, all distributions have an optional parameter to adjust which random stream is used for that particular distribution. The stream parameter takes an integer value starting at 0 I believe. If nothing is used for this parameter, the distribution defaults to 0. So if a different stream is used for each distribution, they shouldn't affect each other.

To make it easier to ensure each stream is different, there is a command called getstream() that can be used in place of the stream parameter of distributions. The getstream() command takes one parameter, the object the distribution is being used in. So for your model, this would be Source3 when using getstream() in the triangular distribution. And in most cases, you can simply use the current variable, like this:

triangular(30, 120, 60, getstream(current))

With this addition and having a reset position on each of your Operators, Source3 should always produce the same amount of flowitems in the same amount of model time.

5 |100000

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

Sebastian Hemmann avatar image
1 Like"
Sebastian Hemmann answered

So I´ve made some tests and as soon as I turn on "Repeat random streams" and give the Operator a fixed reset Position, I always get the result of 82 in Queue3.

Because there is a statistical Distribution in Source3 as Arrival Time, I think the model does what it should!?

5 |100000

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

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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