Incomplete trajectory after do_parallel or clone/trap/syncronize

[awaddington24]

Problem

The main trajectory does not always complete after using simmer.bricks::do_parellel or clone, trap, and synchronize.

Attributes and logs execute up until synchronize(), then cease. get_mon_arrivals shows all end_times as NA (note: in a more complicated version of this, some transactions did complete, but the majority do not.)

Why is this happening, and how can I ensure all transactions complete the main trajectory after the parallel?

Background

In this simulation, customers decide to buy item_1, item_2, or both based on a purchase probability. They must buy at least one item, so there is also a failsafe that if neither item is purchased, it forces a purchase of item_1.

Clerks prepare the orders for the customer. Any clerk may perform any task but only one task per clerk at a time. Each item has a different purchase trajectory, which competes for a common resource (clerks).

When multiple clerks are available, the items may be prepared simultaneously, so the purchase trajectories are performed in parallel.

testing with log_() and set_attribute() I have determined that the trajectories within do_parallel (or clone) are executing as expected. but the synchronization never occurs.

The Code

select_by_probability <- function(p) {
  # selects 1 or zero based on probability (p) of 1
  sample(c(0,1), 1, prob = c(1-p, p))
}
signal <- function() get_name(env)

p_buy_1 <- 0.50 # probability of purchasing item 1
p_buy_2 <- 0.50 # probability of purchasing item 2

env <- simmer("env")

# Define a trajectory for each item
t_buy_1 <- trajectory() %>%
  seize("clerk") %>%
  log_("Bought item 1") %>%
  timeout(10) %>%
  release("clerk")

t_buy_2 <- trajectory("item_2") %>%
  seize("clerk") %>%
  log_("Bought item 2") %>%
  timeout(15) %>%
  release("clerk")

# Define the main trajectory
t_transaction <- trajectory() %>%
  set_attribute("bought_item_1", function() select_by_probability(p_buy_1)) %>%
  set_attribute("bought_item_2", function() select_by_probability(p_buy_2)) %>%
  set_attribute("items_bought", 
                function() sum(
                  get_attribute(env, "bought_item_1"),
                  get_attribute(env, "bought_item_2"))
  ) %>%
  # Clone the trajectory for each item
  clone(
    n = 4,
    trajectory("original") %>%
      trap(signal) %>%
      wait() %>%
      wait() %>%
      wait() %>%
      untrap(signal),
    trajectory("item_1") %>%
      branch(
        function() ifelse(get_attribute(env, "bought_item_1") == 1, 1, 2),
        continue = c(TRUE, TRUE),
        t_buy_1 %>% log_("t_buy_1 completed"),
        trajectory() %>% log_("no item 1")
      ) %>%
      send(signal),
    trajectory("item_2") %>%
      branch(
        function() ifelse(get_attribute(env, "bought_item_2") == 1, 1, 2),
        continue = c(TRUE, TRUE),
        t_buy_2 %>% log_("t_buy_2 completed"),
        trajectory() %>% 
          log_("no Item 2")
      ) %>%
      send(signal),
    trajectory("items_bought") %>%
      branch(
        function() ifelse(get_attribute(env, "items_bought") < 1, 1, 2),
        continue = c(TRUE, TRUE),
        t_buy_1 %>%
          set_attribute("forced_purchase", 1)%>%
          log_("forced purchase"),
        trajectory() %>% log_("no forced purchase")
      ) %>% 
      send(signal)
  )%>%
  log_("waiting to synchronize...") %>%
  synchronize(wait = TRUE, mon_all = TRUE) %>%
  log_("sync'd") %>%
  log_("continuing")

# Run the simulation
set.seed(1234)
env <- env %>%
  add_resource("clerk", capacity = 2) %>%
  add_generator("customer", t_transaction, 
                distribution = at(c(1, 200)),
                mon = 2)

env %>% run(until = 5000)

plot(get_mon_resources(env))

Log

1: customer0: Bought item 1
1: customer0: no Item 2
1: customer0: waiting to synchronize...
1: customer0: no forced purchase
1: customer0: waiting to synchronize...
11: customer0: t_buy_1 completed
11: customer0: waiting to synchronize...
200: customer1: no item 1
200: customer1: waiting to synchronize...
200: customer1: no Item 2
200: customer1: waiting to synchronize...
200: customer1: Bought item 1
210: customer1: t_buy_1 completed
210: customer1: forced purchase
210: customer1: waiting to synchronize...
simmer environment: env | now: 5000 | next: Inf
{ Monitor: in memory }
{ Resource: clerk | monitored: TRUE | server status: 0(2) | queue status: 0(Inf) }
{ Source: customer | monitored: 2 | n_generated: 2 }

From this, I see that customer0 bought item_1 not item_2 and was not forced to make a purchase. Because there was no item 2 purchased or forced purchase, those trajectories are immediately complete and start waiting to sync. When the clerk finishes preparing item 1, it waits to sync; however, this is the last trajectory, so we should then see a log_ entry for "sync'd" but do not. The trajectories never sync.

Customer1 chooses neither option so is forced to buy item 1. Again, all trajectories complete, but do not synchronize.

Other Trouble Shooting

• do_parellel yields the same issue
• Omitting the resources from t_buy_1 and t_buy_2 trajectories has the same result, so it's not as I feared an issue of not being able to use common resources in parallel (or if it is we haven't got there yet).
• In a more complex version, I removed all trajectories and added them back in one at a time. The results of that test were not helpful.

Thank you in advance for your help and for creating/maintaining this package; it is awesome.

[Enchufa2]

The issue is that you have too many things happening at the same time. Several send() happen instantaneously one after the other and are seen as a single signal (see the sd.queue trajectory here for an equivalent problem). Therefore, your original arrival is still wait()ing. Fortunately, this is easy to fix by just adding a few null timeouts at the proper places. The proper place is just before the send() activities, as demonstrated in the previous link. I.e., this pattern:

  ...
  timeout(0) |>
  send(signal) |>
  ...

etc. We may need to add those null timeouts in the do_parallel function too.

[Enchufa2]

In fact, I'm not sure that adding a null timeout before send() is always the right choice. It is certainly required for tasks that happen instantaneously, like your use case, but it may cause trouble in other cases. So I think that it's better to leave do_parallel as it is now, and it should be the user's responsibility to add a timeout(0) at the end of instantaneous tasks.

[awaddington24]

I finished testing this on my simple example and my more complex version.

timeout(0) before send(signal) fixed the issue. Thank you!

I also added timeout(0) before seizing the clerk at the start of each parallel trajectory. I'm unsure if that was necessary, but it works and follows the same logic of conflicting simultaneous activities.

Fantastic package. Thanks again for your help.

[Enchufa2]

Thanks for confirming!