Skip to content
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

add event "priority" to more flexibly deal with ties #236

Closed
achubaty opened this Issue Dec 9, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@achubaty
Copy link
Contributor

achubaty commented Dec 9, 2015

Currently, the event queue is FIFO when events are scheduled to be run at the same time.

This sets up a situation where certain events (e.g., those calculating summary stats) might be initially scheduled to be run at the end of a simulation, but as the simulation progresses other events may accumulate in the queue to be run AFTER the summary stats are done. Therefore, the summary stats don't include the changes to the data made by the subsequent events.

To deal with this, there should be a "priority" column in the event queue data.table which can be used as the secondary key. 'Normal' events can be designated e.g., priority 5, and 'special' events that always need to run before/after normal events can be designated priority 0/10, respectively. This allows for all sorts of flexibility.

@achubaty achubaty self-assigned this Dec 9, 2015

@achubaty achubaty added this to the v1.0.4 milestone Dec 9, 2015

@SteveCumming

This comment has been minimized.

Copy link
Contributor

SteveCumming commented Dec 9, 2015

I think it might be more in keeping with the overall design to have some
defined "times" associated with endings of various kinds (a module
invocation), a simulation run, with which difference event types might be
associated.

I worry that requiring people to keep track of priorities might lead to
unforeseen dependencies.

sc

On Wed, Dec 9, 2015 at 4:38 PM, Alex Chubaty notifications@github.com
wrote:

Currently, the event queue is FIFO when events are scheduled to be run at
the same time.

This sets up a situation where certain events (e.g., those calculating
summary stats) might be initially scheduled to be run at the end of a
simulation, but as the simulation progresses other events may accumulate in
the queue to be run AFTER the summary stats are done. Therefore, the
summary stats don't include the changes to the data made by the subsequent
events.

To deal with this, there should be a "priority" column in the event queue
data.table which can be used as the secondary key. 'Normal' events can be
designated e.g., priority 5, and 'special' events that always need to run
before/after normal events can be designated priority 0/10, respectively.
This allows for all sorts of flexibility.


Reply to this email directly or view it on GitHub
#236.

Steve Cumming
Canada Research Chair in Boreal Ecosystems Modelling
Département des sciences du bois et de la forêt
Université Laval
(418) 656-2131 poste 2593

@achubaty

This comment has been minimized.

Copy link
Contributor Author

achubaty commented Dec 9, 2015

@SteveCumming Eliot and I had discussed stetting some preset priorities that can be easily accessed via a function call by the user. This allows us to update the values as necessary, without breaking the user's code. E.g., if normal priority is 5:

.normal <- function() {
  return(5)
}

the user can schedule things with or without specifying the prority, as the default is .normal():

# normal event priority
scheduleEvent(sim, time, "moduleName", "eventName") # default is .normal()
scheduleEvent(sim, time, "moduleName", "eventName", .normal())

# higher priority
scheduleEvent(sim, time, "moduleName", "eventName", .normal()-1)

# lower priority
scheduleEvent(sim, time, "moduleName", "eventName", .normal()+1)

Additional presets can be added.

@achubaty

This comment has been minimized.

Copy link
Contributor Author

achubaty commented Dec 9, 2015

@eliotmcintire some core functionality, such as loading and saving, needs non-default priorities. What do you think of the following?

## priority.R

.first()   # wrapper for .highest(); returns 1
.highest() # returns 1

.last()    # wrapper for .lowest(); returns 10
.lowest()  # returns 10

.normal()  # returns 5

built in event types:

  • checkpoint: .last()
  • load: .first()
  • save: .last()
  • progress: .last()

achubaty added a commit that referenced this issue Dec 9, 2015

@eliotmcintire

This comment has been minimized.

Copy link
Contributor

eliotmcintire commented Dec 9, 2015

@achubaty Those seem reasonable.
@SteveCumming The basic notion is that a modeler doesn't need to add priorities to their scheduling. The default is as per before... i.e., if something is scheduled for time = 5, then it will run at time=5. If two things are run at time=5, then they will be first in first out (as Alex said). So, this priority stuff is mostly for advanced usage when it seems contrived to schedule something for 5.0000001 to "make sure" it happens at the end of time=5. The use cases described (i.e., default saving events, default plotting events, etc.) should likely be good candidates.

@achubaty achubaty referenced this issue Dec 18, 2015

Closed

Development #240

@achubaty achubaty closed this in b4b66fe Jan 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.