Queue Sorting

Hello,

I noticed this issue in a much bigger model and replicated it in a very small scale with the following sample model (Sorting_Problem_Capture). If you run the sample model, the following events will happen:

• I create 5 flowitems (one every second) and assign them a label named "rank_no". The first flowitem has a "rank_no" of 5, the second one is assigned 4 etc...
• I accumulate them in a queue (by using "closeoutput" command at "OnReset" logic for the queue) and sort them in a descending order within the queue as they come in.
• When the 5th flowitem arrives in the queue, the command "openoutput" is executed and the flowitems go to a processor.
• I expect to see the flowitem with "rank_no = 1" to be processed first, but that is not the case. "rank_no = 2" is processed first, then "rank_no = 1". The rest are correctly sorted.

This is important within the large-scale model I am working on. Can you please let me know why this is the case and how it can be fixed. Please try not to change the flow logic within the sample model drastically.

Thanks in advance and best regards, Goksin

The problem with your model seems to be a problem in a lot of models. What you are doing on the queue is opening the output port of the queue in the OnEntry trigger. You should NEVER, repeat NEVER open or close input/output ports in the OnEntry or OnExit triggers! Goksin, I'm not trying to be hard on you, just trying to make a point for all those who will read this post in the future. The way to accomplish this is to send yourself (same object) a delayed message in zero time and then in the OnMessage trigger, do your opening/closing of ports. I've attached a model (Sorting_Problem_Capture_FS1) to show this is all it takes. This is basically the only change I made to your model. And as you can see by running the model, it fixes the problem.

Originally Posted by Jeff Nordgren

... You should NEVER, repeat NEVER open or close input/output ports in the OnEntry or OnExit triggers! ...

Could you please further explain this issue? Is there any particular reason for this? Is it Ok if we close/open ports of some other objects (not current) in these two triggers?

Thanks.
Alan

I was wondering if you've had a chance to study the section regarding a FixedResource in the Flexsim Manual. It's a great way to understand the common functionality of fixed resources. How they work "under the hood" sort of speak.

One point that's probably not mentioned in there is the change we made to the Queue after publishing that section back with version 2.6 I think. Typically there is an event associated with each and every flowitem that enters a fixed resource subclass object whether there is a process time or not. In other words, a flowitem enters an FR, the input ports are closed, an event is created and put into the future event list, when the event fires the inputs are reopened. We decided to increase the execution speed by removing this "unnecessary" event in the case of a Queue, and just execute the code associated with the Send To Port field as part of the flowitem move event. We soon found this caused "stack overflow" errors when many flowitems enter a Queue at the same time, so we compromised and force an extra event with every 50th flowitem to enter within the same event.

If you have any questions after reading Help>Users Manual>Flexsim Object Library>Fixed Resource, let us know and we'll try to answer them.

Cliff

Here are some comments from Cliff that may help clarify this issue.

I was reading the section of "FixedResource" in the manual. It is really helpful to clarify issues when you see something wrong in the model. A clear image of the FixedResource logic is a must if you want to dynamically control the flows using code.

Something is not so clear in the flow chart.

1.
What is the initial state of those ports? The chart only has steps of opening ports, but not closing ports. When those ports are closed in the logic? Cliff mentioned in the above post: "...In other words, a flowitem enters an FR, the input ports are closed, an event is created and put into the future event list, when the event fires the inputs are reopened...". Does this mean the input ports of an FR are closed once a flowitem enters it? What about the output ports of the upstream objects?

2.
How many FixedResource are involved in the flow chart? 3 or 2?

3.
Where is the point that the event is created mentioned in the Cliff's comments.

4.
What determines when an upstream item gets released?

Hope by discussing, more people will have better understanding of how Flexsim objects works.

Thanks.
Alan

Alan,

The documentation in the users manual is fairly comprehensive and detailed. I hope I can clear up your questions.

1. The initial state of all ports is open unless closed by the modeler. The documentation covers the opening of ports because the output port is always open unless closed by the modeler. Not all FRs are exactly the same. The queue is a good example of that. For our conversations sake, we will say that the FR we are talking about is a processor. The input ports are closed when a flowitem enters so no other flowitem can enter. This, of course is only true if the capacity of the processor is 1. The input port stays closed until the flowitem leaves through the output port. At that point the processor is ready to receive another flowitem and the input ports are opened. The output port of the upstream object remain open. But if there is a flowitem in the upstream object that is ready to leave, the status of the upstream object will be "blocked".

2. The chart itself references only one object. It may make references to some condition on an upstream object but the flow chart itself is of one object.

3. I think I probably covered this one in item 1.

4. A flowitem will be released from an object when it has a flowitem that is ready to leave and a downstream object that is ready to receive it.

I hope that covers it?

Jeff,

Thanks for your answer. One small thing remains. I assume that in the chart, the first opening of ports means input ports, while the second means output ports. So if the output ports are always open, why need to open it after "Call Sendto function"?

Alan

Alan,

If you look at the shaded section of the chart on the left, it tells you that the first one is input ports and the second one is output ports. I guess I was answering the question from the modelers view and not the programmers view. From the programmers view (internally) the output ports do need to be opened. But from a modeler view, having no control over the internal stuff, the output port is always open unless the modeler closes it. In the normal flow of things the output port (modelers view) is always open unless you close it. So I guess it just depends on what view you choose to look at it.

Jeff,

Again, thank you very much! You've been very responsive and helpful.

Best Regards,
Alan

Jeff,

I have been trying to follow your guideline of

"You should NEVER, repeat NEVER open or close input/output ports in the OnEntry or OnExit triggers."

Today I had an interesting problem which I would like to share with you. I also attach a simple, sample model at the end of this message.

What I want in this simplified model is:

• Queue3 is a buffer location with capacity of 1, to act as a gate-control for a processor.
• The input port of Queue3 is closed from the very start.
• After a certain event (at simulation time 5 of the sample model), a message is sent to open the input port of Queue3.
• As soon as one flowitem enters Queue3, the input port should be closed (which is done through a message to itself.)

However in the model, a second flowitem manages to sneak into Queue3. After thinking about it, I can (kind-of) understand why this happens with a queue (I tried changing Queue3 to a processor with zero process time and it worked as I expected.)

Can this be explained with the quote from Cliff you posted before:

Typically there is an event associated with each and every flowitem that enters a fixed resource subclass object whether there is a process time or not. In other words, a flowitem enters an FR, the input ports are closed, an event is created and put into the future event list, when the event fires the inputs are reopened. We decided to increase the execution speed by removing this "unnecessary" event in the case of a Queue, and just execute the code associated with the Send To Port field as part of the flowitem move event.

I will appreciate any guidance about this. For example:

• Are there any other objects where a similar problem can happen?
• When the receiving object is a queue and there is the probability of multiple flowitems waiting for the same queue, should we take an exception to your guideline?

Thanks in advance.

Goksin,

You may have found a minor "exception" to my rule. The queue is a little bit of a different animal. However the same rule can be applied if you use the "NoDelay" on the message you send in the OnEntry trigger of the queue. So if you change the Delay time to "NoDelay" instead of 0, it should work as you would expect it to.

The following rule is not as hard and fast as it seems:
"You should NEVER, repeat NEVER open or close input/output ports in the OnEntry or OnExit triggers."

I think is more appropriately a guidline that should not be crossed without extreme caution.

I have found that in most instances I can close input and output ports on entry and exit without any problems. I have not had as much luck with opening ports. With this in mind I still would not recommend that a user do this without first trying to do it another way.

The case Goksin mentions where he is using a queue as a gate and he has another flowitem sneaking in before he can close the input port with a message is a case where that should be done on the entry trigger. However, if he tries to also include code that opens the output ports he could run into some serious problems.

The bottom line is that if you are going to break the rule you need to make sure that you test, validate, and debug your model at the highest level and after that you will still need to keep that situation in the back of your mind as a potential cause for later problems. And always remember that nobody will be very happy with you if you conciously break the rule and then ask for help later because breaking the rule has caused you problems.

If you're going to break the rules, break them responsibly!
Brandon

When is there ever a problem with closing a port in the entry/exit trigger? I can only think of problems with opening them...

Originally Posted by Brandon Peterson

If you're going to break the rules, break them responsibly!

Please don't break and drive!