Resource monitoring: before or after seize/release

[Enchufa2]

This is just a reminder for me to think about it, but also a discussion forum for throwing pros/cons and, eventually, deciding. Wrapping up:

• Before: The time diffs are aligned when calculating statistics, but we lose the last observation.
• After: The time diffs are misaligned and some reengineering is needed to get the right statistics, but we lose the first observation.

[bart6114]

my 2¢

the end user should have access to all activity stats (this includes the last observation). imo this puts us in the after scenario (where some reengineering has to realign the vectors).

[Enchufa2]

On the other hand, one could argue that the after scenario deprives the user of the first observation... 😉

[Enchufa2]

Let's bring some code to the discussion. This is what we are doing now:

mutate(mean = cumsum(value * diff(c(0,time))) / time)

And I recovered what we were doing when monitoring was performed after:

mutate(mean = c(0, cumsum(head(value,-1) * diff(time)) / tail(time,-1)))

So the reengineering consisted of removing the last observation! 😄

[bart6114]

indeed 😬

something related:

library(simmer)

t0<-create_trajectory() %>%
  seize("server", 2) %>%
  timeout(5) %>%
  release("server")

env<-
simmer() %>%
  add_resource("server", 1) %>%
  add_generator("test", t0, at(0)) %>%
  run()

get_mon_arrivals(env)

What would be the expected/desired output in this case? Currently it returns:

[1] name          start_time    end_time      activity_time finished     
<0 rows> (or 0-length row.names)

Intuitively I would expect one row were finished is FALSE.

[Enchufa2]

Arrival reporting is executed when an arrival leaves the trajectory: because 1) it has reached the end or 2) it was rejected. In this case, the arrival is requesting 2 units when the resource has only 1, so the arrival will be enqueued forever. But it has not finished its lifetime, so nothing is reported.

This is a consequence of the very flexibility that the trajectory-based seize/release system offers: the programmer is responsible for creating well-formed trajectories, and simply this is not.

[bart6114]

I understand the reasoning behind it, just adding to the discussion (trying to speak from the side of the end-user 😃 ).

[Enchufa2]

This is interesting as a separate question (#36 opened), but I think it is not important for this discussion (the resource will never be seized).

[Enchufa2]

After giving much thought, I think that probably you are right: the user would expect an observation to be the snapshot of that instant, not of the last interval. The definitive argument that I've found in favour of your point is the behaviour of stepfun().

So, I'll perform the monitoring after, starting from the next release. This requires a minor version change and a careful explanation.

[bart6114]

great 👍