-
Notifications
You must be signed in to change notification settings - Fork 99
Phase 4 Scope of Work
Phase IV will be performed during FY1819, ending in June 2019, and will focus on multi-processing, shadow pricing, integration of two zone system support, support for initial implementation in two regions, and verification of model results and remaining fixes.
Task 1: Project Management
Task 2: Multi-Processing
Task 3: Shadow Pricing
Task 4: Two Zone Systems
Task 5: Implementation Support for Two Regions
Task 6: Verification and Remaining Fixes
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 52 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
- xxxx
The goal of this task is to revise ActivitySim to make use of multiple machine processors in order to reduce model run times. Currently, all ActivitySim procedures run in a single process. Within each sub-model, operations are chunked into reasonably sized chunks (for instance 5000 tours for choosing tour mode) in order to avoid creating data structures that are too big for the available memory. ActivitySim iterates through these chunks in a single process and accumulates the results.
In addition to iterating through the chunks, ActivitySim will concurrently operate on the chunks via multi-processing. Python multiprocessing is likely to be used, as opposed to threading within a single process due to the Global Interpreter Lock (GIL). To multi-process an ActivitySim model run requires the following basic steps:
- Randomly assign households into process groups
- Create shared data structures across processes for read only data - skims, zone data, etc
- Start concurrent model runs for each of the household process groups
- Merge the results into one data pipeline at two spots in the model run - at the end of work and school location choice and at the end of the overall model
- Restart process after work and school location choice since shadow pricing requires data across households
We will begin by prototyping multi-processing for one sub-model, benchmarking the sub-model runtimes against the existing run, and discussing our findings with the AMPO partners. We will then revise the full example to use the new framework, and the updated software will be described in the online documentation.
Deliverable(s): (Due 12 weeks from NTP)
- Prototype Multi-Process Sub-Model
- Integration of Multi-Processing into the entire ActivitySim example
- Updated Example
- Updated Documentation and Tests
Comments
- xxxx
The goal of this task is to develop a shadow pricing module for the work and school 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 provide the user with the optional ability to flexibly define a set of destination choice size terms by zone, segmented by purpose (eg. work by industry sector, school by school type), worker or student attributes (eg. income, age), and/or other geographies (school district boundaries). It will not include walk transit sub-zone markets since these are currently not in ActivitySim. The procedure will be implemented after multi-processing is added since shadow pricing requires summing data across processes (assuming processes process batches of households for example). Due to the iterative nature of the shadow pricing calculation, it will be implemented efficiently as possible. The module will include the ability to save results for input to subsequent model runs. The module will also include the ability to set iteration and convergence parameters, such as to iteratively update shadow prices up to a fixed number of times, or until a minimum threshold of destinations zones demonstrate a minimum performance criteria (eg. 95% of zones with more than 100 jobs are within +/- 5% relative to usual workplace destination choices). We will revise the existing ActivitySim work and school destination choice sub-models to use the new shadow pricing code. The new procedures will be described in the online documentation.
Deliverable(s): (Due 20 weeks from NTP)
- Shadow Pricing Calculation Procedure and Interface
- Updated Work and School Destination Choice Sub-Models to Support Shadow Pricing
- 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 do prices by purpose and zone for now, as noted above.
- ( Joe ) What does transit subzones not being implemented mean for overall model system implementation? ( Ben ) It means we won't be segmenting zone demand into three submarkets - percent with short walk to transit, long walk to transit, and no walk to transit. This means the initial version of the example will probably not forecast transit travel as well at the zone level. We've decided to not implement this since it makes the code a mess and the multiple zone system approach used by MTC TM2, SANDAG, PSRC, and others is a better approach.
- ( Joe ) Due to the iterative nature of shadow price calculation, I think it would be good to ensure that process is implemented efficiently. ( Ben ) Yes, as noted above.
The goal of this task is to integrate support for two zone system network level-of-service (see partner zone systems) into the ActivitySim framework. In two zone system models, i.e. the DaySim-based PSRC and SFCTA models, trips are modeled from maz/parcel to maz/parcel, but network level-of-service varies by mode:
- auto - taz-to-taz skims
- walk/bike/near auto - maz-to-maz for nearby zone pairs using path costs from an allstreets network
- transit - taz-to-taz skims except for access/egress time, which comes from the maz/parcel file, which includes access distance by transit line-haul for each maz In three zone system models, i.e. SANDAG and MTC TM2, transit stop-to-stop skims + a set of nearby stops for each maz are used to do transit virtual path building during a model run to build maz to maz impedance through the best transit access and egress stops.
Under a separate contract, support for three zone system was prototyped using the SANDAG ABM model inputs. This task will involve integrating the prototype three zone system implementation into a new two zone system ActivitySim example model for SANDAG (see Task 5). See Task 5 for how SANDAG's data will be slightly revised for the two zone system approach. Full support for three zone systems (which adds transit virtual path building) will be done in a later phase of work. The complete new example model will be tested and documented.
Deliverable(s): (Due 28 weeks from NTP)
- Integration of Support for Two Zone System Models into ActivitySim
- Additional Example
- Updated Documentation and Tests
Comments
- xxxx
The goal of this task is to initially setup two additional regions (ARC and SANDAG) as test examples in order to begin the transition from the existing models to ActivitySim-based models. Consultant will assist the agency partners in preparing the input data and revising sub-model expression files as required. The level of implementation at this point assumes the new regional models will use the existing TM1 implemented sub-models, but key structural components such as modes and times-of-day will be localized. Consultant will also re-factor the code in order to improve the flexibility for implementation in new regions 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.
For SANDAG, Consultant will assist SANDAG with developing procedures to code best transit stop by maz for each transit (line haul mode | skim set) in order to use the two zone system approach implemented in Task 4 . The planned approach is to add to the input maz input table, an access/egress stop by transit (line-haul mode | skim set) and use that for calculating transit path level-of-service. DaySim's maz input file (as used by PSRC and SFCTA) has attributes for distance to nearest transit stop by line-haul mode, but SANDAG's will have a stop ID, and the distances will be looked up from additional input files + used to query the stop-to-stop transit skims. See the SANDAG Multiple Zone Systems Design for more info.
Deliverable(s): (Due 28 weeks from NTP)
- Full Scale Example Model Run of All Implemented Sub-Models for the Two Additional Regions
- Informal Comparisons of Model Results to Expected Results
- Updated Source Code, Configuration Files, Documentation, and Tests
Comments
- xxxx
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 by comparing high level results to existing MTC TM1 calibration/validation summaries and fixing any 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 36 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
- xxxx
| Region | TAZs (1) | TAZs + MAZs/parcels (2) | TAZs + MAZs/parcels + transit stops (3) | Notes |
|---|---|---|---|---|
| PSRC | X | Transit IVT, etc from TAZ-to-TAZ skims. Transit access/egress times looked up by sub-mode in the buffered MAZ/parcel file and represent time to nearest stop. | ||
| SFCTA | X | Transit IVT, etc from TAZ-to-TAZ skims. Transit access/egress times looked up by sub-mode in the buffered MAZ/parcel file and represent time to nearest stop. | ||
| MTC TM1 | X | |||
| MTC TM2 | X | Does transit virtual path building during a model run to build MAZ to MAZ impedance through the best transit access and egress stops | ||
| SANDAG | X | Does transit virtual path building during a model run to build MAZ to MAZ impedance through the best transit access and egress stops | ||
| SEMCOG | ? | ? | ? | Trip-based model uses TAZs |
| ARC | X |