similar to how you say people arrive by set number per hour, I have that data for departure.
I think you're looking at this backwards. The number of departures and their departure times should be a function of things going on in your model.
For example, if there are lots of patients waiting for a busy doctor there are going to be fewer and less frequent departures than a similar model that has 2 doctors seeing the waiting patients. If you were to somehow (I can't even think of a way of doing this) enforce a set departure schedule then your model wouldn't be very useful. Adding a second doctor, like in my example, wouldn't increase the throughput of the model and you would be lead to believe that it didn't matter how many doctors there are.
This sounds to me like a statistic you should be measuring in your model so you can first validate the model (make sure the departures and throughput match your historical data reasonably well) and then experiment with your model to see, for example, what factors within the model most affect the throughput.
Similar Example - Wait Times
We often see similar concerns with wait times. Whereas some delay times (like a specific surgical procedure) have a specific amount of time associated with them that you want to enter in the model, wait times are a function of the model.
You should never force a patient to wait in the waiting room for 63.5 minutes because that's what the historical data says they do. Doing so turns the model into an emulation and not a simulation. This defeats a lot of the purposes of simulation such as helping you answer questions about why the wait time is so long.
Instead wait times should be measured for validation and experimentation. Set up the model so that the average time in the waiting room is about 63.5 minutes because there is only one doctor performing tasks for a long time, for example.
I would create a list of leaving persons. If the list functionality doesn't exist, you can use a label that you decrement each time when a person should leave the exit queue and increment when a person is leaving the facility. The following sink object have to open the input in the set departure time, wait until a person enters the sink and close the input. Or the sink closes its input if the time elapses a person would need to reach the sink. You will see that if your model doesn't feed the exit queue with enough input the label contains negative values. If you use a list you see back orders. If your departures frequency is to low the content in the exit queue will rise.
You see it is only a work around to get a departure driven model, because you can't force or get something like an output from nothing, you can only document that there is a deficit or a surplus.
The only possible real departure driven model, I can think of, creates a demand by a message or a ProcessFlow and you create the object at this moment in the model where and when you need this person.
7 People are following this question.
