These examples are adapted from the Python package ‘SimPy’, here. Users familiar with SimPy may find these examples helpful for transitioning to simmer. Some very basic material is not covered. Beginners should first read The Bank Tutorial: Part I & Part II.



  • Standard resources.
  • Waiting for other processes.
  • Logging messages into the console.

From here:

A carwash has a limited number of washing machines and defines a washing process that takes some time. Cars arrive at the carwash at a random time. If one washing machine is available, they start the washing process and wait for it to finish. If not, they wait until they an use one.

Parameters and setup:

The implementation with simmer is as simple as defining the trajectory each arriving car will share and follow. This trajectory comprises seizing a wash machine, spending some time and releasing it. The process takes WASHTIME and removes some random percentage of dirt between 50 and 90%. The log_() messages are merely illustrative.

car <- trajectory() %>%
  log_("arrives at the carwash") %>%
  seize("wash", 1) %>%
  log_("enters the carwash") %>%
  timeout(WASHTIME) %>%
  set_attribute("dirt_removed", function() sample(50:99, 1)) %>%
    paste0(get_attribute(env, "dirt_removed"), "% of dirt was removed")) %>%
  release("wash", 1) %>%
  log_("leaves the carwash")

Finally, we setup the resources and feed the trajectory with a couple of generators. The result is shown below:

Machine Shop


  • Preemptive resources.
  • Interruptions.
  • Loops.
  • Attributes.

From here:

This example comprises a workshop with n identical machines. A stream of jobs (enough to keep the machines busy) arrives. Each machine breaks down periodically. Repairs are carried out by one repairman. The repairman has other, less important tasks to perform, too. Broken machines preempt theses tasks. The repairman continues them when he is done with the machine repair. The workshop works continuously.

First of all, we load the libraries and prepare the environment.

The make_parts trajectory defines a machine’s operating loop. A worker seizes the machine and starts manufacturing and counting parts in an infinite loop. Provided we want more than one machine, we parametrise the trajectory as a function of the machine:

make_parts <- function(machine)
  trajectory() %>%
    set_attribute("parts", 0) %>%
    seize(machine, 1) %>%
    timeout(function() rnorm(1, PT_MEAN, PT_SIGMA)) %>%
    set_attribute("parts", 1, mod="+") %>%
    rollback(2, Inf) # go to 'timeout' over and over

Repairman’s unimportant jobs may be modelled in the same way (without the accounting part):

other_jobs <- trajectory() %>%
  seize("repairman", 1) %>%
  timeout(JOB_DURATION) %>%
  rollback(1, Inf)

Failures are high-priority arrivals, both for the machines and for the repairman. Each random generated failure will randomly select and seize (break) a machine, and will seize (call) the repairman. After the machine is repaired, both resources are released and the corresponding workers begin where they left.

machines <- paste0("machine", 1:NUM_MACHINES-1)

failure <- trajectory() %>%
  select(machines, policy = "random") %>%
  seize_selected(1) %>%
  seize("repairman", 1) %>%
  timeout(REPAIR_TIME) %>%
  release("repairman", 1) %>%

The machines and their workers are appended to the simulation environment. Note that each machine, which is defined as preemptive, has space for one worker (or a failure) and no space in queue.

for (i in machines) env %>%
  add_resource(i, 1, 0, preemptive = TRUE) %>%
  add_generator(paste0(i, "_worker"), make_parts(i), at(0), mon = 2)

The same for the repairman, but this time the queue is infinite, since there could be any number of machines at any time waiting for repairments.

env %>%
  add_resource("repairman", 1, Inf, preemptive = TRUE) %>%
  add_generator("repairman_worker", other_jobs, at(0)) %>%

Finally, the failure generator is defined with priority=1 (default: 0), and the simulation begins:

The last value per worker from the attributes table reports the number of parts made:

Movie Renege


  • Standard resources.
  • Condition events.
  • Shared events.
  • Attributes.

From here:

This example models a movie theater with one ticket counter selling tickets for three movies (next show only). People arrive at random times and try to buy a random number (1-6) of tickets for a random movie. When a movie is sold out, all people waiting to buy a ticket for that movie renege (leave the queue).

First of all, we load the libraries and prepare the environment.

The main actor of this simulation is the moviegoer, a process that will try to buy a number of tickets for a certain movie. The logic is as follows:

  1. Select a movie and go to the theater.
  2. At any moment, the moviegoer reneges if the movie becomes sold out (the “sold out” event is received).
  3. In particular, leave immediately if the movie already became sold out.
  4. Reach the ticket counter and stay in the queue. When the turn comes (counter is seized),
    1. Try to buy (seize the resource) tickets (randomly chosen between 1 and 6).
      • If there are not enough tickets, the moviegoer is rejected after some discussion.
    2. Provided the moviegoer has tickets, the reneging condition is aborted.
    3. Check the tickets available and, if at most one ticket is left…
      • Set instant rejection for future customers (at point 3.).
      • Send the “sold out” event (subscribed at point 2.) for current customers (waiting at point 4.).
  5. Release the ticket counter after the duration of the purchase.
  6. Enjoy the movie!

This recipe is directly translated into a simmer trajectory as follows:

which actually constitutes a quite interesting subset of simmer’s capabilities. The next step is to add the required resources to the environment env: the three movies and the ticket counter.

And finally, we attach an exponential moviegoer generator to the moviegoer trajectory and the simulation starts:

The analysis is performed with the help of dplyr:

Gas Station Refuelling


  • Standard resources.
  • Waiting for other processes.
  • Condition events.
  • Shared events.
  • Concatenating trajectories.
  • Loops.
  • Logging messages into the console.

From here:

This example models a gas station and cars that arrive for refuelling. The gas station has a limited number of fuel pumps and a fuel tank that is shared between the fuel pumps.

Vehicles arriving at the gas station first request a fuel pump from the station. Once they acquire one, they try to take the desired amount of fuel from the fuel pump. They leave when they are done.

The fuel level is reqularly monitored by a controller. When the level drops below a certain threshold, a tank truck is called for refilling the tank.

Parameters and setup:

SimPy solves this problem using a special kind of resource called container, which is not present in simmer so far. However, a container is nothing more than an embellished counter. Therefore, we can implement this in simmer with a global counter (GAS_STATION_LEVEL here), some signaling and some care checking the counter bounds.

Let us consider just the refuelling process in the first place. A car needs to check whether there is enough fuel available to fill its tank. If not, it needs to block until the gas station is refilled.

Now a car’s trajectory is straightforward. First, the starting time is saved as well as the tank level. Then, the car seizes a pump, refuels and leaves.

car <- trajectory() %>%
  set_attribute(c("start", "level"), function() 
    c(now(env), sample(FUEL_TANK_LEVEL[1]:FUEL_TANK_LEVEL[2], 1))) %>%
  log_("arriving at gas station") %>%
  seize("pump", 1) %>%
  # 'join()' concatenates the refuelling trajectory here
  join(refuelling) %>%
  release("pump", 1) %>%
    paste0("finished refuelling in ", now(env) - get_attribute(env, "start"), " seconds"))

The tank truck takes some time to arrive. Then, the gas station is completely refilled and the signal “gas station refilled” is sent to the blocked cars.

The controller periodically checks the GAS_STATION_LEVEL and calls the tank truck when needed.

controller <- trajectory() %>%
  branch(function() GAS_STATION_LEVEL / GAS_STATION_SIZE * 100 < THRESHOLD, 
         continue = TRUE,
         trajectory() %>%
           log_("calling the tank truck") %>%
  ) %>%
  timeout(10) %>%
  rollback(2, Inf)

Finally, we need to add a couple of pumps, a controller worker and a car generator.

env %>%
  add_resource("pump", 2) %>%
  add_generator("controller", controller, at(0)) %>%
  add_generator("car", car, function() sample(T_INTER[1]:T_INTER[2], 1)) %>%
#> 94: car0: arriving at gas station
#> 107: car0: finished refuelling in 13 seconds
#> 144: car1: arriving at gas station
#> 158: car1: finished refuelling in 14 seconds
#> 219: car2: arriving at gas station
#> 236.5: car2: finished refuelling in 17.5 seconds
#> 301: car3: arriving at gas station
#> 322.5: car3: finished refuelling in 21.5 seconds
#> 377: car4: arriving at gas station
#> 392.5: car4: finished refuelling in 15.5 seconds
#> 439: car5: arriving at gas station
#> 440: controller0: calling the tank truck
#> 454: car5: finished refuelling in 15 seconds
#> 535: car6: arriving at gas station
#> 597: car7: arriving at gas station
#> 696: car8: arriving at gas station
#> 740: controller0: tank truck arriving at gas station
#> 740: controller0: tank truck refilling 193 liters
#> 753: car7: finished refuelling in 156 seconds
#> 759: car9: arriving at gas station
#> 760: car6: finished refuelling in 225 seconds
#> 774.5: car8: finished refuelling in 78.5 seconds
#> 777: car9: finished refuelling in 18 seconds
#> 853: car10: arriving at gas station
#> 860: controller0: calling the tank truck
#> 874.5: car10: finished refuelling in 21.5 seconds
#> 953: car11: arriving at gas station
#> 988: car12: arriving at gas station
#> simmer environment: anonymous | now: 1000 | next: 1045
#> { Monitor: in memory }
#> { Resource: pump | monitored: TRUE | server status: 2(2) | queue status: 0(Inf) }
#> { Source: controller | monitored: 1 | n_generated: 1 }
#> { Source: car | monitored: 1 | n_generated: 14 }