-
-
Notifications
You must be signed in to change notification settings - Fork 42
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
Comments
(continuing from simmer-devel thread linked above)
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. |
The problem is that, as soon as the arrival gets kicked from the resource, there is no amount seized, so a method such as An attribute could be easily used to distinguish between the Anyway, let's make this work in the first place and then we'll see how to address that. |
@thigger: There's an initial implementation in the 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") |
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 |
Very interesting project, thanks for sharing. Looking forward to seeing the results! |
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? |
Yes, it's safe. It just replaces the drop-out trajectory. If |
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. |
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) |
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. |
Right now, there is no mechanism to handle unfinished arrivals:
queue_size_strict=TRUE
).queue_size_strict=TRUE
).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
.The text was updated successfully, but these errors were encountered: