Fast Food Restaurant Model Questions

Hi, I am currently working on simulating a fast food restaurant. There are a few questions I have about problems I have run into that I am hoping someone here can help me with:

1.) I am modeling the system with Customers as TaskExecuter Flowitems. They enter the system and move into a queuing area and then move throughout a set of network nodes to different processes. I want the customers to be able to have collisions. However, under the collision tab of the flowitem, I can only add existing static objects to its collision table. How do I allow the flowitems to be able to collide with each other?

2.) For customer queuing, is it possible either to create a free "queuing area" where, rather than having a static queue object where the flowitems gather, have a 'queue network' where they can freely (randomly) move through a network but still be counted as in a queue?

Something simpler, if possible, is can you increase the spacing distance between objects in a queue? The reason I ask is because the simulation is heavily based on relative size and distance, and people queuing 2 inches between each other is not realistic from a practical sense. (I suppose this could be solved If I could figure out how to check collisions between them, and the collision spheres could remain active in the queue.)

3.) This one should be simpler. I am currently having customers gather in a large queue before moving into a smaller queue for individual registers. I am using the shortest queue length logic for sending customers from the large queue into the smaller ones. However, this logic does not account for the processor following the smaller queue.

What happens is, the first customer enters the big queue, goes into the small queue off port 1 and then moves right to the attached processor. When the second customer comes, he goes to the large queue. His logic tells him to go to the shortest subqueue. At this point, both subqueues are empty, but the first one has a customer at the processor. The second customer still goes to the first queue because it defaults to port 1 - leaving the second processor empty when a customer is in queue for processor 1.

I hope I explained that clearly. Is there a way to modify the shortest queue flow logic to take into account the status of the process further down the flow?


Thank you very much for any help you can provide.
Jarrett

First some answers:

1) I'm not sure this is a good idea but the way you would add them is by using code. Use createcoupling() and pass in the two values returned by getvarnode(<object>,"collisionobjects") for all the pairs of <objects> you want to check. If you're having them wander around in a confined space, I'd imagine the collision handling code could get very complicated.

2) a) Free space: You can create traveltoloc tasks for the task executers while they are waiting. Just set the item placement option on the queue to 'Do Nothing' and use the entry trigger with something like createtraveltoloctask(item,1,uniform(0,5),uniform(-5,5),0,0,0,0); You'd need to make sure they have enough time in the queue to complete the travel task I guess.

2) b) Queue distance. Check this thread.

3) You should be able to change the Shortest Queue logic to something like:

treenode tempobject;
int curmincontent = 1000000000; // this sets the integer to the largest possible value that an integer can hold.
double curminindex = 0;

for(int index = 1; index <= nrop(current); index++)
{
tempobject = outobject(current, index);
int thiscontent= content(tempobject)+content(outobject(tempobject,1));
if(opavailable(current,index) && thiscontent < curmincontent)
{
curmincontent = thiscontent;
curminindex = index;
}
}

return curminindex ;


Using taskexecuterflowitems simplifies the modelling process but you run into hurdles like these. At some point jumping over all these hurdles becomes more work than using something like coordinated task sequences or subtasks, which may be more appropriate for some aspects of the model. Also consider using nodefunctions that call usercommands - I find this makes it all easy to read and can be used to chain a few task sequences together.

UPDATE: I've put together an example which also caters for the variable 'nroftransportsin' for deciding the shortest queue. I'll post it when I've ironed out an issue I am seeing.

Attached is an example model. Thanks to Phil for pointing out the error. I'd ignored my own warning in the above post about making sure the traveler has enough time to travel to a waiting position. To get around that I've added the release to the task sequence and set the queue4 sendTo to 'Do not release'.

Thank you very much Jason! I did what you said for both the 'free queuing' and the shortest queue logic and it worked like a charm.

For the collisions, after looking into it I see what you mean by how complicated it can get. The number of collisions it would need to check would be huge, and its not really worth it for the amount it would slow down the model, so I wont worry about it.

Thank you again!

Jarrett