New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle unfinished arrivals #177

Closed
Enchufa2 opened this Issue Nov 29, 2018 · 11 comments

Comments

Projects
None yet
2 participants
@Enchufa2
Copy link
Member

Enchufa2 commented Nov 29, 2018

Right now, there is no mechanism to handle unfinished arrivals:

  • Arrivals dropped from a queue (when the queue size is shrinked and queue_size_strict=TRUE).
  • Arrivals preempted from a server (when the capacity is shrinked or due to another higher-priority arrival, with queue_size_strict=TRUE).
  • Leaving arrivals (from the leave activity).

A new mechanism is proposed to set a handler for them: a trajectory that would be followed after such events happen. See this thread for further details.

Possible names for the new activity: catch, cleanup, handle_exception, handle_unfinished.

@thigger

This comment has been minimized.

Copy link

thigger commented Nov 29, 2018

(continuing from simmer-devel thread linked above)

There are already flags to show what happened. If the arrival was
preempted or dropped from a queue, get_mon_arrivals(per_resource=TRUE)
will show the seize event, and from the activity time you know whether
it was a preemption or a queue drop. If there is no info in such a
table, then the arrival left the trajectory using "leave".

Are any of these accessible from within a trajectory during the simulation? I guess this might be a separate enhancement but I can't presently see any way of "knowing" whether a patient currently has a bed seized (for example). Even though the "seize" activity completed successfully, the bed may have been pre-empted away so it's now gone. (I'm trying to find a temporary workaround to my bed problem using signals, but I can't see how an arrival can "know" it's been put back in the queue)

I guess I'm looking for get_currently_seized(.trj, resource) which returns the amount of the resource currently seized or similar. And/or a getter to know which of the three situations you describe above have occurred (so I can branch down different trajectories). In my own project only the second will happen, but as you say it would be useful to have this generic.

@Enchufa2

This comment has been minimized.

Copy link
Member

Enchufa2 commented Nov 29, 2018

The problem is that, as soon as the arrival gets kicked from the resource, there is no amount seized, so a method such as get_currently_seized wouldn't help you.

An attribute could be easily used to distinguish between the leave case and the resource case. But I don't see right now an easy way to distinguish between a queue drop and a server drop.

Anyway, let's make this work in the first place and then we'll see how to address that.

Enchufa2 added a commit that referenced this issue Nov 29, 2018

@Enchufa2

This comment has been minimized.

Copy link
Member

Enchufa2 commented Nov 29, 2018

@thigger: There's an initial implementation in the handle-unfinished branch. Give it a try, please, to see if this works for you. I've tested the following:

library(simmer)

rejected <- trajectory() %>%
  log_("I've been kicked")

patient <- trajectory() %>%
  handle_unfinished(rejected) %>%
  seize("bed") %>%
  timeout(10) %>%
  release("bed")

blocker <- trajectory() %>%
  set_queue_size("bed", 0) %>%
  set_capacity("bed", 0)

env <- simmer(verbose=TRUE) %>%
  add_resource("bed", preemptive=TRUE, queue_size_strict=TRUE) %>%
  add_generator("dummy", patient, at(0, 0)) %>%
  add_generator("blocker", blocker, at(5)) %>%
  run()

And it seems to work fine. The same if I change the patient trajectory with this one:

patient <- trajectory() %>%
  handle_unfinished(rejected) %>%
  leave(1) %>%
  log_("Never reached")
@thigger

This comment has been minimized.

Copy link

thigger commented Nov 29, 2018

Brilliant, thanks for the incredibly quick response - looks perfect and like it should work with my test project - I'm fairly locked down with R packages and compiling in the hospital but I should be able to try it when I get home.

For interest's sake - this is the project

@Enchufa2

This comment has been minimized.

Copy link
Member

Enchufa2 commented Nov 29, 2018

Very interesting project, thanks for sharing. Looking forward to seeing the results!

@thigger

This comment has been minimized.

Copy link

thigger commented Nov 29, 2018

Just dropped it into my test project (still based on the bank example!) and it seems to be working as expected with no customers disappearing silently as they did before - thanks! Presumably it's safe to call handle_unfinished more than once in a trajectory as the patient moves around the hospital?

@Enchufa2

This comment has been minimized.

Copy link
Member

Enchufa2 commented Nov 29, 2018

Yes, it's safe. It just replaces the drop-out trajectory. If NULL is provided, it unsets the trajectory.

@Enchufa2 Enchufa2 closed this in df3c1f0 Nov 30, 2018

@Enchufa2

This comment has been minimized.

Copy link
Member

Enchufa2 commented Nov 30, 2018

Merged. The next release on CRAN will be in January.

Regarding how to distinguish between different cases, I'm pretty sure that this can be done by looking at the last monitored values in the arrivals table. The problem is that current methods return all the rows. So I plan to revisit this as part of #169.

@thigger

This comment has been minimized.

Copy link

thigger commented Nov 30, 2018

Brilliant, thanks - will that mean it's safe to call get_mon_arrivals etc during the simulation? (eg to help decide which trajectory to take)

@Enchufa2

This comment has been minimized.

Copy link
Member

Enchufa2 commented Nov 30, 2018

It's safe, but it's very inefficient (the whole table is copied to R for each call) and thus not recommended. That's why I opened #169.

@Enchufa2

This comment has been minimized.

Copy link
Member

Enchufa2 commented Dec 2, 2018

Related to this, #25 and #179 have been implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment