-
Notifications
You must be signed in to change notification settings - Fork 0
University Model
The University model is a tour-based model representing the travel decisions of university students, faculty, and staff. It also models parking lot choice based on the number and costs of parking spaces allocated to students, staff, and visitors.
The University model, if the RunUniversityModel setting is enabled, is run (in Java) from the JEMnR R scripts via a batch file, which specifies the model paths and launches the Java executable. Visum skims in OMX format are first converted to ZMX format, which the University model can read without modifications, and saved to the unimodel/emmemat
folder. The model outputs a trips table to unimodel/outputs
in CSV format, which JEMnR then processes into a matrix and saves as an RData file.
Prior to running the University model, JEMnR splits the model population into two sets: a university population, whose travel decisions are made by the university model, and a general population whose travel decisions are modeled by JEMnR.
The University model uses its own TAZ data file and several Utility Expression Calculator (UEC) files, which specify how matrix and zonal inputs are used in the model.
Inputs are documented in memo 4.2 starting on page 73 and on the Model Inputs page.
The University model requires both disaggregate households and persons files created by an outside population synthesis model (PopSynIII) plus PUMS files used to generate the group quarters and university faculty/staff population.
The PUMS person and household files are for Public Use Microdata Area (PUMA) 600, Linn and Benton counties in Oregon. PUMS data files, variables, and codes can be found at the Census Bureau PUMS website.
The file path to the person and household files are stored in the GroupQuartersPopulation.PUMS.PersonFile and GroupQuartersPopulation.PUMS.HouseholdFile University model properties, which should be updated if these file names change.
The household and person Public Use Microdata Sample (PUMS) files are read in by the university model program, and are used to create the group quarters (GQ) synthetic population. The target number of GQ records by type for each TAZ are read from the TAZ Data file. The synthetic household and person files containing the non-GQ population are generated by the Population Synthesizer, which should be run separately before running the university model. The synthetic population files contains the representative non-GQ population for the entire modeled region. The University of Oregon students living in family or non-family residential households can be identified using the UofOTag in the person file. The university faculty and staff members are sampled from the synthetic population by the worker location model. While the synthetic population contains all households and persons, the university model is applied only to persons tagged as student, staff, or faculty members of the University of Oregon. The full synthetic population is required to generate the size terms for the worker location model. The TAZ data file contains household by type, employment by type, and other fields that are necessary to run the university model. The time and cost skims are used for calculation of accessibilities, mode, and destination choice models.
Skim matrices provided to the University model from Visum and JEMnR are listed on the Model Outputs page. However, not all skims are actually used by the model. This is dictated by which skims are defined and used in calculations in the UEC files.
The following table summarizes the level of service (LOS) skims used by the CALM university model. The skims should be in ZMX format. In the current CALM university model, these skims are generated by the Visum transportation software and converted to ZMX format. The skim names and descriptions are summarized in the table below. Note that skim names should be kept the same. The LOS skims depend on various network attributes and settings. The auto skims depend on roadway attributes such as speed limits, number of lanes, capacities, and volume-delay functions. The transit skims depends on transit routes, headways, dwell times, and transit runtimes.
Skim Name | Description |
---|---|
mf9 | In-vehicle time for Bus-Walk mode |
mf10 | Walk time for Bus-Walk mode |
mf11 | First wait time for Bus-Walk mode |
mf12 | Second (transfer) wait time for Bus-Walk mode |
mf14 | Number of transfers for Bus-Walk mode |
mf19 | Off-peak auto travel time |
mf20 | Peak auto travel time |
mf21 | Auto distance |
For example, while looking into University model errors, we found that bike and walk distance skims were not used in calculating zone-to-zone bike and walk travel time in the University Model.
Instead, the UEC entries above show skimmed auto distance is multiplied by the speed in minutes per mile to calculate travel time in minutes. (20 minutes per mile for a 3mph walk speed, 6 minutes per mile for a 10 mph bike speed)
The University model mode choice was calibrated as part of the migration to Visum.
This line was added to the University tab in /unimodel/ctlfiles/UniversityTourModeChoice.xls
:
Field | Value | Explanation |
---|---|---|
No | 280 | Next integer in sequence, should be unique value |
Token | (blank) | Not defining a token |
Description | Visum calibration adjustment | |
Filter | (blank) | applies to all markets/modes |
Formula for variable | 1.0 | no variables used |
DRIVEALONEFREE | 0.1663 | DA calibration adjustment |
DRIVEALONEPAY | 0.1663 | same as above |
SHARED2GP | 0.1557 | HOV 2 calibration adjustment |
SHARED2PAY | 0.1557 | same as above |
SHARED3GP | 0.0599 | HOV 3 calibration adjustment |
SHARED3PAY | 0.0599 | same as above |
WALK | 0.0928 | Walk calibration adjustment |
BIKE | -0.1810 | Bike calibration adjustment |
WALK_LOC | -1.5564 | Walk to Local Bus calibration adjustment |
WALK_PRM | 0.00 | Not used |
PNR | 0.00 | Not used |
KNR | 0.00 | Not used |
The calibrated values are the result of an iterative process. Initially, the values on this line are the natural log of the target mode share for University model trips (from the Emme model) divided by the current mode share. After updating the UEC, the model is run again and new adjustments are calculated using current mode shares from the latest run. The number used in the UEC is the sum of the adjustments from each iteration, so that the 2nd iteration uses the sum of adjustments from iterations 1 and 2 and so on.
If UniversityParkingLotChoiceModel.RunModel is set to true in tpau_tbm.properties, then the major university parking lot choice model will be run.
This model requires an input file allocating parking spaces to TAZs. The format for Parking_Capacity.csv is described on the Model Inputs page.
The model will choose a parking lot TAZ for each worker and student who travel to any of the university zones for work or university tours by auto tour mode. It will insert the parking lot as the first and last on-campus stop on their tour, which will be identified by a “Parking” purpose in the trip output file for the lot location. The model will also output a parking demand file HouseholdManager.output.parking.file and an unmet demand file containing demand for parking that cannot be accommodated by available parking supply UniversityParkingLotChoiceModel.UnmetParkingDemand.file.
The original model and updates are documented in 3 technical memos:
-
Tour-Based University Student Travel Model Development and Use (4.2) (Student market only) contains:
- Model Description
- Model Estimation procedures
- Inputs and Survey Processing
- A User's Guide describing the input and output files
-
Faculty/Staff Modeling Additions to University Model (4.3) contains:
- Faculty/Staff survey processing
- Descriptions of additional models for faculty/staff travel
- Changes to the input and output files
-
University Parking Lot Choice Model Development and OSU Model Calibration (4.4) contains:
- Input data, model estimation, and calibration of parking lot choice model
- Instructions for running the model and creating/updating parking scenarios
The University model could be updated to accept OMX matrix inputs directly. Currently, ZMX files are prepared solely for the University model.