-
Notifications
You must be signed in to change notification settings - Fork 100
Phase 3 Amendment Scope of Work
This draft scope of work is for the second half of 2017. See the Phase 3 Scope of Work for work planned in the first half of 2017.
Task 1: Project Management
Task 2: Stop-Level Models
Task 3: Joint Tour models
Task 4: Shadow Pricing
Task 5: 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 XXXX 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
- ( Elizabeth ) User Definition / Restructure existing processes: Just reiterating my vote that this be a explicit task, possibly named "Design for User Effectiveness" or similar which would have subtasks to define user types and their needs and then restructure existing code to more effectively serve each of these users.
- ( Ben ) Based on my understanding of the PMC's priorities, translating MTC TM1 components and sub-models to the new framework is the focus right now. After we initially complete this exercise, then we'll begin to more explicitly focus on the user experience.
- ( Elizabeth ) Agile Project Management Practices: As velocity on this project increases and potentially more developers become involved, I suggest that we start using true agile project management practices with users, user-stories, etc.
- ( Ben ) See previous comment.
- ( Elizabeth ) Management Plan and User Community Maintenance: At TRB we had discussed specific deliverables and budget associated with developing a management plan for the future and managing any pull requests/coordination/publicity with other users.
- ( Ben ) See previous comment.
- ( Elizabeth ) Add Additional Contributors: I agree that doubling Jeff's time makes sense as it wasn't too significant to begin with. However, one way to test usability/maintainability/extensibility is to have multiple contributors. @lmz suggested she would be interested in peeling off a task or two and I'm guessing other agency staff and potentially other consulting resources may be good to get involved.
- ( Ben ) @stefancoe is building the DaySim buffering process into Asim. @lmz is probably too busy these days to get into the code, but we're happy to get her involved if she wants.
The goal of this task is to implement the stop frequency, purpose, scheduling, destination sampling, and destination sub-models 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 will be completed under the earlier Logsums task, 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 new procedures will be described in the online documentation.
Deliverable(s): (Due XXXX 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 plan to implement fixes as best we can once we have the basic implementation up and running.
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 XXXX weeks from NTP)
- Joint Tour Models
- Updated Example, including Expression and Config Files
- Updated Documentation and Tests
Comments
- xxxx
The goal of this task is to develop a shadow pricing module for the mandatory destination choice models. Shadow pricing is an iterative mechanism that works to match estimated workers and students in each zone to input employment and enrollment totals. The calculated shadow prices are part of the destination choice model utilities and also output to a file so they can seed subsequent model runs in order to reduce run time. Shadow pricing in MTC travel model one is done by destination choice size variable segment (work low income, work medium income, work high income, work very high income, university, school grade, school high), zone, and walk transit sub-zone market (no walk %, short walk %, long walk %).
The ActivitySim Shadow Pricing module will operate on the user defined set of destination choice size terms by zone and purpose only. It will not include walk transit sub-zone markets since these are currently not in ActivitySim. It will also not include income segmentation for now. The procedure will be implemented before multi-threading/processing is added to ActivitySim since shadow pricing requires summing data across threads/processes (assuming threads/processes process batches of households for example). The module will include the ability to save results for input to subsequent model runs. We will revise the existing ActivitySim mandatory destination choice sub-models to use the new shadow pricing code. The new procedures will be described in the online documentation.
Deliverable(s): (Due XXXX weeks from NTP)
- Shadow Pricing Calculation Procedure and Interface
- Updated Mandatory Destination Choice Sub-Models to Use Shadow Pricing Module
- Updated Documentation and Tests
Comments
- ( JEF ) It always sort of bugged me that the shadow prices in CT-RAMP 1 were segmented by income and walk market. I am not sure why the code was designed this way but it seems like overkill, and could result in some very different prices for each segment, which isn't intuitively obvious. So I would suggest that you start simply, by calculating prices across zones. If there are convergence problems one can always add the segmentation later.
- ( Ben ) We'll just do prices by purpose and zone for now, as noted above.
The goal of this task is to continue to verify, and correct as needed, sub-models implemented in phase 1. 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. 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 XXXX weeks from NTP)
- Full Scale Example Model Run (All Zones, Skims, and Households) of the Initially Implemented Sub-Models
- Informal Comparisons of Model Results to Expected Results
- Updated Source Code, Configuration Files, Documentation, and Tests
Comments
- ( 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.