Entity Container and renege when full

[Mike H]

Hi Harry.

Is there a way to limit the contents of a Container?

For example on a bus route, if the bus is full (Container) I want it to renege and go to the next stop (RemoveFrom and AddTo) and so on until enough people have disembarked and it can take on passengers again.

 

Something like:-

RenegeCondition             this.QueuePosition==1||this.obj.Count>25

 

Can it be done using a Threshold to  control whether the AddTo adds any more to the container or not?

 

Thanks

Mike H

 

[Harry King]

Hi Mike,

I like your bus model! You can control the number of passengers that board the bus using the NumberOfEntities input for the AddTo object. Add a Capacity attribute to your bus object and then enter the following expression for NumberOfEntities keyword for each AddTo object:

'max(min([Queue1].QueueLength, this.Container.Capacity - this.Container.Count), 1)'

Replace Queue1 with the appropriate queue for each AddTo object. See the attached model.

This change works great except that the NumberOfEntities input cannot be zero, so a full bus loads one more passenger. I've been struggling with the question of what to do with NumberOfEntities equal to zero for the last few weeks. For your model, it would make sense to just release the EntityContainer immediately, with no entities added. This might just be the best solution -- I'll try it out and see there are any snags.

Harry

[Mike H]

Hi Harry

Thanks.

It seems to work ok as a bus route, Buses bunch up, and renege when another bus is picking up.  The overloading was the only one behaviour I could not figure.  Now I will look for some bus timetables to try it as a simple simulation of what appears to be quite complex  problem.

Mike H

[Harry King]

Mike,

I forgot to look at your reneging condition for the container queue. Yes, your inputs allow a full bus to bypass a stop if another bus is still loading (assuming that none of the passengers on the bus want to get off at that stop). I hadn't thought about using the reneging feature in that way. Now the only problem is to get the bus to not load passengers if it is already full.

Harry

[Mike H]

Hi Harry.

The renege condition this.QueuePosition==1||[EntityContainer1].Count>25

Is what I had.

I took out the  [EntityContainer1].Count>25 because I could not get it to work and it would not have worked properly or as well as your solution.

this.QueuePosition==1 makes the preceding bus overtake the bus picking up at the AddTo and carry on to the RemoveFrom, which is behaviour I have observed with my local bus service when one bus catches up with another and they become "bunched" together.  This is usually caused by congestion, high passenger demand (Xmas) or other factors along the route.

Thanks

Mike H

[Harry King]

Hi Mike,

The buses in Vancouver work the same way unless they are trolley buses.

Your present renege condition, this.QueuePosition==1||this.obj.Count>25, is correct. With the new Capacity attribute, it would be this.QueuePosition==1||this.obj.Count>=this.obj.Capacity. Note that the buses will not get a chance to renege, though, because the ServiceTime input is zero for all the AddTo objects. A queue will never form because the buses load instantaneously. It will work fine once you allow for a realistic loading time of a few seconds per passenger.

I've looked some more into the question of NumberOfEntities equal to zero. Releasing the EntityContainer immediately works okay for AddTo, but unfortunately it causes the Pack object to generate an infinite number of EntityContainers at the time the value goes to zero, thereby locking the model. The solution I propose is to accept NumberOfEntities equal to zero in both cases, but automatically place a lower limit of 1 for Pack. In other words, an input of 0 would be the same as an input of 1 in that case. This seems like a better solution than generating a runtime error message and forcing users to put max(1, ... ) around their input expression. For example, in your model the expression would simplify to:

'min([Queue1].QueueLength, this.Container.Capacity - this.Container.Count)'

What are your thoughts on this?

Harry

[Mike H]

Hi Harry.

Been thinking about what you said.

"If I have this right" then:-

 

Anything that makes expressions simpler is good, but that comes with a price, and I was not really aware of the consequences until I decided to control the Removefrom with a distribution.

As it is at the present if you try to unpack zero entities we get an error message that the NumberOfEntities has to be 1 or more. I tried it when I set up the discrete distribution for the RemoveFrom's.

You have to unpack at least 1 object so there is no change there.

The only way around that is to have an automatic renege condition if the distribution returns a zero for the Number of Entities for an unpack so that the container goes to the NextForContainers?

 

The rest of the model is working fine, I see nothing wrong with it, it allows buses to pass each other by when a stop is occupied, and it limits the passengers boarding to the capacity of the bus.  Brilliant.

Now, all I need to do is decide what I will do with it.

I saw a post about Optimisation, not sure if this is what you meant, but here goes.

3 buses capacity 50

4 buses capacity 40

5 buses capacity 30

Against

Average waiting time at the queues and overall average waiting time.

Which is the best solution depending on whether you are trying to optimise the operating cost of the busses or the passenger waiting time at the queues.  Each must have a cost, wait too long and you get in the car or other transport.

 

Somewhere in between possibly is a compromise, it might well be the middle option, or not depending upon the cost of operating each scenario.

I am not a bus operator so I do not really know how they balance these variables, I do know they look at reliability of the bus timetable, these days they have trackers to track the buses, but that's another ball game.

 

I am looking for a problem for my students to solve, but I do not want to make it too complicated, at least the first time around, if this works I can add to it.

 

I knew this was not a simple problem.

 

By the way, Trolley Buses.  I remember them as a kid in the early to mid 60's, lost of sparks flying on a cold November night, especially if it was damp or even foggy.

 

Mike H

[Mike H]

Harry

I meant to attach the model as it is now.

Mike H

[Harry King]

Hi Mike,

Yes, RemoveFrom can be modified to allow zero for NumberOfEntities in the way that you describe.

This is a good example of a real-world problem. Fewer, larger buses is usually the cheapest solution, but provides less frequent service and longer waiting times. When there is a finite list of alternatives such as this, usually the analyst would simply run each case and tabulate the results. The selection of the best alternative would be done externally in a spreadsheet that compared capital cost, operating cost, and service level. For the purpose of your exercise, you could provide these costs for each type of bus and ask your students to simulate the cases, tabulate results, and describe how they would make a recommendation. 

Harry

[Harry King]

Mike,

The ability to handle an input of zero for NumberOfEntities has been added in release 2016-15 for Pack, AddTo, and ReleaseFrom.

Harry

[Mike H]

Hi Harry

Thank you

Mike H