First, load the package and instantiate a new simulation environment.
library(simmer)
env <- simmer("SuperDuperSim")
env
#> simmer environment: SuperDuperSim | now: 0 | next:
Set-up a simple trajectory. Let’s say we want to simulate an ambulatory consultation where a patient is first seen by a nurse for an intake, next by a doctor for the consultation and finally by administrative staff to schedule a follow-up appointment.
patient <- trajectory("patients' path") %>%
## add an intake activity
seize("nurse", 1) %>%
timeout(function() rnorm(1, 15)) %>%
release("nurse", 1) %>%
## add a consultation activity
seize("doctor", 1) %>%
timeout(function() rnorm(1, 20)) %>%
release("doctor", 1) %>%
## add a planning activity
seize("administration", 1) %>%
timeout(function() rnorm(1, 5)) %>%
release("administration", 1)
In this case, the argument of the timeout
activity is a function, which is evaluated dynamically to produce an stochastic waiting time, but it could be a constant too. Apart from that, this function may be as complex as you need and may do whatever you want: interact with entities in your simulation model, get resources’ status, make decisions according to the latter…
Once the trajectory is known, you may attach arrivals to it and define the resources needed. In the example below, three types of resources are added: the nurse and administration resources, each one with a capacity of 1, and the doctor resource, with a capacity of 2. The last method adds a generator of arrivals (patients) following the trajectory patient
. The time between patients is about 10 minutes (a Gaussian of mean=10
and sd=2
). (Note: returning a negative interarrival time at some point would stop the generator).
env %>%
add_resource("nurse", 1) %>%
add_resource("doctor", 2) %>%
add_resource("administration", 1) %>%
add_generator("patient", patient, function() rnorm(1, 10, 2))
#> simmer environment: SuperDuperSim | now: 0 | next: 0
#> { Resource: nurse | monitored: TRUE | server status: 0(1) | queue status: 0(Inf) }
#> { Resource: doctor | monitored: TRUE | server status: 0(2) | queue status: 0(Inf) }
#> { Resource: administration | monitored: TRUE | server status: 0(1) | queue status: 0(Inf) }
#> { Generator: patient | monitored: 1 | n_generated: 0 }
The simulation is now ready for a test run; just let it simmer for a bit. Below, we specify that we want to limit the runtime to 80 time units using the until
argument. After that, we verify the current simulation time (now
) and when will be the next 3 events (peek
).
env %>% run(until=80)
#> simmer environment: SuperDuperSim | now: 80 | next: 81.0747215115259
#> { Resource: nurse | monitored: TRUE | server status: 1(1) | queue status: 3(Inf) }
#> { Resource: doctor | monitored: TRUE | server status: 1(2) | queue status: 0(Inf) }
#> { Resource: administration | monitored: TRUE | server status: 1(1) | queue status: 0(Inf) }
#> { Generator: patient | monitored: 1 | n_generated: 9 }
env %>% now()
#> [1] 80
env %>% peek(3)
#> [1] 81.07472 84.53021 88.24078
It is possible to run the simulation step by step, and such a method is chainable too.
env %>% onestep()
#> simmer environment: SuperDuperSim | now: 81.0747215115259 | next: 81.0747215115259
#> { Resource: nurse | monitored: TRUE | server status: 1(1) | queue status: 3(Inf) }
#> { Resource: doctor | monitored: TRUE | server status: 1(2) | queue status: 0(Inf) }
#> { Resource: administration | monitored: TRUE | server status: 0(1) | queue status: 0(Inf) }
#> { Generator: patient | monitored: 1 | n_generated: 9 }
env %>% onestep() %>% onestep() %>% onestep()
#> simmer environment: SuperDuperSim | now: 84.530209035957 | next: 84.530209035957
#> { Resource: nurse | monitored: TRUE | server status: 0(1) | queue status: 3(Inf) }
#> { Resource: doctor | monitored: TRUE | server status: 1(2) | queue status: 0(Inf) }
#> { Resource: administration | monitored: TRUE | server status: 0(1) | queue status: 0(Inf) }
#> { Generator: patient | monitored: 1 | n_generated: 9 }
env %>% now()
#> [1] 84.53021
env %>% peek(Inf, verbose=TRUE)
#> time process
#> 1 84.53021 Post-Release
#> 2 84.53021 patient4
#> 3 88.24078 patient
#> 4 88.24078 patient8
#> 5 89.97530 patient3
Also, it is possible to resume the automatic execution simply by specifying a longer runtime. Below, we continue the execution until 120 time units.
env %>%
run(until=120) %>%
now()
#> [1] 120
Finally, you can reset the simulation, flush all results, resources and generators, and restart from the beginning.
env %>%
reset() %>%
run(until=80) %>%
now()
#> [1] 80
It is very easy to replicate a simulation multiple times using standard R functions.
envs <- lapply(1:100, function(i) {
simmer("SuperDuperSim") %>%
add_resource("nurse", 1) %>%
add_resource("doctor", 2) %>%
add_resource("administration", 1) %>%
add_generator("patient", patient, function() rnorm(1, 10, 2)) %>%
run(80)
})
The advantage of the latter approach is that, if the individual replicas are heavy, it is straightforward to parallelize their execution (for instance, in the next example we use the function mclapply
from the package parallel). However, the external pointers to the C++ simmer core are no longer valid when the parallelized execution ends. Thus, it is necessary to extract the results for each thread at the end of the execution. This can be done with the helper function wrap
as follows.
library(parallel)
envs <- mclapply(1:100, function(i) {
simmer("SuperDuperSim") %>%
add_resource("nurse", 1) %>%
add_resource("doctor", 2) %>%
add_resource("administration", 1) %>%
add_generator("patient", patient, function() rnorm(1, 10, 2)) %>%
run(80) %>%
wrap()
})
This helper function brings the simulation data back to R and makes it accessible through the same methods that would ordinarily be used for a simmer
environment.
envs[[1]] %>% get_n_generated("patient")
#> [1] 9
envs[[1]] %>% get_capacity("doctor")
#> [1] 2
envs[[1]] %>% get_queue_size("doctor")
#> [1] Inf
head(
envs %>% get_mon_resources()
)
#> resource time server queue capacity queue_size system limit
#> 1 nurse 8.600886 1 0 1 Inf 1 Inf
#> 2 nurse 19.378642 1 1 1 Inf 2 Inf
#> 3 nurse 23.529568 1 0 1 Inf 1 Inf
#> 4 doctor 23.529568 1 0 2 Inf 1 Inf
#> 5 nurse 28.306291 1 1 1 Inf 2 Inf
#> 6 nurse 37.982305 1 0 1 Inf 1 Inf
#> replication
#> 1 1
#> 2 1
#> 3 1
#> 4 1
#> 5 1
#> 6 1
head(
envs %>% get_mon_arrivals()
)
#> name start_time end_time activity_time finished replication
#> 1 patient0 8.600886 50.41121 41.81032 TRUE 1
#> 2 patient1 19.378642 62.13504 38.60547 TRUE 1
#> 3 patient2 28.306291 77.04548 39.06318 TRUE 1
#> 4 patient0 10.215929 50.29546 40.07953 TRUE 2
#> 5 patient1 22.780496 64.55883 39.81314 TRUE 2
#> 6 patient0 9.645535 49.12441 39.47888 TRUE 3
Unfortunately, as the C++ simulation cores are destroyed, the downside of this kind of parallelization is that one cannot resume execution of the replicas.
You may want to try the simmer.plot
package, a plugin for simmer
that provides some basic visualisation tools to help you take a quick glance at your simulation results or debug a trajectory object: