Skip to main content

Simulating a Lift with Python Part 1A: the Curse of the Basement Floors


The Curse of the Basement Floors

Tired of waiting for lifts? I am!

In my University, there’s a building that’s (in-)famous for its four painfully slow lifts. The ground floor is crowded everyday with students who want to attend lectures. However, it is not a simple lifting job. The twist is there are two basement levels under the ground floor. While most of the students are waiting on the ground floor and want to go UP, the lifts are often called DOWN, against the majority’s wills, by a few people on the basement floors. That often means an extra few minutes of standing, sighing, and complaining.

I am always frustrated by this. I mean yeah, of course those people down there also need a lift, but I can’t help but think if there exists no basement floor at all, it got to be faster now that the majority the lift system is serving are initialized on the ground floor. If it is not that the lift must make a detour every time it comes back down to the ground floor, the whole system must be more efficient and overall quicker! It got to be!

Right?

Objective

My hypothesis is “a lift system will be more efficient in a building without basement floors”, and I am testing this hypothesis stochastically. The goal is to programme and simulate two lift systems, one with basement floors, and one without any. Then, I’ll calculate the time needed to “clear” all the passengers within the system respectively in each model and see if there’s any significant difference between the two.

Actually, there is an even more ambitious goal: to test the efficiency of different algorithms of lift movements under different conditions, which will be explained in future articles.

Code

The following code is written in Python 3.7.4. 

Explanation

This programme is not hard to explain. I am not a Computer Science student (they are incredibly smart), so I always try to code using the “translator” approach – to simply express my idea in a foreign language, which just so happens to be understandable by computers. Although that might make my codes a bit more readable and understandable, professional programmers or CS students might find my codes a bit chunky, inefficient and needlessly “humane”. Oh well.

The Building
First, a “building” is represented as the list floorArray, which contains 21 floor objects, representing a building with 21 levels, 0th to 20th floors. Then, the programme assign a list (peopleArray) of people objects into each floor object, which of course stands for the waiting passengers on each floor. Each people object has an attribute of destination, which is a randomly generated number representing the level the passenger would like to go to through the lift.

The Lift
The building is done. The next big thing is the main character itself – the lift. The lift object has four attributes – position (self-explanatory), capacity (the maximum capacity of a lift, which is arbitrarily and somewhat realistically set as 20), direction (+1 when the lift is going up, and -1 when the lift is going down), and another peopleArray. The main idea is to let the lift go up and down in the building, picking up passengers (by transferring people objects, from peopleArray in the floor objects, to peopleArray in the lift object) along the way, as long as the lift isn’t full. Passengers get out of the lift when they have reached their destination (in this case, I will directly erase the people object out of the system for simplicity sake).

Lift Algorithm, and a Can of Worms
And we are half-way done. Then, we have to code the algorithm of the lift movement, which by itself is a huge thing. I would imagine that real-life design of lift-movement logics requires advanced intellects from fields of Statistics, Mathematics, Architecture, Engineering, and Computer Science. I am tacking this in future projects (again, I will explain this later), but definitely not now.

But at this point, I can’t just avoid making a decision, because the lift has to somehow move in this simulation. Here, I will make a bold simplification: a lift will only change direction at the top or the bottom of the building, i.e. 0th or 20th floor. In other words, the lift will go up until it reaches the top, and go down until it reaches the bottom, which is mostly the case in real life if you assume there are always passengers waiting on every floor. Bold, I know, but good enough.

Furthermore, the lift will stop on a floor if:
  1. At least one passenger is waiting outside, and they find the lift is going in the right direction (e.g. a passenger isn’t going in if he wanna go to the top floor while the lift is going down); or
  2. The lift reaches the destination of at least one passenger inside the lift.

Time Measurement
Finally, we have to somehow give an objective measurement of the time spent to “clear the building” within the model. We don’t actually care how many minutes or seconds it takes, as we just want the time spent to be represented by a single number, whose unit doesn’t really matter, with which we can compare across simulations.

Here, I again make some bold simplifications. I assign a parameter to each event (door opening, people getting in, lift moving, etc.), and then tally up the total at the end of the simulation. These parameters are relatively representing how long it takes for those events to occur. For example, in real life a person getting in the lift takes significantly shorter time than the door opening and closing, so the former event has a time parameter of 1 and the latter has that of 5. Of course, I can grab a stopwatch, stand by a lift, and actually measure the exact number of seconds needed for a real lift door to close, but this matter is rather trivial, and I am lazy.

Results

Please stay tune for part 1B .;)

天涯思君不可忘
塞上牛羊空許約

Comments