Time-specific resource availability

[Enchufa2]

Use case provided by @bart6114:

env <- simmer("SuperDuperSim") %>%
  add_resource("nurse", list(0=1, 30=2, 180=1)) %>%  # time schedule dependent capacity
  add_generator("patient", t0, function() rnorm(1, 10, 2))

This allows to simulate work schedules, in this case there would be 1 nurse available from time 0 to 30, 2 nurses from time 30 to 180 and 1 nurse from 180 onwards.

[Enchufa2]

Reply to #36 (comment):

If we create functionality to let the capacity increase/decrease during a run', [this functionality] can simply be achieved by introducing a convenience function; i.e. an arrival starting at 0 which increases / decreases capacity at specified times.

Indeed. But then the resource needs to become a process and I don't like that from the simulator's design point of view, specially when you can achieve the same, easily, using a branch.

Which brings to mind; what to do when you decrease capacity (e.g. to 0) when something is processing. Do you interrupt it or let it finish? Should that be another parameter?

The resource is already seized. I think it is unfair to interrupt anything. But now, think about arrivals with different priorities and a preemptive resource with time-specific resource availability. An arrival with an amount of 2 is preempted and then the capacity decreases to 1... I see PITA, PITA everywhere. 😄

So currently my position is closer to discard this enhancement than to implement it.

[bart6114]

Indeed. But then the resource needs to become a process and I don't like that from the simulator's design point of view, specially when you can achieve the same, easily, using a branch.

How would you implement the example using a branch?

[Enchufa2]

Let's suppose, for instance, we have a clinic with different number of nurses at morning/afternoon/night:

• 3 nurses from 6am to 12pm
• 2 nurses from 12pm to 20pm
• 1 nurse from 20pm to 6am

check_hour <- function() {
  hour <- now(env) %% 24
  if (6 <= hour && hour < 12) return(1)    # morning
  if (12 <= hour && hour < 20) return(2)  # afternoon
  if (20 <= hour || hour < 6) return(3)       # night
}

t0 <- create_trajectory() %>%
  branch(check_hour, rep(T, 3),
    create_trajectory("morning") %>%
      seize("nurse_morning", 1) %>%
      ...,
    create_trajectory("afternoon") %>%
      seize("nurse_afternoon", 1) %>%
      ...,
    create_trajectory("night") %>%
      seize("nurse_night", 1) %>%
      ...,
  )

env <- simmer("SuperDuperSim") %>%
  add_resource("nurse_morning", 3) %>%
  add_resource("nurse_afternoon", 2) %>%
  add_resource("nurse_night", 1) %>%
  add_generator("patient", t0, function() rnorm(1, 10, 2))

env %>% run()

[Enchufa2]

Wait, wait... it occurred to me... We can create like pools, namespaces of resources, so that you can repeat resource names between pools and then apply time-specific availability across pools. This way, we kill two birds with one stone:

• Pools are processes, resources not.
• All the problems of "what if one is being served when the capacity changes, or one was preempted and then..." are gone forever. 😄

What do you think? I don't know if I've explained myself. I can clearly see the implementation of this in the backend (C++ part), but I'm not sure what's the best syntax for the frontend.

[bart6114]

I'm not sure if I understand you correctly. Do you mean that the pool would then control seize and release requests for a specific namespace?

If the pool operator function has access to the attributes of the arrival and the simulator object and route requests to the correct resource it can be used in a very flexible way to do create e.g. time-schedule dependent resource availability (which in essence would be different types of resources).

[Enchufa2]

I'm not sure if I understand ME correctly. 😄 I came up with this idea while thinking about a low-level implementation, so I don't how much sense it has from the frontend point of view (I mean, maybe this is compatible with your original use case, the code in the top comment, maybe not).

So, from the C++ core point of view, I imagine a pool of resources as a process that controls resource instances. Suppose that this pool has a "nurse" and a "doctor", but more than that: it has n instances of a resource called called "nurse" and n instances of "doctor". The n instances have the same name but different characteristics (for instance, different capacity), and only one (one "nurse", one "doctor" in this case) can be active at the same time.

The pool process is inserted in the event queue at those times in which the resource instances must change (for example, the capacity must change). When the pool is activated, it transfers the queue from the active resources to the new ones, and no more changes are needed (the arrivals being served in the previous resources will finish eventually and new ones go to the currently active resources).

This scheme preserves resources as passive entities and it is more efficient, because it allows the programmer to group resources with the same scheduling.

[Enchufa2]

Ok, forget all my previous crazy ideas. All I need is a resource scheduler. I know exactly how to do it now. ;-)

[bart6114]

Great work @Enchufa2.
For those testing the current dev-main branch (7ea13bd), see the following working example:

library(simmer)

t0<-
  create_trajectory() %>%
  seize("t-rex") %>%
  timeout(5) %>%
  release("t-rex")

sim<-
  simmer() %>%
  add_resource("t-rex", capacity = schedule(timetable = c(5,10,15), 
                                            period=Inf, 
                                            values = c(1,0,1))) %>%
  add_generator("piggy", t0, at(0,0,0)) %>%
  run()

plot_evolution_arrival_times(sim)

get_mon_arrivals(sim)