Should we reject a seize with an amount exceeding the limits of a given resource? about simmer HOT 6 CLOSED

I guess it depends... (doesn't it always)

Check the example at http://simpy.readthedocs.org/en/latest/examples/gas_station_refuel.html

In this case the resource's capacity can be 'upped' during the simulation, and thus seizing more than the current limits is acceptable. A quick loose translation with some functionality we currently don't have:

GAS_STATION_SIZE = 200     # liters
THRESHOLD = 10             # Threshold for calling the tank truck (in %)
TANK_TRUCK_TIME = 300      # Seconds it takes the tank truck to arrive
T_INTER = c(30, 300)        # Create a car every [min, max] seconds



car<-
  create_trajectory("car") %>%
  set_attribute("fuel_level", function() rpois(1, 50)) %>%
  seize("fuelpump", function(attrs) attrs[["fuel_needed"]] ) %>% # fill up car's gas tank
  timeout(function(attrs) attrs[["fuel_needed"]] / 10)

fuel_truck <-
  create_trajectory("fuel_truck") %>%
  timeout(TANK_TRUCK_TIME) %>%
  put("fuelpump", 
      function(attrs){
        attrs$__resource$fuelpump$capacity - attrs$__resource$fuelpump$level
  }) 
  ## an extension of the 'release' which ups the level of the resource 
  ## (could also simply be the release(), depends on how this is implemented on the resource side, see env creation)
  ##
  ## we currently can't determine resource level during the run; we could e.g. pass it along with the attributes
  ## so maybe we should also pass the attributes as a list instead of a named vector; eases the syntax a bit and allows for nesting...

gas_station_control<-
  create_trajectory("gas_station_control") %>%
  ## we also can't initiate the creation of a new generator by an arrival 
  ## while there are some ways to circumvent this in this model, it would be a nifty addition
  ## we also don't have a straightforward conditional() option, which would also be nifty :)
  conditional(when=function(attrs) attrs$__resources$fuelpump$level<THRESHOLD,
              what=generate("fuel_truck", 
                            trajectory=fuel_truck, 
                            dist=minutes_from_now(0))) %>% 
  # minutes_from_now is then an adjustment of at() which takes into account sim->now()
  timeout(20) %>%
  rollback(2, times=Inf)

env<-
  simmer() %>%
  add_generator("car", car, function() sample(1,T_INTER[1] : T_INTER[2]))) %>%
  add_resource("fuelpump", GAS_STATION_SIZE) %>%
  ## depending on implementation this could result in a different type of resource, a deplatable one:
  ## add_resource("fuelpump", 200, type="depletable')
  run()

from simmer.

Yes, but no. I mean, the gas station is a resource like ours and it cannot be seized beyond its capacity. On the other hand, the fuel pump is conceptually another type of resource: it is a container. And, well, check my recent addition to the TODO list... 😄

from simmer.

And this question is closely related to #21, because if we are going to implement #21 more or less as defined there, then the capacity can grow. But then another question comes to my mind... is it worth implementing #21? Because we could simply visit different resources with different capacities depending on the time.

from simmer.

Completely on board with the TODOs.

Regarding #21, if we create functionality to let the capacity increase/decrease during a run', the functionality described in #21 can simply be achieved by introducing a convenience function; i.e. an arrival starting at 0 which increases / decreases capacity at specified times.

Which brings to mind; what to do when you decrease capacity (e.g. to 0) when something is processing. Do you interrupt it or let it finish? Should that be another parameter?

from simmer.

Let's move the discussion about #21 to #21 to keep things tidy. 😉 Because, thinking more about it, this question remains independently of that feature.

The point is, I cannot think of use cases for one or the other option, i.e., enqueue the arrival or reject it. From my point of view, if somebody comes up trying to seize an amount larger than the capacity (of a standard resource, not a container), he/she is doing bad programming, plain and simple, until a good use case proves me wrong.

Nonetheless, if we choose rejection, the enqueueing case is automatically excluded. But if we choose the latter, always there are ways to do the trick and reject those arrivals.

Summing up, I vote for leaving matters as they are regarding this issue.

from simmer.

Don't necessarily agree with it being bad programming. That said, I would also leave it as is; i.e. leaving the arrival enqueued.

Closing for now.

from simmer.