Issue with simultaneous arrivals trying to select and then seize a resource

[Mat S.]

I’m modeling the ability of a given fleet of vehicles to keep up with a demand schedule given breaks and maintenance. I’m trying to see how well a given number of available cars can maintain a required level of operations given different route lengths and maintenance requirements.

 

But, I’m running into problems whenever I have multiple arrivals at the same time (in my model the need to have vehicles operate 2 at a time).  It works properly with only one arrival (only one generator) and I’ve tried changing the way that the generators are defined by haven’t addressed the problem. 

 

Is the problem somewhere on the trajectory side that causes problems with the select and seize operation?  Any help would be much appreciated.

 

 

So:

route <-

  trajectory("Route Path") %>%

  log_("depart") %>%

  set_attribute("start_time", function() {now(fleet)}) %>%

  select(c("car1", "car2", "car3", "car4"), policy = "round-robin-available") %>%

  seize_selected(amount=1) %>%

  timeout(function() rnorm(1, 20)) %>%  ## in the actual code I’m sampling from a table of repair times

  log_(function() {paste("Delayed: ", now(fleet) - get_attribute(fleet, "start_time"))}) %>%

  release_selected() %>%

  log_("return")

 

 

fleet <-

  simmer("fleet") %>%

  add_resource("car1", 1, 0) %>%

  add_resource("car2", 1, 0) %>%

  add_resource("car3", 1, 0) %>%

  add_resource("car4", 1, 0) %>%

  add_generator("MissionReq", route, from_to(1, 900, function() {10})) %>%

  add_generator("MissionReq2", route, from_to(1.01, 901, function() {10}))

 

fleet %>% run(until = 100)

fleet %>% get_mon_arrivals()

 

Note the problem below – half of the responses have no activity time and do not finish, even when there are resources available:

 

 

           name start_time end_time activity_time finished replication

1  MissionReq20       1.01  1.01000       0.00000    FALSE           1

2  MissionReq21      11.01 11.01000       0.00000    FALSE           1

3  MissionReq22      21.01 21.01000       0.00000    FALSE           1

4   MissionReq0       1.00 21.28716      20.28716     TRUE           1

5  MissionReq23      31.01 31.01000       0.00000    FALSE           1

6   MissionReq1      11.00 32.38203      21.38203     TRUE           1

7  MissionReq24      41.01 41.01000       0.00000    FALSE           1

8   MissionReq2      21.00 41.03270      20.03270     TRUE           1

9   MissionReq3      31.00 50.57621      19.57621     TRUE           1

10 MissionReq25      51.01 51.01000       0.00000    FALSE           1

11 MissionReq26      61.01 61.01000       0.00000    FALSE           1

12  MissionReq4      41.00 61.77214      20.77214     TRUE           1

13 MissionReq27      71.01 71.01000       0.00000    FALSE           1

14  MissionReq5      51.00 71.37239      20.37239     TRUE           1

15 MissionReq28      81.01 81.01000       0.00000    FALSE           1

16  MissionReq6      61.00 82.06666      21.06666     TRUE           1

17 MissionReq29      91.01 91.01000       0.00000    FALSE           1

18  MissionReq7      71.00 91.73528      20.73528     TRUE           1

[Iñaki Ucar]

On Fri, 22 May 2020 at 00:02, Mat S. <matthew...@gmail.com> wrote:

I’m modeling the ability of a given fleet of vehicles to keep up with a demand schedule given breaks and maintenance. I’m trying to see how well a given number of available cars can maintain a required level of operations given different route lengths and maintenance requirements.

 

But, I’m running into problems whenever I have multiple arrivals at the same time (in my model the need to have vehicles operate 2 at a time).  It works properly with only one arrival (only one generator) and I’ve tried changing the way that the generators are defined by haven’t addressed the problem. 

 

Is the problem somewhere on the trajectory side that causes problems with the select and seize operation?  Any help would be much appreciated.

Interesting. The issue here is that, when you assign a trajectory definition to a generator, the generator makes a copy of that trajectory (so that you can break that definition afterwards and this doesn't affect the generator). Therefore, if you pass the same trajectory definition to two generators, both have a different internal object, which means that the select activities that they both see are independent.

In other words, it's not a problem of timing or simultaneous events. What happens is that, due to simmer's internal architecture, those built-in policies work for one generator, and are independent across generators (i.e., you have one round-robin running for MissionReq and another round-robin for MissionReq2).

To make it work as you intend, you have two options: 

1. Use only one generator, so that all the arrivals "see" the same policy.
2. Implement the round-robin method yourself as an R function, thus ensuring that the same state is shared across any number of generators you may define.

Now, we could discuss whether this is a feature or an issue. This is a similar situation to what happens with batches. Ideally, trajectory definitions should not hold state, because they are like templates. But sometimes some activities really need to hold state, like batches. So in that case, we added an argument "name" to be able to share batches across trajectories and generators. I'm not a very big fan of such a solution though.

Iñaki

  

--
You received this message because you are subscribed to the Google Groups "simmer-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simmer-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/simmer-devel/d7df9223-2238-4076-8297-ca9ea139a8f1%40googlegroups.com.

--

Iñaki Úcar

[Mat S.]

Many thanks for your explanation.  Could I ask you to provide some additional guidance for how to make it work with only one generator?  I’m encountering similar problems when I try that even when using a few different methods.

 

I’ve tried specifying start time through add.dataframe and have run into similar problems using the rep command that you have described in other posts [though here, my code is questionable: add_generator("MissionReq", route, function() c(10), rep (0, 1))  ].

 

The common issue is that however I que up the generator, I have problems getting all of the results out of the trajectory.  Any help you could provide would be greatly appreciated.

 

For example, if I use a dataframe of departure times:

 

add_dataframe("MissionReq", route, MissionTimes)

 

using the dataframe generated by the code below:

##

 

MissionFreq <-8

MissionTimes <-0

Counter <-0

for (i in 1:(100)) {

  Counter <-i

  MissionTimes <- rbind(MissionTimes, Counter*MissionFreq)

  MissionTimes <- rbind(MissionTimes, (Counter*MissionFreq)+0.1)

}

 

MissionTimes <- as.vector (MissionTimes)

MissionTimes <-as.data.frame(MissionTimes)

names(MissionTimes)[names(MissionTimes) == "MissionTimes"] <- "time"

 

##

 

I get a similar problem that half of the start times are skipped.  The data frame has entries for 8 and 8.1, 16 and 16.1, etc

 

         name start_time end_time activity_time finished replication

1 MissionReq0        0.0 20.79040      20.79040     TRUE           1

2 MissionReq1        8.0 27.66714      19.66714     TRUE           1

3 MissionReq2       16.1 37.86461      21.76461     TRUE           1

4 MissionReq3       32.1 52.93912      20.83912     TRUE           1

5 MissionReq4       48.2 67.78252      19.58252     TRUE           1

6 MissionReq5       72.2 91.78923      19.58923     TRUE           1

[Iñaki Ucar]

The simplest way to achieve this is to remove one generator and add a clone(2) on top of the trajectory. The only disadvantage (or advantage, it depends) is that you get the same identifier for each pair of arrivals in the output data frame.

--

You received this message because you are subscribed to the Google Groups "simmer-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simmer-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/simmer-devel/0903498c-0246-4c5d-b566-0466dceda222%40googlegroups.com.

--

Iñaki Úcar

[Iñaki Ucar]

BTW, here's a short sketch of the issue here [1]. We need to either document this behaviour or fix it. The round-robin policy is the only one that requires a shared state, so it's the only one affected by this kind of issue. I'm in favour of fixing it, but I still need to figure out what's a reasonable solution here.

[1] https://github.com/r-simmer/simmer/issues/233

--

Iñaki Úcar

[Iñaki Ucar]

FYI, this is fixed in the development version on GitHub. It will be available in the next CRAN update.

Iñaki

--

Iñaki Úcar