External Model

The SWIM external model, based on the Oregon statewide integrated model, runs select link analysis in the SWIM assignment at each ABM external station in order to build traversal matrices by mode and time-of-day for the SOABM external flows. See the SWIM Select Link module for more information.

The SWIM External Model was originally developed for JEMnR (Joint Estimated Model in R, used for the MPO areas, which ODOT operates). The concept is that a given urban model area is “cut” out of the larger StateWide Integrated Model (SWIM) area. The trends from SWIM provide the best source of information for how passenger cars and long-distance freight travel to, from, and through the “cut” area. When a “cut” boundary is created, the "select link" (SL) process is run in SWIM to create a subset of the full SWIM car and truck tables. The subset includes all the trip ends that travel in, to, from, or through the cut area. This provides the basis for the trends for the external model for the given local urban model, the “cut” area.

It is very important to understand that SWIM is only providing trends, or travel distributions. It is not providing raw results or volumes that would be fed directly into the local model. There are several reasons why raw SWIM output is not used:

SWIM is a model for statewide policy. The small and medium sized external stations to an urban area are not calibrated to high precision in SWIM. These external points may have smaller relative volumes compare to more major external stations, but the small external volume, might be very influential to the network and zones that are in close proximity to the given external station. For this reason and others, external volume control totals are an input by the user outside of SWIM. The control totals provide by the user dictate the total volume at an external station by time of day, while the SWIM results provide the zone to zone trip patterns and distribution (what % of the trips go to zone A vs B).
SWIM is a policy tool that requires that land use be modeled and integrated with transportation and the economy. This means that SWIM is modeling more than just the transportation element that our urban trip based models capture. SWIM is also modeling the land use that would accompany the given transportation and economic scenarios. Because of this SWIM’s land use is not “set” or dictated like in the ABM (or JEMnR or OSUM). The ABM requires that the dictated land use for a given scenario be adhered to. This inconsistency explains the second reason why SWIM’s raw volumes / results cannot be fed directly into the urban models – because the land use doesn’t match. Before SWIM’s trends can be used, the trip tables are first re-weighted by SWIM-to-local land use factors, so that the number of trips to a given zone represents the local measured or asserted land use, as opposed to the modeled land use in SWIM.
SWIM is a stochastic model, meaning that each run of SWIM will provide slightly different results. To get a good “average” set of external trends, multiple sets of SWIM output need to be averaged together.

All of these reasons explain why SWIM is used for trend information (that cannot be obtained from other sources), and while control totals are still needed in the SWIM external model process. The following explains the volume control file and the other SWIM external model input files that are needed to use and operate the SWIM external model and the output files that can be used to diagnose the results of the external model and that are used as the external demand in the ABM.

External Model Inputs

select_link_1_2010_outputs.zip - SL outputs
swimControls.RData - R data object of various SWIM external model settings
SelectLinks.csv - SWIM select link file with count data appended
SWIM_JEMnR_TAZ_CW.csv - SWIM to local zone crosswalk. The filename is specified as a Model Parameter in the properties file
TOD_Periods.csv - CVM Time-of-day periods
config/swim_ext/SWIM_External_Properties.csv - SWIM external model properties file for setting Model Parameters
maz_data_export.csv - MAZ data export by VISUM for CT-RAMP (not detailed below, for more information see Model Outputs)

External Model Outputs

select_link_1_2010_outputs.RData
externalOD_ZnZnTdMd.RData - Trip tables by time-of-day and purpose for debugging
externalOD.omx - External trip table for assignment

Each file is now described in more detail. The following five files aren't altered by the user. They are provided from the SWIM model or are internal files that represent adjusted versions of those provided SWIM files. The user just needs to provide them to the model as inputs and/or be aware of them, but doesn't need to edit or change them.

select_link_scenario_year_outputs.zip

An input file found in \inputs. This zip file is the resulting set of subarea trip tables obtained from the “cut” area in SWIM. There could and should be multiple SWIM subsets, so that a good average can be obtained. The person doing the SWIM cut will name this zip file. The format of the name goes; “select_link” _ SWIM scenario name _ SWIM year pulled _ “outputs.zip”. This is an example of a full file name – “select_link_Reference_2010_outputs.zip”, where “Reference” is the name of the SWIM scenario where the subset trip table was pulled and 2010 is scenario year (SWIM produces trip table data every 3 years, so a 2017 run might pull a 2016 SWIM trip table and a 2019 from the same scenario).

When the code is run three files which are variations of “_outputs” file are created:

select_link_scenario_year_outputs.RData

An output file found in \inputs. This R dataset is an exact duplication of the csv tables kept in the zip file (described above), except in R format. It can take a measurable amount of time to unzip the csv tables, so the first time the zip file is referenced the contained csv files are unzipped and stored in an R dataset, then each future run the code recognizes that the R dataset exists and skips the unzipping and reading process and just loads the R dataset. The code looks for new zipped datasets with the “_outputs.zip” naming convention. So if a new zipped data set is added to the “data” folder, the code will automatically create an R dataset copy and use the newly added datasets, along with any existing dataset to create the average trends.

externalOD_ZnZnTdMd.Rdata

An output file found in \outputs\other. This 4-D OD (Origin – Destination) array is a mid-step product of the SWIM external model (not an input). This is a weighted, averaged, and proportionally fit OD array where all of SWIM’s trends have been averaged across scenarios (as provided), weighted to the local land use, distributed to the local zone structure (note that SWIM has much larger zone aggregations than the local model will have, so a disaggregation process is needed), and then iteratively adjusted to match external station volume controls. The Zone-to-Zone (ZnZn) OD matrices are provided by Time-of-day (Td) and Mode (Md). For the ABM there are 7 time-of-day periods; EV1, EA, AM, MD, PM, EV2 and one daily summation (EV1 and EV2 are added to together to form EV). The Mode dimension captures passenger vehicle travel and truck travel. To simplify the external model produces nine “mode” categories, as purpose is combined with mode; eight auto purposes (hbcoll, hbo, hbr, hbs, hbsch, hbw, nhbnw, nhb), and just one truck purpose – truck. This results in 7x9 (63) different “slices” of the OD matrix. Currently, the ABM collapses the auto purposes, so that just mode information exists (auto and truck), and then utilizes the auto and truck patterns at each of the external stations for each period. So the 63 “slices” exist for the analyst to refer to, but the ABM only uses 12 (6x2) OD slices.

externalOD.omx

An output file found in \outputs\trips. This is basically a copy of externalOD_ZnZnTdMd.Rdata, but in OMX format, which is read by Java, as opposed to the Rdata format. This is the data (the demand matrices) that is ultimately used in ABM.

swimControls.Rdata

An input file found in \inputs. This file needs to match the SWIM version number that the SWIM dataset that was provided. Meaning that if SWIM 2.5 was used to generate the select_link_scenario_year_outputs.zip file, then the swimControls.Rdata file needs to match SWIM 2.5 (ask the person who provided the select_link_scenario_year_outputs.zip file if the two are consistent). This file provides OEA (population) and OED (employment) land use controls for the state and surrounding "Halo" region for the base and future years. These land use controls are necessary to adjust SWIM’s modeled land use to state consistent projections for the entire model area, not just the local model area. Without this file, the user would have to generate population and employment controls for the entire state (as opposed to just the TAZ file for the local model), which would be an over burdensome task. Hence the existence of this one file, for all Oregon urban model areas to use.

Inputs that the User Creates or Alters

The following inputs are ones that the user must create and/or manipulate to use or alter the external model (along with several output files that are copies of these input files that are written out from the code with additional internal calculation fields for assessing the model run):

selectLinks.csv –

This is the main file that a user will access to edit the external model.

An input file found in \inputs. This is the file that is used to provide external station controls for all external stations in the model. This file is also the crosswalk between the local model and SWIM, so for documentation, and a more complete understanding, the SWIM links that are used to represent each of the external stations are also included in this file. Controls can be set for both the “IN” and “OUT” directions of each external station, creating 2 rows for each external station. So the number of total rows in this file is 2 times the number of external stations. The following are the fields (columns) contained in this input and how each is used or defined.

FROMNODE and TONODE – these two fields are for documentation purposes only. They define the FROM and TO node of the SWIM link that was chosen to represent the local external station. An additional note for context – when the subarea is defined in SWIM it must be a totally closed loop, meaning that a fictional closed loop must be able to be drawn through all the links identified in this file, without crossing over an unidentified link. The impact of this, is that when this link crosswalk is first being developed, it may requiring either editing (addition / subtraction) of SWIM network, or adding or subtracting local external stations. Either way, by the end of the crosswalk set-up both the SWIM network and the external stations in the local model must match 1-to-1 at the local model boundary (internally, the network within the local model area boundary, there can and will be differences due to scale and detail).
DIRECTION – This field defines if the row of information (and the identified SWIM link) is inbound or outbound, where “IN” would be the direction entering the local model and “OUT” would be exiting the local model. All controls in the SWIM external model are specified by direction.
STATIONNUMBER – This is the external station number. Each external station should be repeated twice, once for each direction. Note that this numbering system needs to match the external station numbering (zones) as defined in the local (ABM) model network.
AutoAWDT and TruckAWDT – These fields represents the daily auto and truck control (total) value for each direction of each external station. If only the total volume is known at the external, then the total volume should be put in the AutoAWDT field and either a zero or an NA should be put in the following field – TruckAWDT. An NA value signals to the code to use the SWIM truck percentage, zero would mean all the volume is assumed to be auto. The reason to specify the auto truck split is because trucks have different origins and destinations than autos. SWIM has truck and auto patterns so these differing patterns are used to help better distribute the control volumes at each external station. By putting a zero in the TruckAWDT field the assumption is that all the traffic from the given external station direction has the distribution of passenger car travelers, which may or may not be correct. If truck volume is not known and the user wants truck volume, but does not want to use SWIM’s split (by setting NA); other information and/or judgment can be used to split the total volume into auto and truck. The AutoAWDT and TruckAWDT fields need to sum to the daily total volume for each given direction for each given external station. As is discussed in the “selectLinks_Report.csv” description, the user can run the model once, and have the SWIM auto and truck splits reported back via the “Report” file. The SWIM truck splits can then be used as additional information in manually setting the best split.
AWDT_YEAR – this is the year of the AutoAWDT and TruckAWDT fields. For future year runs, the auto and truck daily volumes can either be projected up externally to the model and put in this file, or the user can leave the base year totals and let the growth rate field grow the volumes to whatever future year is being modeled. Note that due to this external model set up, it is critical that the user specify the year being modeled in the year setting THIS NEEDS TO BE UPDATED AFTER THE EXTERNAL MODEL CODE IS CLEANED UP AND THIS IS PROPERLY MOVED TO A PROPERTIES FILE INPUT.
GrowthRate – This field is used to set the by direction annual growth rate for each external station (although it is highly recommended that the user keep the growth rate the same for both directions of any given external station). The GrowthRate field is applied whenever the AWDT_YEAR field and the model specified year differ. So if for say the AWDT_YEAR field was set at 2045 for future years, but an interim year of 2035 was being run, then the external model would use the growth rate to lower the 2045 control total to 2035. This setup helps ensure that all inputs are properly documented. The user cannot just specify total volume controls. The user must also specify the year those controls represent and the growth rate that was established for each external station. For calculating the (annual) growth rate the user must use the equation being used in the model, which is (1 + (growth rate * (Model year – AWDT_YEAR field))). This equation calculates the multiplier for the volume controls at each direction for each external station, which is then applied to both the Auto and Truck controls to get the controls for the given year being modeled. So the input in this field needs to match the form of the equation, so for 2% annual growth, the input in this field should be 0.02. Again, this documentation structure and logic help remove user error where volume controls from the wrong year are applied. For further information on developing the Growth Rates, see the Methodology discussion below.
Period fields – As is discussed below, the “TOD_Periods.csv” file defines all time-of-day periods in the model. Each period defined in the TOD file needs to have a period factor field defined in the selectLinks.csv. For the ABM, the 24 hour day is divided into 5 periods, however EV (evening) has both an covers both midnight - 3am (EV1) and 6:30pm - midnight (EV2). Therefore 6 period factor fields need to exist in the selectLinks.csv. As an example, the first period in the ABM is AV1”, so the “selectLinks.csv”, as a field “EV11_DirPdFactor”. Note that the “_DirPdFactor” can be revised or removed, the code only looks for the names from the “Period” field in the TOD file. In this case, the first Period in the TOD file is “EV1”, so the code looks for the field that starts with this character string. If it does not exist the code will fail. Note that the period name from the TOD file needs to start the field name in the selectLinks.csv. Any additional naming can follow, but the period name must lead the field name in the selectLinks.csv. In the ABM, since all 24 hours of the day are represented in the 5 (or 6 depending on how you are counting) periods, all the period factors should sum to 1.00. So each period factor should represent the percentage of daily traffic that occurs in the given period (where 5% would be coded as 0.05). These factors should come from the counts that occurred at the external stations and they can and should vary by direction. Note that the factors are applied to each direction independently, so each direction’s (row’s) period factors should sum to 1.00 across all periods.
Optional fields – The above fields are the required fields for the model to run. However, the code finds all of these by name, so there is no harm in moving their relative position or in adding additional fields. Adding additional documentation fields is highly encouraged and recommended, as long as the new documentation fields for a specific development / implementation are explained in documentation or a readme (meta-data). Here are some of the recommended documentation fields:
- HWY_MP – This documents the highway and MP of the external station, which can be used to pull historic count information, Transportation Volume Tables (TVT) information, Future Volume Tables (FVT), possibly Automated Traffic Recorder (ATR) information and lots of other information that can be used to create the control totals and growth rates
- TVT_Volumes – for every external station, the HPMS dataset should be reviewed to compare what average volumes are being report on the given segment (where available)
- TVT_Year – Provide the year the TVT volumes came from
- FVT – If the external station is on the state highway system then it will have a future year volume projected by historic information. This should be used for analysis and in future year development
- Growth rate fields – Growth rates can be obtained and calculated from historic sources, the statewide model and others. All work done should be documented here. With the final growth rate that is determined and set being captured in the “GrowthRate” field (described above), which is the field actually used by the model.

selectLinks_Report.csv

An output diagnostic file that is not currently being generated for the ABM (the code needs an update). This file is created by the code. This report file provides the user with some of the internal calculation results to help assess if the model is running correctly. This report file has all the fields used by the code (so not all the documentation fields provided in the input file) and as ordered by the code (so ordering might change from the input file). In addition to the used input fields, some additional internally calculated fields are also appended. Here is a description of all the fields.

station – this is the “STATIONNUMBER” field which comes first in the dataset within the model and is renamed to “station” to create consistency with both OSUM and JEMnR (ODOT's trip based modes) internal naming in the code.
DIRECTION – same field from the input
AutoAWDT and TruckAWDT – these will differ from the input if TruckAWDT was coded as NA. If NA, then the total volume in Auto will have been split to auto and truck using the auto / truck percentages found in SWIM
AWDT_YEAR – the year representing the volumes in AutoAWDT and TruckAWDT.
Period Factor fields – all the period factor fields from the input, however these fields will be named with only the part of the field name that matches the “Period” name in the TOD file. Any extra field description in the name from the selectLinks.csv input file will be dropped in this report file.
GrowthRate – the GrowthRate field from the input
SWIMauto, SWIMtruck, and SWIMtrkPct – the SWIM auto and truck daily volumes by external station by direction prior to being adjusted to the control totals. From SWIMauto and SWIMtruck, the SWIM truck percentage (SWIMtrkPct) is calculated. This is what is used to split the total volume if NA is coded in the “TruckAWDT” field.
daily_auto and daily_truck – these fields are the final daily control totals for the model, by external station and direction. The daily external station volumes found in the assignment results (the daily assignment totals found at the external stations in Visum) should match the summation of these two columns, by external station by direction. These fields are derived by factoring up the AutoAWDT and TruckAWDT fields using the GrowthRate field and the following equation (1 + (growth rate * (Model year – AWDT_YEAR field))). For every period being run, the period factors in the Results table are multiplied by these two fields to get the period specific control totals.

SWIM_Local_TAZ_CW.csv

An input file found in \inputs. This is the zone crosswalk between SWIM zones and the local model zones. There are four columns in this crosswalk; SWIMZONE, LOCALZONE, SWIMPCT, and LOCALPCT. The purpose of this file is to disaggregate the trip pattern information at the larger SWIM zones (SWIM’s “alpha” zones, used for trip assignment) down to the smaller local (ABM) zones, in this case the TAZs for the given model. If the activity (population and employment) in a SWIM zone overlaps with a local zone then that SWIMZONE-LOCALZONE pair needs to be captured in this file (if less than 1% of the SWIM zone's activity falls within the local zone, the SWIMZONE-LOCALZONE pair can be ignored). There should be no duplicate SWIMZONE-LOCALZONE pairs. All SWIM zones who’s zone connectors connect to the network within the fictional closed loop that is created by the subarea cut for the local model area needs to be represented in this crosswalk by at these one link to a local zone. All local zones represented in the model network (internal zones not the external stations) need to have at least one link to a SWIM zone. There are two fields that provide the quantity of representation that each local zone has with a given SWIM zone. The first field is “SWIMPCT”.

SWIMPCT - This field was used in development and is being retained as a legacy, but will likely never be used. It represents the percentage of a given SWIM zone’s traffic that would be allocated to a local zone. It is a fairly brute force method and requires a special toggle in the parameters to the external model to be set for it to be used, so it will likely never be used.
LOCALPCT - Is the primary input of interest is. This field represents the percentage of the local land use that falls in a given SWIM zone. This field works by multiplying this percentage to the Population and/or Employment fields from the ABM TAZ information (summed from MAZ level information - maz_data_export.csv). The LOCALPCT field needs to sum to 100 for each local zone. The code is set up to have the LOCALPCT field represent just population, just employment, or an “activity” combination of both employment and population, where the combined activity would be (2 * employment) + population, a fairly standard measure. This final “activity” representation of the local land use is the default and the setting that will most likely be used by all implementations, unless someone has documented a specific adjustment for a given implementation. Therefore the LOCALPCT field should be developed using this activity measure, so for each SWIM and Local (TAZ) zone pair the percentage of the local zones activity that fell within that zone pair (SWIM zone) would be captured for the given zone pair combination. There are automated processes set up to develop this crosswalk and once it is developed it likely will not need to be altered. Please consult SWIM staff for assistance in developing this crosswalk.

SWIM_TAZ_CW_Report.csv

An output diagnostic file that is not currently being generated for the ABM (the code needs an update). This report file is a copy of the “SWIM_Local_TAZ_CW.csv”, with five additional appended fields (to the original and unaltered 4 fields, making 9 total fields). The five appended fields are defined here:

LOCALPOP – is the TAZ Population (POP) multiplied by the LOCALPCT field.
LOCALEMP – is the TAZ Total Employment (EMP_TOTAL) multiplied by the LOCALPCT field
County – This field represents the County that the SWIM TAZ (or alpha zone) is tagged with. This field can serve as a quick quality check to make sure that all of the local zones are associated with expected counties.
AtrFac and ProFac – These abbreviations stands for “Attraction Factor” and “Production Factor”. After all the trips have been weighted at the SWIM level, the trip ends need to be disaggregated to the Local TAZ level. This “Crosswalk” file is used to disaggregate all SWIM zone trip ends to Local TAZ Production and Attraction trip ends. The AtrFac field is calculated by taking the specific activity for a SWIM zone – Local TAZ pair (where activity is defined by one of the four input choices as described above and below, typically employment *2 + population, or LOCALEMP *2 + LOCALPOP) and dividing it by the total activity associated with the given SWIM Zone represented in the specific zone pair. This produces the local zones share of activity for trip attracted to a given SWIM zone. The ProFac is similarly calculated except instead of “activity” the production equation is based simply on population. So the ProFac is calculated by taking the specific population (LOCALPOP) for a SWIM zone – Local TAZ pair and dividing it by the total local population associated with the given SWIM Zone represented in the specific zone pair.

Note that these factors are not used to re-weight the SWIM trip table, those factors are described in the next “Report” file. These factors are simply used to disaggregate or distribute the larger SWIM zone trends down to the smaller local zones. Which factor (production or attraction) is chosen to disaggregate the specific trip (the code loops through all SWIM trips in the weighted SWIM trip table) depends on the “home” location of the trip. If the trip’s home zone is within an alpha zone that falls within the model boundary that it is disaggregated using the “ProFac”. Conversely, if the “home zone” is outside the model area (not represented in the land use crosswalk file), then the attraction factor is applied. Note that the home zone has nothing to do with the ends of the trip, it is where the home zone is for the household, or trucks originating point for the tour. After the correct type of factor is chosen, the code then uses that factor for the specific zone that the specific end(s) of the given trip fall in. So say, the home zone is internal (within the ABM model boundary). Then it would be determined that the “ProFac” be used for the given trip disaggregation. The trip goes from external station 1 to SWIM zone 2300. SWIM zone 2300 is associated with internal zones 203, 204, 205. All of their production factors would some to 1.00, and the single weighted trip would be disaggregated to 3 trips, each of which would get a share of the total weighted trip given their production factor (percent of the population) for that alpha zone. So if their shares were 0.2, 0.3, and 0.5, respectively, and if the weighted trips from external station 1 to SWIM zone 2300 for a give purpose was equal to 10 trips, then the result would be 2 trips 1->203, 3 trips 1->204, and 5 trips 1->205.

This report file is solely used for disaggregating weighted trips to local zones. The next file is the copy of the table used to weight the SWIM trips based on land use.

SWIM_TAZ_LUadj_Report.csv

An output diagnostic file that is not currently being generated for the ABM (the code needs an update). This report file can help the user understand how much land use weight adjustment has been applied to the original or raw SWIM subarea trip table. At this point it is important to remember that SWIM models land use. Land use (like population and employment) are not inputs to SWIM. So due to the fact that SWIM models land use, it is expected that the land use results in SWIM will not match the land use assumptions developed for the local model implementation. Before SWIM’s trends can be used to provide travel pattern information, the travel patterns must first be weighted to align SWIM’s resultant modeled land use with the land use assumptions of the given local model scenario. If this was not done, then as an example, SWIM’s travel trends would be totally ignorant of the planned Mall that was to be constructed in a hypothetical scenario and the external trips that should be drawn to that large new Mall would not be present in the results because SWIM’s land use did not capture the theoretical new mall. So this is a very important and critical step in the process. There are 9 fields in this report file that is a copy of the table used by the code in weighting. The 9 fields are described here:

TAZ – Is the SWIM TAZ (Alpha zone). All SWIM’s internal TAZs (roughly 3000) are included in this file, because all TAZ’s need to be weighted to land use assumptions. For all areas outside of the local model area, the developed land use controls assume that all projects run by ODOT want to conform to the OEA and OED county population and employment projections. All TAZ’s internal to the local model area (which are identified in the “SWIM_Local_TAZ_CW.csv” file) use the local model inputs as opposed to County level controls. However, the County controls are held to, so land use within the local model area should not surpass the county controls that the model falls within, or the external model will likely fail – the solution maybe be to provide a new set of county controls in the “swimControls.Rdata” input. This altered controls file could have more population and employment then has been assumed for the County in previous work to allow the model to complete.
County – this is the county that each SWIM TAZ falls in. This field is used to sum and allocate the county controls.
SWIMPOP – the raw total population by SWIM TAZ for the given model year the SWIM data came from.
AdjustPop – the calculated total population for the given SWIM zone for the local model year. This population could either be derived from the County controls, or the local model TAZ totals for the SWIM zone, depending on whether the SWIM zone falls within or outside of the local model boundary.
SWIMEMP – the raw total employment by SWIM TAZ for the given model year the SWIM data came from.
AdjustEmp – the calculated total employment for the given SWIM zone for the local model year. This employment could either be derived from the County controls, or the local model TAZ totals for the SWIM zone, depending on whether the SWIM zone falls within or outside of the local model boundary.
Atr – This abbreviation stands for “attraction”. This is the total adjusted attraction for the given SWIM zone. The attraction calculation methodology is based on which disaggregation method is chosen. Atr can either be population, employment, or “activity” which is employment * 2 + population.
AtrFac – the Atr attribute is calculated using the adjusted population and employment fields. The AtrFac field takes the Atr field and divides it by the “raw” SWIMPOP and SWIMEMP fields. SWIMPOP and SWIMEMP are used to calculate the “raw” attraction value using the same methodology as is used to calculate the Atr field. The most typical case will be where “activity” (2*EMP+POP) is used to calculate the Attraction Factor. In this case the “AtrFac” field would be equal to AdjustEMP * 2 + AdjustPop) / (SWIMEMP * 2 + SWIMPOP.
ProFac – the Production Factor is calculated using the population of a zone. So the production factor is simply the division of the AdjustPop and SWIMPOP fields – AdjustPOP / SWIMPOP.

As is introduced, this table is then used to re-weight the “raw” subarea trip table out of SWIM. There are four weighting steps:

First an initial weight is given to all the “raw” trips. To do this, first the trip tables are subset to just auto modes (Drive alone (DA), Shared ride 2 (SR2), Shared ride 3+ (SR3P)). Each trip record is then given a weigh of “1” for DA, “0.5” for SR2, and “0.3” for SR3P. Truck records get an initial weight of 1.
A production weight is first applied to ensure the right trip generation for the system. The “Home Zone” is used to identify the correct “Production Factor” to use (the ProFac field above) and then each trip weight gets multiplied by the trip’s home zone production factor (ProFac). After this factor is applied, the weighted trips are summed to the home zone and this trip Production total by SWIM zone is saved as the “trip generation” to be conserved (this production adjustment step is not done for trucks, as there production is not impacted by the population of a given zone).
An attraction weight is then applied. The destination of the trip is used to pick the appropriate attraction factor (AtrFac). The appropriate attraction factor is then multiplied through to adjust each trip to the attractions. This step is performed for the truck trips as well, no further adjustment is made to the truck trip adjustment weights.
The attraction adjustment step will change total production. So the weighted trips are again summed to the home zone (the production zone). This new home zone total is divided by the control obtained from step 2 above. This creates a last factor at the home zone level to reapply to the weights to bring the production (trip generation) back the desired trip production totals.

After this step the trips are summed up to unique zone-to-zone pairs, by home zone, purpose, and time-of-day (period) (the aggregation of like trips is done to save computing time). These similar trips are then disaggregated to local zones (as described above using the land use crosswalk), and then the disaggregated trip matrices (by purpose/mode and time-of-day) are multiplied and balanced to match the volume controls set in the selectLinks.csv.

TOD_Periods.csv

An input file found in \config\cvm. This file is used to define all the periods in the model. In the case of the ABM there are 5 periods that represent the 24 hours of a given day. This is a crosswalk between the local assignment periods and the full-day trip table in SWIM by minute. The four fields in this file are “Period”, “StartTime”, “EndTime” and “Description”. The ABM’s “EV1” period starts at 0 ends at 259 and is described as “midnight to 3am". The EV2 period (the second half of the EV period defined in the ABM) starts at 1830 ends at 2359 and is described as “6:30pm to midnight”. Note that “daily” period is also calculated, however the user does not need to specify this period. The code assumes that a daily must be calculated and defines the “daily” to ensure that it is set up correctly. The code defines daily as follows, “daily” 0 to 2359 “all times of the day”.

Period	StartTime	EndTime	Description
EV1	0	259	midnight to 3am
EA	300	659	3am to 7am
AM	700	829	7am to 8:30am
MD	830	1629	8:30am to 4:30pm
PM	1630	1829	4:30pm to 6:30pm
EV2	1830	2359	6:30pm to midnight

External Model Parameters

To run the SWIM external model there are a handful of settings and flags that need to be specified in a CSV properties file - config/swim_ext/SWIM_External_Properties.csv. The model parameters are specified as key, value pairs in the properties file. The keys are the keywords corresponding to each configurable model parameter and should not be changed. The values are the actual parameter values and needs to be specified by the user. The user must specify the values for the following model parameter keywords:

SWIM_SL_Filename_Pattern – this property is provided to allow for some flexibility in the naming of the SWIM subarea cut file for the given model area. The current default is “_outputs”. When the external model code runs it will look for any files in the “data” folder that end with either “_outputs.zip” or “_outputs.Rdata”. If a zip file exists but no Rdata file, the code will create the Rdataset. Once the Rdataset exists the zip file can be deleted, however it is good practice to keep a copy of the zip for documentation and potentially ease of use / reference, since the zip file holds the csv cuts from SWIM. While one could change the unique “_outputs” identifier, this field should not be changed from the default of “_outputs” without good reason.
externalDisaggregateMethodNumber – This field has to be an integer - 1, 2, 3, or 4. This value should not be changed from the default - 4 without good reason. The part of the model that deals with reweighting the SWIM travel patterns to local land use uses this input. Each value, 1-4, will have the code apply a different land use crosswalk methodology, as described below:
1. SWIMPCT – setting value to “1” will have the code use the “SWIMPCT” field in the “SWIM_Local_TAZ_CW.csv” file. The “LOCALPCT” field will not be used. As described in the section detailing this file, this is somewhat of a brute force method, and requires that the user keep the SWIMPCT field up-to-date with all land use changes, assumptions, and projections at the local level.
2. LOCALPOPSHARE – setting value to “2” will use the “LOCALPCT” field in the “SWIM_Local_TAZ_CW.csv” file. The “SWIMPCT” field will not be used. When calculating how much land use is in a local zone for the purposes of distributing SWIM trips to the local zones, only the local population will be used (as opposed to population and employment), this option was put in for testing purposes, it is not recommended that this option be employed.
3. LOCALEMPSHARE – setting value to “3” will use the “LOCALPCT” field in the “SWIM_Local_TAZ_CW.csv” file. The “SWIMPCT” field will not be used. When calculating how much land use is in a local zone for the purposes of distributing SWIM trips to the local zones, only the local employment will be used (as opposed to population and employment), this option was put in for testing purposes, it is not recommended that this option be employed.
4. LOCALPOP2EMPSHARE – setting value to “4” will use the “LOCALPCT” field in the “SWIM_Local_TAZ_CW.csv” file. The “SWIMPCT” field will not be used. When calculating how much land use is in a local zone for the purposes of distributing SWIM trips to the local zones, both the local employment and population will be used to calculate a “activity” representation of land use, where the “activity” of a zone is equal to (2 * employment) + population, a fairly standard measure of activity for travel modeling. This is the recommended setting and therefore the value should not be changed from the default - 4 without good reason.
YEAR – this is a very important required input as the year field is used in comparing;
1. The Local model year to the SWIM model year – these will likely not be the same and some adjustment will need to occur because of it, and
2. The external station control volume years to the actual year being run. If the years are not equal the growth rate will be used to adjust the external station volume controls to the year being run using the Growth Rate information provided with the external station input file – selectLinks.csv

After setting all of these files and inputs the external model will run and provide the local model area with the external trip pattern information provided by the StateWide Integrated Model (SWIM).

Crosswalk - The name of the SWIM to local zone CSV crosswalk. The file must be present in the inputs folder

Methodology for Developing Growth Rate Assumptions

External Growth rate assumptions can be a critical input to a travel demand model. While an annual growth rate of 5% might have little overall impact to a regional model for a County road that carries 500 vehicles per day; a growth rate of 2% on a major interstate route (like I-5) can mean the difference between LOS C or LOS F along an interstate in a future year analysis. That is to say that, on a major route, that one simple growth rate number can make a significant difference in the model results, in the project analysis, and most importantly in the implementation of the correct project investment/plan.

In the past growth rates mainly came from historical trends (i.e., local traffic counts or Transportation Volume Tables (TVT) that are used in developing Future Highway Volume Tables. For smaller roads engineering judgement or information from counts/trends along roads with similar characteristics was used. An additional information source for growth rates are now also available for Oregon modeling and analysis. That additional source of information is the Oregon StateWide Integrated Model (SWIM). SWIM is not “the answer” when it comes to growth rates, but rather an additional piece of information to help assess and determine future growth rates under alternative forecasts. SWIM takes into account the global and regional economic growth patterns, and thus provides additional information about how urban centers might grow relative to their current conditions and relative to one another. These future relative population sizes are key indicators of the expected level of intercity travel. Different SWIM economic growth assumptions can produce different growth rates at external stations used in the regional models, which likely will also differ from traditional historic growth rates (e.g., Future Volume Tables). Further, SWIM can be used to assess how construction of regional transportation or land use projects might change or influence growth rate assumptions. As an example, widening I-5 south of Salem to Eugene might change statewide shipment patterns and in the 20-year horizon might shift truck traffic from US 97 to I-5, increasing the growth rate assumption along I-5 if that large interstate expansion were to happen. Similar shifts occur as Oregon has altered the posted speeds along I-5 and alternative routes to the east (like US 97). Other examples of regional scale projects that could impact external growth assumptions:

New bridge construction (3rd bridge in Salem or the CRC),
Bypasses, like the Newberg Bypass Phases,
Tolling projects, like bridge tolls along the Columbia or concepts like congestion pricing.

Because of these issues and availability of SWIM forecasts, ODOT recommends considering a range of potential growth rate assumptions in regional models used on larger project analyses. However, given that it is not always possible to test all project scenarios under a series of varying inputs, it is recommended that at a minimum several different growth rate sources be considered, documented, and the final chosen “default” values be justified, reviewed, and agreed upon (peer reviewed), given their significant impact on the end results. ODOT suggests that this review include at least the following scenarios in setting up the travel model reference scenario (e.g., RTPs and TSPs), with alternative forecast scenarios suggested for review for larger projects:

Historic: Historic trends from counts from the external station location, or a location with similar characteristics
SWIM County Growth Projections: A SWIM future that aligns with state population and employment projections to the extent possible.
SWIM Unconstrained: A SWIM future that is not constrained to match state projections (a modeled future).

Some additional potential growth rates that might be considered, given significant lead time to produce the necessary SWIM model runs:

A SWIM run with an optimistic economic future for the area or for Oregon overall.
A SWIM run with a pessimistic economic future for the area or for Oregon overall.
A SWIM run with and without potential regional statewide projects that are anticipated to impact the external flow to the given region.
Alternative SWIM runs with or without significant uncertain land use and transportation projects that could be expected to have an impact on intercity travel.

The evaluated growth rate assumption scenarios should be documented for each external station (as in the Tables below) with a justification for the chosen final “default” growth rate. Documentation might also provide guidance for when to use alternative growth rates. For example, “If funding for the I-5 expansion is identified, then all future projects should use growth rate X for external station Y”. The documentation and discussion should be part of the model peer review including specific local review and buy-in for the chosen “default” rate. (A map showing the external stations can be seen here.)

Documentation of Model External Station Growth Rates

External Station	AWDT 2010	Historic	SWIM	Projected Pop and Emp Growth	Final Growth Rate
1: 1-5 MP-70	19,000	0.5%	1.25%	1%	1%
2: OR-227 MP-45	370	NA	0.5%	-0.5%	0.5%
3: OR-62 MP-28	2800	0.2%	1.5%	1.25%	1%
4: OR-140 MP-8	3,000	0.2%	1%	0.5%	0.5%
5: OR-66 MP-6	600	0.8%	1%	0.1%	0.5%
6: 1-5 MP-5	14,600	0.8%	1.5%	1.25%	1%
7: US-199 MP-10	8,000	0.2%	2%	0.5%	1%

2045 Future Volumes Results

External Station	AWDT 2010	Historic	SWIM	Projected Pop and Emp Growth	Final 2045 Volume Result
1: 1-5 MP-70	19,000	22,325	27,313	25,650	25,650
2: OR-227 MP-45	370	NA	435	305	435
3: OR-62 MP-28	2,800	2,996	4,270	4,025	3780
4: OR-140 MP-8	3,000	3,164	4,050	3,525	3,525
5: OR-66 MP-6	600	763	810	621	705
6: 1-5 MP-5	14,600	18,481	22,265	20,988	19,710
7: US-199 MP-10	8,000	8,519	13,600	9,400	10,800

From the Growth Rate field discussion and defintion above, the external model uses the following linear formula: (AutoAWDT and TruckAWDT) * (1 + (growth rate * (Model year – AWDT_YEAR field)))

The future year of the given scenario (say 2045) is compared to the year of external count data (say 2010) to get the number of years of growth (35 yrs in this case). The growth rate input is assumed to be annual and linear, so the growth rate is multiplied by the difference in years (a 2% growth rate over 35 years would equal 70%) that factor is than added to 1, or the base year volume (factor of 1.7 or 170%). The growth factor is applied to the base year to grow it to the future year.

A simple example for developing an historic annual growth rate value following the linear assumption used in the External model:

2005 volume = 10,000; 2015 volume =15,000
Divide = 1.5
Subtract 1 = 0.5
Divide by the number of years of time that covered the factor (in this case 10) 
= 0.5/10, or 0.05
= 5% linear annual growth rate

This formula (or assumption) is currently hard coded into the external model and therefore is a requirement if using the growth rate functionality in the external model. If a different growth assumption is desired, the user's option would be to calculate the end year volumes outside of the external model and then use the developed future year volumes as volume inputs (AutoAWDT and TruckAWDT), along with setting the future year that those volumes were developed for (AWDT_YEAR). Even if the user were to go this route and use an external process for developing the future year volumes, it would still be good practice to provide the linear growth rate assumption in the "GrowthRate" field, as that field will be used if the model year and the ADWT_YEAR values ever vary.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly