-
Notifications
You must be signed in to change notification settings - Fork 21
Cross Border Model Implementation Plan
The plan is to replicate the existing model (code, uecs, inputs) and add a border wait time function.
The Cross Border model starts with a SANDAG specific pre-processor Python script that reads a yaml config file. This script has two purposes:
- Preprocess Mexican Colonias (tazs) and Ports of entry (POE) to create a POE Mexican population accessibility term at the MAZ level
- Generate a tour, households, and persons table for input to ActivitySim based on the input number of tours
- Reformat auxiliary input files (e.g. probability lookup tables, configs, etc.) according to ActivitySim data schema
ActivitySim operates on three types of zones - microzones, tazs, and taps. The Cross Border model has two additional types of zones - Mexican Colonias (tazs) and Ports of entry (POE). The Colonias are coded with population and distance and time to each POE. Each POE is associated with a microzone via the microzone POE_ID field in the input file.
The first step in this script calculates the POE Mexican population accessibility term at the MAZ level. The output file is an update microzone table with a new field: Colonia_pop_accessibilty. The yaml config file contains:
maz_data_file: mazs.csv
maz_field: MAZ_ID
poe_id_field: POE_ID
colonia_data_file: colonias.csv
colonia_field: COLONIA_ID
poe_field: POE_ID
population_field: POPULATION
distance_field: DISTANCE
distance_parameter: -0.19
The second part of the script creates a tour with purpose and lane type for each tour to be created. It also creates a household and person for each tour. This second step generates tours, households, and persons based on settings from the submodel yaml config file:
num_tours: 108000
purpose_shares:
work: 0.254
school: 0.041
cargo: 0.012
shop: 0.547
visit: 0088
other: 0.058
lane_shares_by_purpose:
work:
regular: 0.1
sentri: 0.2
ready: 0.7
ped: 0.5
school:
regular:
sentri:
ready:
ped: 0.5
The output of the script are input tables - mazs, households, persons, tours - for ActivitySim.
The cross border model ActivitySim model steps are:
models:
- initialize_landuse
- initialize_households
- initialize_tours
- initialize_los
- initialize_tvpb
- tour_od_choice
- tour_scheduling_probabilistic
- tour_mode_choice_simulate
- stop_frequency
- trip_purpose
- trip_scheduling
- trip_destination
- trip_mode_choice
- write_trip_matrices
- write_tables
The implementation plan for each submodel is described below.
This submodel reads the maz data file, which includes the POE_ID column and the Colonia_pop_accessibilty field.
This submodel reads the MAZ, TAZ, and TAP network los data and pre-computes the TAP to TAP total utilities for downstream models.
This submodel calculates a tour origin (POE maz) and destination for each tour. The choice set is (poe_maz to sandag_maz) pairs. It uses the existing tour destination choice to first sample N alternatives with a more limited set of information and then evaluates the full utility (i.e. with mode logsums) for the sample set. The model settings from the submodel yaml config file are:
sample_size: 30
size_terms: destination_choice_size_terms.csv
SAMPLE_SPEC: tour_origin_and_destination_sample.csv
SPEC: tour_origin_and_destination.csv
COEFFICIENTS: tour_origin_and_destination_coeffs.csv
LOGSUM_SETTINGS: tour_mode_choice.yaml
MODEL_SELECTOR: purpose #for size term selection
The result is an updated tours table with an origin maz and destination maz.
The cross border submodel will need to create a new version of the existing tour destination choice submodel since it must build an alternative set of origin-destination pairs - not just destinations.
This submodel sets the tour time-of-day using a probability lookup table. It is essentially the same code as the existing ActivitySim trip scheduling submodel. The result is tour start and end time fields.
This submodel sets the tour mode. It is similar to the existing ActivitySim tour mode choice submodel, but calls trip mode choice for the inbound and outbound legs conditional on a tour mode being choosen. This model is therefore more like a border crossing mode model that considers the various trip leg mode options as well. The origin zone POE maz border wait time (see below) is used in this model (and the tour origin and destination model via logsums). The result is a tour mode field. This model does not currently include transit modes directly but instead considers them via the trip mode choice model.
This submodel sets the tour stop frequency. It is essentially the same code as the existing ActivitySim tour stop frequency submodel. The result is a tour stop frequency field and the creation of trips table.
This submodel sets the trip purpose using a probability lookup table. It is essentially the same code as the existing ActivitySim trip scheduling submodel. The result is a trip purpose field.
This submodel sets the trip destination choice. It is essentially the same code as the existing ActivitySim trip destination choice submodel, complete with sampling and then evaluation of the full utility (using logsums) for the sample set. The result is a trip destination field.
This submodel sets the trip departure time using a probability lookup table. It is similar to the existing ActivitySim trip scheduling submodel but looks up a probability based on the duration rather than the depart period. The result is a trip departure time field.
This submodel sets the trip mode choice. It is essentially the same code as the existing ActivitySim trip mode choice submodel. The result is a trip mode field. It currently uses transit modes and therefore transit virtual path building.
This submodel writes taz and tap demand matrices to OMX format.
This submodel writes the data pipeline household, person, tour, and trip tables to CSV files.
The Cross Border model is run via an overall ABM model runner. This overall ABM model runner creates the necessary ActivitySim format settings files for the specific scenario being run. An example of the steps to prep and run the Cross Border model are:
prep_sandag_run.py -p ParametersByYear.csv -y 2020 -o settings_yr2020.yaml
cd asim_cross_border_model
python simulation.py -c yr_2020_configs -c configs -d data_yr2020 -o output_yr2020 -s settings_yr2020.yaml
A dynamic POE wait time model will be added and the model will maintain its data as MAZ attributes. The model calculates the POE wait time after tour origin and destination choice and maybe tour mode choice as a function of POE demand, time-of-day, etc. and requires re-running model components until a converged/averaged result is achieved**