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

max residual window #21

Closed
fscottfoti opened this issue Feb 25, 2015 · 5 comments
Closed

max residual window #21

fscottfoti opened this issue Feb 25, 2015 · 5 comments

Comments

@fscottfoti
Copy link
Contributor

So I don't keep bombarding Dave with these questions, I might start posting them here. I'm working my way through the non mandatory tours model for MTC for full time workers and ran into the concept of the maximum residual window and the expression ln(max(window1,max(window2,window3))+1) - are these time windows? Can someone elucidate a bit? Thanks!

@guyrousseau
Copy link

We have the exact same thing here @arc with our ABM (and perhaps SANDAG too?), this is related to the scheduling of non-mandatory tours and the time availability that remains after higher priority tours are scheduled. Regarding the time windows, they’re related to the 30-minute temporal resolution that we’re using for time of day choice.

So these are the time windows that remain after the higher priority tours, which comprise both mandatory tours and joint tours, are scheduled. The three terms in the expression are defined as follows:

window1 – total time available between the beginning of the day and the start of the first higher priority tour
window2 – total time available between end of first higher priority tour and start of last priority tour
window3 – total time available between end of last higher priority tour and end of the day

So the maximum residual window is simply the largest of these three time windows. Note that since the time periods are identified only in 30-minute increments, then the windows are also measured in 30-minute increments.

I hope this helps, you guys keep up the good work.

@fscottfoti
Copy link
Contributor Author

That does help thanks!

@guyrousseau
Copy link

Some further clarification regarding the question about the maximum residual time window variable used in the prediction of non-mandatory tour frequency for workers. Suppose for the purpose of the discussion that the full day consists of 18 time periods (in our model there are 40 total time periods). Suppose further that either mandatory and/or joint tours have been scheduled for this person, in the periods shown in yellow below. The available time windows are then shown by the periods in green, but the model also assumes some overlap, because each time window is 30 min long so part of a window may be available even if a tour has been scheduled within it. Specifically for this example, the model calculates the three time windows as follows:

Window1 – available time periods = {1,2,3,4} = 4 periods
Window2 – available time periods = {6,7,8,9,11,12,13} = 7 periods
Window3 – available time periods = {14,15,16,17,18} = 5 periods

And

maximumResidualWindow = 7

abm

@fscottfoti
Copy link
Contributor Author

OK, piggybacking off of this topic, in the mandatory tour scheduling model, I see several variables that also have to with the windows which I'm trying to figure out. Things like Previously-scheduled tour begins in this arrival hour and Adjacent window exists after this arrival hour - first tour interaction.

I also think that since I'm doing mandatory tour scheduling, no tours outside of this model have actually been scheduled. So for the first variable, the previously scheduled tour is actually referring the first (already scheduled) mandatory tour when scheduling the second mandatory tour. And this means that the first scheduled tour is scheduled to begin in the same hour as the second (currently being scheduled) tour is scheduled to end. I'm thinking I don't need windows for this - I just match up the times.

For the second variable I need to start keeping track of the complete set of time periods for the model. I'm looking for whether there is an adjacent window before the start time of the tour that is currently being scheduled. This implies I need to start keeping track of all the "blocked out" time for every person being modeled - is that done in CDAP or is this more typically computed on the fly based on a given person's currently scheduled list of tours?

@guyrousseau
Copy link

It's my understanding that the scheduling of mandatory activities is generally considered a higher priority decision than any decision regarding non-mandatory activities for either the same person or for the other household members. As the result of the mandatory activity scheduling, “residual time windows” are calculated for each person and their overlaps across household members are estimated. Time window overlaps, which are left in the daily schedule after the mandatory commitment of the household members has been made, constitute the potential for joint activity and travel.

For instance, the ARC model (and most likely MTC & SANDAG too) utilizes direct availability rules for each subsequently scheduled tour, to be placed in the residual time window left after scheduling tours of higher priority. This conditionality ensures a full consistency for the individual entire-day activity and travel schedule as an outcome of the model. Also in our model structure, the tour-scheduling model is placed after destination choice and before mode choice. Thus, the destination of the tour and all related destination and origin-destination attributes are known and can be used as variables in the model estimation. This provides us with ‘induced demand’ effects on the generation and scheduling of joint tours. The frequency and duration of mandatory tours affects whether or not joint tours are generated. The parameter values for our CDAP model were estimated from our ARC household travel survey.

That said, I'll try to follow-up with additional details regarding time windows / availability effects, namely:
"Previously-scheduled tour begins in this arrival hour" and
"Adjacent window exists after this arrival hour - first tour interaction"

@bstabler bstabler closed this as completed Apr 7, 2016
bstabler added a commit that referenced this issue Aug 11, 2020
* move other resources into folder since examples now part of package as well

* Add new skim lookups for the TNC bridge tolls return charges below.
- odr - origin to destination reverse
- dor - destination to origin reverse

TNC revisions:
- Update TNC bridge tolls so return charges are included
- Added ride-hail single and taxi constants for trip mode choice within ride-hail tour mode choice
- Reduced TNC wait time mean and sd slightly to in the highest density category
- Turned on origin density index constant (already used for walk, bike and walk-transit modes) for TNC single and TNC shared

* allow for a small number of stop locations within walking distance

* updated tnc ascs from tm 1.5 run

* add notebooks

* add readme for notebooks folder

* Interactive tutorial (#3)

* Add verification jupyter notebook

* add shapefile

* code review

* cleanup

* update shapefile note

Co-authored-by: Ben Stabler <bstabler@users.noreply.github.com>
Co-authored-by: bstabler <benstabler@yahoo.com>

* clean up folder setup

* finish summaries notebook

* updated getting started tutorial

* continue work on the recipe book

* estimation notebooks for larch (#19)

* notebooks for auto ownership and workplace location estimation

* minimally functional larch estimation mode notebooks

includes auto ownership, workplace location, tour mode
requires larch >= 5.3.7

* revised notebooks

uses new EDB for tour_mode_choice

* update example EDBs and estimation notebooks

* Fix tour mode choice notebook (#20)

Fill in missing values in values DataFrame

* update notebook

* update getting started notebook

* more notebook updates

* notebook for estimating school location (#21)

* create two and three zone test data, see also https://github.com/ActivitySim/activitysim/wiki/Multiple-Zone-Systems-Design

* update notebook markdown

* after merge from develop, resolve conflicts, pycodestyle, and add header to school location notebook

* small doc fix

* update tests EXPECT_TOUR_COUNT

* resolve conflict

Co-authored-by: Blake <blake.rosenthal@rsginc.com>
Co-authored-by: Jeffrey Newman <jeff@newman.me>
Co-authored-by: Jeff Doyle <toliwaga@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants