-
Notifications
You must be signed in to change notification settings - Fork 99
Phase 3 Amendment Scope of Work
The period of performance for this scope of work is the first half of 2018. See the Phase 3 Scope of Work for work completed in 2017.
Task 1: Project Management
Task 2: Joint Tour models
Task 3: Stop-Level Models
Task 4: Complete Initial Implementation of All Sub-Models
The purpose of this first task is to manage the overall project, including invoicing and conference calls with the project team, and coordination with the AMPO agency partners. All deliverables, including meeting notes, software, tests, documentation, and issue tracking will be managed through GitHub. UrbanLabs will twice review project progress and QA/QC select project deliverables, as identified by the AMPO partners.
Deliverable(s): (Due 24 weeks from NTP)
- Management of Bi-Weekly Meetings
- Pre- and Post-Meeting Notes
- Invoicing and Progress Reports
- Client Coordination
- QA/QC of Select Deliverables
Comments
- XXXXX
The goal of this task is to implement the joint tour frequency, party composition, person participation, scheduling, and destination sub-models. The joint tour mode model will also be implemented using the existing tour mode choice model.
The joint tour frequency and party composition models are relatively straightforward and should be easily vectorized. The joint tour person participation model currently loops through household persons until a valid tour party is formed. Within the loop, a switch statement based on the party composition sets up and solves the relevant expression file for a) adults only, b) children only, or c) mixed, adults and children. After solving the relevant model, it checks for a valid party and if not, then it repeats the participation choice with new random numbers.
Vectorizing the joint tour person participation model will require re-structuring the problem into a series of pandas tables with rows and columns being persons and joint tours or vice versa. The goal is to switch from a for loop within each tour to a for loop that operates on all relevant tours at once. It will also require the calculation of available person time windows, which is required for the partially implemented duration models as well. These calculations will likely be added to the household and person tables as methods to calculate person time availability. The method will accept a vector of households or persons and return a vector of time window availability by operating on a vectorized representation of person time use throughout the day.
The joint tour scheduling model is similar to the existing other partially implemented scheduling models. It will be implemented under this task and depends on some of the key missing features noted earlier - calculation of time windows and logsums. These missing expressions and underlying software will be as faithfully implemented as possible within the available budget (in in addition to what is done in other tasks).
The joint tour destination and mode models are similar to the other partially implemented destination and mode models. The new procedures will be described in the online documentation.
Deliverable(s): (Due 12 weeks from NTP)
- Joint Tour Models
- Updated Example, including Expression and Config Files
- Updated Documentation and Tests
Comments
- ( Joe ) Will the joint tour mode models be implemented? ( Ben ) Yes, as noted above.
- ( Joe ) Is there anything unique about joint tour destination sampling that hasn't already been addressed in sampling work already completed? ( Ben ) No, not really. The joint tour destination models are the same as the individual ones with the exception of some additional information about the joint tour (number of participants, etc). This shows up in the mode choice logsums that feed into the destination choice models.
The goal of this task is to implement the stop frequency, purpose, scheduling (depart time), destination sampling, and destination, and to finish implementing stop mode choice. The stop frequency model is similar to the tour frequency model but also requires information about the traveler's skeleton schedule (such as number of tours scheduled) and tour attributes such as purpose and start time. The MTC travel model one stop purpose model simply samples from a probability distribution given tour purpose, direction, departure time, and person type. The MTC travel model one stop scheduling model also samples from a probability distribution given tour purpose, direction, departure time, and trip number.
The next step in this task is to complete the partially implemented trip mode choice sub-model by adding walk and bike alternatives, support for all purposes, using the correct OD pairs and time periods, using actual trips instead of tours, etc. This sub-model needs to be in place before stop destination choice because destination choice is predicated on availability of trip modes for the tour and uses logsums from trip mode choice as an explanatory variable. General support for logsums has been implemented, and so the focus here is on integration of logsums into the stop models.
The stop destination sampling model is similar to the tour destination sampling model but sequentially processes the stops from tour origin to destination when outbound and then destination to origin when inbound. When doing so, the model calculates out-of-direction network costs in two-parts: origin to alternative stop + alternative stop to next destination. We expect to vectorize these sequential models by segmenting the model by number of stops on the tour leg in order to apply the same calculation to record. This is essentially the same vectorization plan as was done for the CDAP re-write. The stop destination model is similar to the tour final destination models already implemented. The new procedures will be described in the online documentation.
Deliverable(s): (Due 24 weeks from NTP)
- Stop-level Models
- Updated Example, including Expression and Config Files
- Updated Documentation and Tests
Comments
- ( JEF ) There are problems with the current CT-RAMP implementation in stop frequency\purpose that result in simulation errors (dead-ends) under certain circumstances that we need to fix in these models. ( Ben ) We're planning to implement fixes as best we can once we have the basic implementation up and running.
The goal of this task is to continue to verify, and correct as needed, all implemented sub-models. Consultant will work through the sub-models in order and fix as many unresolved issues, such as implementing missing utility variables, logsums information, time windows, additional time periods, etc., as budget allows. Unresolved issues are noted in the Progress Report or the Issues. Consultant will also re-factor/organize the file/folder setup in order to improve the separation of concerns as budget permits and as the PMC desires. Consultant will update the source code, documentation, and tests as a result of any revisions to the framework.
Deliverable(s): (Due 24 weeks from NTP)
- Full Scale Example Model Run (All Zones, Skims, and Households) of All Implemented Sub-Models
- Informal Comparisons of Model Results to Expected Results
- Updated Source Code, Configuration Files, Documentation, and Tests
Comments
- ( Joe ) Under what scope / tasks are the completion of individual non-mandatory models? ( Ben ) Under this task, and the work needs to be prioritized along with other items on the clean-up to do list. The two sub-models that are currently not implemented at all are the individual non-mandatory tour frequency extension and tour location sample models. The first is a choice model based on an input probability table by person type, mandatory tour participation indicator, joint tour participation indicator, non-mandatory tour type, and the likelihood of zero, one, or two additional tours. The second is essentially the same as the now implemented work/school destination choice sample models, but for non-mandatory travel (i.e. shop, eatout, etc.).
- ( Clint ) Does this get us a fully functional replica of Travel Model One? ( Ben ) It gets us closer. Upon completion of this task, we will have the initial version of the code and model structure in place. There will still be some missing utility expression components that need to be completed. In some cases, this also means writing some code to produce the data items. See also the next phase of work, Phase 4.