Jump to content
Simio Forum

Transport Priority vs Seize Request Priority


Recommended Posts

Not sure how many of you will be able to open this model... but essentially I am trying to understand why entity priority is not applying to seize request priority.


Refer to attached model.

Model_Transport_vs_Seize_Priority.spfx

 

The last time I asked about this, I was lead to believe that the entity priority should dictate order, as long as ranking and dynamic ranking expressions maximised priority. I did not have time at that stage to go back and verify, but now that I am looking at this again... it still does not seem the case. Clarification would be appreciated.

 

2013-03-18_11-17-41__Model_Transport_vs_Seize_Priority_-_Simio_Team_Edition_-_Registered_to_Anglo_Am.thumb.png.0ca4a1f262c395c6d1c28beb77a22c75.png

2013-03-18_11-17-43__Model_Transport_vs_Seize_Priority_-_Simio_Team_Edition_-_Registered_to_Anglo_Am.thumb.png.0b1428af1eac747f6e4583158a71f051.png

2013-03-18_11-18-15__Resource_Seizes_-_Repeating_Property_Editor.png.280701b3cfa00ce8f71c1b467e5d408c.png

 

EDIT:

Found where I last enquired about this. http://www.simio.com/forums/viewtopic.php?f=17&t=720

Every Object that has the ability to act as a Resource (objects that have the Resource Object property set to True) have 3 methods of evaluating seize requests: one is the Evaluating Seize Request process that has the ability to deny capacity units to any requesting object based on some criteria, and/or the Ranking Rule & Ranking Expression, and/or Dynamic Selection Rule . The Ranking/Dynamic Selection Rules can be set to Largest/Smallest Value and when used along with a Ranking Expression allows the object to decide which of the requesting Objects are allocated capacity units.


Both of these evaluation methods look at the value of certain, user-defined, expressions. You can evaluate any expression pertaining to the requesting object. So you can just assign a value to that expression (Entity.Priority) to be evaluated.


The Move Priority is evaluated by the PlanVisit and SelectVisit process steps when determining where to Move the Object between several requests. This Move Priority is different than the Seize priority because it is choosing between several objects that have already seized capacity of the object. The Move Request priority has nothing to do with Seize priority. To initiate a move request on a resource, the owner object first has to seize the resource. The Move Priority is only used if the owner(s) of the resource have issued multiple move requests to it, and the resource is using a step like SelectVisit to select its next accepted move destination.

Edited by Guest
Link to post
Share on other sites

James, the priority is being applied -- the problem is the model you created is probably not what you intended to create!


Two entities both request a seize of the vehicle at the same time. The vehicle correctly accepts the request from the 'top' entity first because it has a higher priority and adds that entity to its visit request queue. Upon arriving at the node, the vehicle is released by the entity, and then accepts the seize from the bottom entity, adding this entity to its visit request queue, and so begins to head to the bottom entity.


The next top entity to arrive attempts to seize the already seized vehicle. The vehicle does not 'unsieze' itself and accept the top entity -- you would need to add some extra logic to be able to do this.


Next, a number of entities all queue at the various nodes and if you animate the allocation queue you will see that they are correctly ordered by priority. However, once the vehicle arrives at the top lane, it serves all entities there by stepping through your 'seize - > release' logic for however many entities are there, allowing them all to move forward. The vehicle's allocation queue then only has entities from the bottom lane, and proceeds to that location.


I've attached a modified model which doesn't release the vehicle until the vehicle moves to the sink. In this case you'll find it operates as you intended.

AJSMODIFIED_Model_Transport_vs_Seize_Priority.spfx

Link to post
Share on other sites

Thanks Alan. A combination of a fresh look at it, and your demo showing the vehicle allocation/visit queue revealed that it was doing something I had not expected. I can now see that it would immediately iterate through the backlog of entities.


I think this has allowed me to see what I can change in my bigger model, using these learnings. I have a completely different but somewhat related problem in my big model, and I was trying to figure out how to fix it. I had a good idea of what I should do to fix it, but did not clearly see why it would work. Modelling it (even though the problem turned out to be completely different) on a smaller scale helped me gain a bit of clarity over it.

Link to post
Share on other sites
  • 1 month later...

Hi James...


I battled like crazy with this to try and understand how the transporter interacts and why the transporter does not do what it is told...


Should you like, hit me up on skype and I can explain in detail the interaction between an entity, node and a transporter (seize, allocate, route, the whole bag) as well as how to get around the limitations...Monitoring and removing/adding requests to the allocation q at a transporter and model level can prove detrimental if the transporter capacity allocation is not also adjusted...i.e. make sure you get rid off all your tokens in your transporter...


Mark

Link to post
Share on other sites

Pretty sure I did something silly there, and I was over looking a small detail that made it do the complete opposite of what I expected.


I'm fine for now, but thanks for the offer.


My Skype is J.CDoran for reference.

Link to post
Share on other sites

Hi Dave,


Awesome...may we request an elaboration on:


State assignments, capacity allocation, and the transporter seize process...


Specifically surrounding entity and transporter interaction...


There is confusion around the seize process as most people would think that the transporter is seized like a normal resource which does not seem to be the case...


First prize would be a flow diagram or table with two swimlanes (1.Entity and 2.Transporter) that details the process interaction and the blocks and processes used...


nice reference chart we can stick on the wall...


Kind Regards,

mARK

Link to post
Share on other sites
Hi Dave,


Awesome...may we request an elaboration on:


State assignments, capacity allocation, and the transporter seize process...


Specifically surrounding entity and transporter interaction...


There is confusion around the seize process as most people would think that the transporter is seized like a normal resource which does not seem to be the case...


First prize would be a flow diagram or table with two swimlanes (1.Entity and 2.Transporter) that details the process interaction and the blocks and processes used...


nice reference chart we can stick on the wall...


Kind Regards,

mARK

 

Mark, keep in mind that transporters CAN be seized like normal resources and ARE seized like normal resources when requested.

Link to post
Share on other sites

Nope...


Yes other objects can seize a transporter like a normal resources...


but when transporting...transporters seize themselves...


step through the two scenarios and check the subclassed processes that execute...or check the resource owners in your watch expression...


or check the type of token that executes the subclassed process: onRiderReservationAccepted and check to see who the parent is that is being seized....

Link to post
Share on other sites

Ah, sorry Mark, I wasn't clear. I didn't mean that vehicles/workers DON'T seize themselves, but rather that seizing a resource and requiring a transporter to move through a transfer node are different things.

Link to post
Share on other sites
×
×
  • Create New...