Elevator simulation thoughts

CS 680
Spring, 2003
Ethan Bolker
Elevator simulation thoughts

Measuring time. The discrete event simulator engine uses longs to measure sim~ulated time. But the natural time unit for the elevator simulation itself is seconds, and fractions of a second will matter. So you should probably convert float or double values for seconds to long values for milliseconds in order to schedule events.
I suggest that you write some time unit conversion methods and call them regularly, so you don't end up worrying about when to divide by 1000 and when to multiply by 1000 and when to round off and how.
Input data (Answering ckarki's forum post).
In real life a passenger comes to the elevator at (say) floor F planning to go to floor G. If there are N floors, that means there are N*(N-1) kinds of trips. We'd need to specify the arrival rate in passengers/second for each kind.
Our first simplification is to assume that all passengers boarding the elevator anywhere other than the main floor will go to the main floor rather than to any intermediate floor. That means we have only 2(N-1) kinds of trips, those going to main from somewhere and those going somewhere from main.
Our second simplification is to assume that each passenger boarding at the main floor to go up makes a random decision at each floor about whether or not to get off at that floor. Real passengers don't behave that way, but the simulator doesn't care whether we specify the trips to a particular exit floor in terms of passenger arrivals at main or as a decision made at random at each floor.
Finally, we assume passengers are conserved. That is, we assume that in the long run the rate at which passengers leave the elevator at any floor other than main is the same as the rate at which they arrive at the elevator to go back to main.
With these assumptions we need only this input data about trips:
- The rate at which passengers arrive at the elevator at the main floor.
- The probability that an arriving passenger at main wants to go up.
- The probability that a passenger going away from main leaves the elevator when it stops at some floor. (That probability must be 1.0 at the top and bottom floors.) Note that passengers on the elevator on the way back to main never get off except at main even if the elevator stops to pick up other passengers. Only at main do passengers get on and off.
With this we can actually compute the rate at which passengers arrive at the floors other than main. In fact I've done that for you in the static method compute in class $CS310/elevators/ArrivalRates.java
It follows from this discussion that some of what's in the .els file is irrelevant is irrelevant.
This line matters:
```
# probability that a passenger on board leaves at floor f
  1.0 0.7 0.9 0.5 0.3 0.2 0.5 0.3 0.5 0.1 0.1 1.0
```
but it should be recommented:
```
# probability that a passenger on board travelling away from
# main leaves at a particular floor. Must begin and end with 1.0.
# The value for main itself is never used.
  1.0 0.7 0.9 0.5 0.3 0.2 0.5 0.3 0.5 0.1 0.1 1.0
```
The only entries on these two lines that we need now are the ones for main - the other arrival rates will be computed and the other probabilities are always 1.0 and 0.0 as shown. But to keep the parsing unchanged we will not change the input format.
```
# passengers/second arriving at a floor
  0.0067 0.04 0.06 0.03 0.013 0.0167 0.057 0.01 0.05 0.0067 0.043 0.0167

# probability that a person arriving at a floor wants to go up
# (these values assume all trips are to or from main, which is 2)
  1.0 1.0 0.8 0 0 0 0 0 0 0 0 0
```
Simulator Performance. Simulations need to run a long time in order to produce statistically significant results. You probably need many thousands of passengers to get good average values for the times to and from the main floor. So it may be important to make the simulator run fast.
But it's a mistake to pay too much attention to performance early in the design process, since attempts to speed things up will distract you from making good design decisions. Here's how to address the question. (Details to follow.)
- Instrument your simulator so that after it's run it tells you how much CPU time it consumed and how many objects it created - particularly, Event objects and Passenger objects (I will have the simulator package count the Events for you).
- After you have finished the coding and testing, refactor so as to reuse those objects if you can.
Reusing Events. Note that the Event class has a setter for the time at which an Event should take place. That allows you to reuse an Event object, like an ElevatorArrivesAtFloorEvent. You might be able to create just one of these for each Elevator and reschedule it as needed.
I have added error handling to the simulator package that prevents you from changing the actionTime of an Event that is already on the event queue!
Elevator Logic. Write an API that allows you to test out different possibilities. Some things to experiment with:
- Should you always send the nearest Elevator to pick up a passenger?
- Where do elevators wait when there are no passengers?
- If you have two or more elevators, does it make sense to have one reserved for the higher floors? (That's a little tricky given the way we have specified our input data.)
You might want an ElevatorLogicFactory so that you can have several implementations of the ElevatorLogic API in several classes. Run your simulation seeded several times with different logics to see what difference the logic makes in the average passenger trip times.

If there are people on board when the elevator stops and the
departure probability is 0.3 then

	  loop on the list of people on board
	     choose a random number between 0.0 and 1.0
	     if the number < 0.3 that person leaves the elevator

When the simulator runs for real the user should see no output after the simulator starts. Messages from each Event are good for debugging but not what you want when you run for hours of simulated time, with thousands of events. Since the Simulator object has a debug mode you should probably use that when you want a display, rather than having to edit your code to turn messages off when you're done. If you don't want to do it that way you should at least have your own debug flag. And the clever way to do that is to have a Debug class, with
```
     public boolean debug = false;

     public static void out(String s)
     {
         if (debug) {
            System.out.println(s);
	 }
     }
```
Then in your code you always write
```
     Debug.out("some message");
```
and when you want debugging just say someplace
```
     Debug.debug = true;
```
Reading your memos I find a common misunderstanding that gets in the way for a lot of you. You say something like "A PassengerArrivesAtFloorEvent schedules an ElevatorArrivesAtFloorEvent." You cannot make progress on this simulation until you get this notion out of your head. At the time when the Passenger arrives at the floor there is no way anything in the system can know at what time an Elevator will arrive to pick that Passenger up. An Elevator can be told to start moving from where it is to the right Floor, but it might have to stop along the way because another Passenger has come along in the meanwhile. All the PassengerArrives...Event can do is inform some object (perhaps an ElevatorLogic object) that there is a request. Then that object will know what to say when an Elevator asks it where to go. If Elevators are idle that object can tell one of them to start toward the desired floor - just one floor at a time. Then it's not idle, so it can ask for new instructions when it has moved one floor.

Back to the CS680 home page.

CS 680 Spring, 2003 Ethan Bolker Elevator simulation thoughts

CS 680
Spring, 2003
Ethan Bolker
Elevator simulation thoughts