averbraeck

Dave, thanks for the explanation. This makes it (especially the paradigm) a lot more clear. If some of this can be included in the standard description of a resource and schedules in the manual and in the help files, I believe it will be very beneficial to a lot of people! A SimBit to demonstrate the capacity reducing example you outline below, would also be very helpful for many (I will for sure build that example for my classes -- it will answer a lot of questions I routinely get). Finally, you are absolutely right that being able to extend the standard objects and change their behavior is easy and helps to address many issues. I can create a 'preemptive server' that way in a matter of minutes. Thanks again! Alexander.

Option 1: The way I often solve it is to create a high-priority 3-hour job that tries to seize the server at the time when it should go down. As it is waiting in the front of the priority-based queue, it will keep the server busy for 3 hours after the previous job has finished. Statistics will not show true idle time, of course... Option 2: Same high-priority job that triggers an add-on process that takes the server off-shift (or decreases capacity by one); after 3 hours, the token increases the server capacity again. Job time for the job that carries out the trigger is e.g., 0.1 second. Assign step: Server.CurrentCapacity := Server.CurrentCapacity - 1. The advantage over a Timer or a schedule change is that you can control what happens with your own 'helper' Entity. Make sure it is a different Entity instance to avoid contaminating the entity statistics of your 'real' entities. Alexander Verbraeck Professor of Systems Engineering and Simulation Delft University of Technology, The Netherlands

Regarding item #3: This is behavior that no one will understand. Suppose a models has a large volume of jobs with a duration of 2 hours or more. In the late afternoon, 10 people work on these jobs. When they all go home at 6, work stops (so, going off-shift completely is preemptive behavior, while the model behavior is completely different when I change the capacity from 10 to 1...). When 1 person comes in in the morning at 7, he picks up all 10 remaining jobs and finishes them in parallel... I would consider that to be a bug. Alexander.

Glenn, Dave, Thanks for the replies. Totally clear, and IMHO, very important to state this CLEARLY and OFTEN in the Simio documentation, where this seems to be totally missing. I had a few models where processing times were quite long, and there were lunch breaks and times to go home for the employees (resources) through schedules, but the results were not valid. I now understand that most employees did probably not take lunch at all and went home late. It would be ideal if "preemptive" schedule changes and "wait" behavior for breaks could be implemented as standard options as well when building a schedule. E.g., indicating that the schedule capacity needs change immediately (preemptive behavior), needs to finish the current job(s) (ignore -> current behavior), or needs to shift the next capacity change for the duration of finishing the current job(s) (wait behavior, but I realize that this is difficult to implement in a consistent manner). Alexander.

When does a resource change capacity when this is requested through a schedule or through an assignment of the CurrentCapacity? When studying the behavior, we deduced the following, but want to check that it is correct (the documentation did not give much information): 1. When the resource is busy (say, fully occupied with a capacity of 5), and the capacity is decreased to 1 or more, all entities that are in process finish their work as scheduled. The effective change apparently takes place after busy entities are finished. (in Arena, this was either the IGNORE or the WAIT behavior). 2. When the resource is busy (say, fully occupied with a capacity of 5), and the capacity is decreased to 0, it immediately stops processing the current entities, which will stay in the Processing queue. When capacity is increased again to 5, the entities are finished. (in Arena, this was the PREEMPT behavior). 3. When the resource is busy (say, fully occupied with a capacity of 5), and the capacity is decreased to 0, it immediately stops processing the current entities. When capacity is increased again to, e.g., 1, all entities seem to finish at the same time. This is strange, because one would expect the entities to be finished one-by-one. This could be considered a bug? Finally, is it possible to implement IGNORE (schedule change starts late if entity busy, but next schedule change remains unchanged), WAIT (schedule change starts late if entity busy, and next schedule change is shifted accordingly) and PREEMPT (schedule change starts immediately) behaviors in Simio? -- Alexander Verbraeck, TU Delft, Netherlands