flowchart LR
SE["Base SE data<br/>(2023 or 2055)"] --> Base["Base run<br/>no HH added"]
SE -->|"+N HH at Murray"| Control["Control run"]
SE -->|"+N HH at Site A"| SiteA["Test: Site A"]
SE -->|"+N HH at Site B"| SiteB["Test: Site B"]
SE -->|"+N HH at Site ..."| SiteN["Test: Site ..."]
Base --> Metric["Delta VHT = Test minus Base<br/>peak periods, congested V/C tiers"]
Control --> Metric
SiteA --> Metric
SiteB --> Metric
SiteN --> Metric
Metric --> Index["Burden Index(site) =<br/>Delta VHT(site) / Delta VHT(Murray control)"]
Household Location Burden Index
Scoping document — for review, only a base scenario exists so far
The question
This study asks whether the TDM could quantify the additional Congested Roadway Capacity Demand — peak-period roadway burden — created by adding a fixed number of typical households (500 or 1000) at different locations around the region. Capturing that burden properly means letting the TDM run its full multimodal, all-day pipeline for those households (mode choice, trip timing, route choice) and measuring the delay it imposes on everyone else already on the system, not just the new households’ own travel.
The result would be expressed as a Burden Index relative to a reference location at the region’s geographic center (Murray): a household placed in Western Davis County, for instance, might place meaningfully more burden on the system than one placed in one of Davis County’s designated City or Town Centers.
Decisions needed before building this
| Decision | Options | Recommendation | If left unresolved |
|---|---|---|---|
| N — households per site | 500 or 1000 | 1000, for a more clearly measurable effect | Defaults to 500 (the first-mentioned number in the original ask) |
| Congestion threshold | V/C ≥ 0.8, ≥ 1.0, or report both | Report both — cheap, since both are already in the same summary CSV | Defaults to reporting both |
| Peak window | AM+PM only, or all four periods | AM+PM, matching “peak-period” in the original ask; MD/EV available in the same file if wanted later | Defaults to AM+PM |
| Site list | See “Candidate sites” below — Murray control plus typical-vs-center pairs in Western Davis, SW Salt Lake, and western Utah counties (each with alternates) | Start with Murray + Syracuse pair (minimal proof-of-methodology build); once proven, expand to the full 7-site recommended list (Murray + 3 typical-vs-center pairs) | Build proceeds with the recommended picks below unless told otherwise |
| Network vintage(s) | 2023 (today) only, or 2023 + 2055 (long-range Needs) | Both — burden today, plus whether the center-vs-sprawl gap holds, widens, or narrows as the region grows to its 2055 forecast. More relevant to a growth-siting decision than a single-year snapshot | Proposed as part of the initial build, not a later add-on |
Proposed methodology
Design: one Base run, one Control run (Base + N households added at a Murray TAZ — the geographic-center reference), and one Test run per candidate site (Base + the same N households added at that site’s TAZ). Same household count everywhere, so differences reflect location, not household mix.
Run this whole pattern twice — once against 2023 (today), once against 2055 (long-range Needs), proposed as part of the initial build rather than a later add-on (see “Decisions needed” above). The diagram below shows one vintage; the 2055 pass is the identical pattern against the 2055 network and 2055 SE forecast instead.
Metric: systemwide congested vehicle-hours-traveled (ΔVHT), not just the new households’ own trips — the whole point is capturing the delay imposed on everyone else, which only shows up as a regionwide before/after difference. Peak periods (AM, PM), filtered to links at or above a congestion threshold (V/C ≥ 0.8 and/or ≥ 1.0).
Burden Index = ΔVHT(site) ÷ ΔVHT(Murray control) — giving the “1.6x” / “1.2x” style figure directly, computed separately for 2023 and 2055 so the two years can be compared side by side.
A caveat on comparing 2023 and 2055 directly
N households is a much bigger relative bump against a TAZ’s 2023 household count than against its 2055 forecast, which already assumes decades of organic growth at these sites. A rising or falling Burden Index between the two years could partly reflect that shrinking relative size, not just a real shift in how the network absorbs growth at that location — worth calling out when the results are reported, not something the study design itself corrects for.
Baseline signal, from the registered base scenario
These are real numbers from an already-completed model run — not simulated for illustration. That run is the region’s current (2023) road network exactly as it exists today, with no new households added yet; reusing it here meant no new traffic-model run was needed just to produce this table. It shows how congested the road network already is, by time of day, using the same “how congested” math (V/C ≥ 0.8 and ≥ 1.0 — road segments running at or above 80%/100% of their capacity) that will measure each candidate site’s impact later.
| Period | Total VHT | VHT at V/C ≥ 0.8 | VHT at V/C ≥ 1.0 |
|---|---|---|---|
| AM | 225,355 | 66,522 (29.5%) | 17,225 (7.6%) |
| MD | 405,888 | 43,243 (10.7%) | 908 (0.2%) |
| PM | 338,003 | 146,780 (43.4%) | 51,135 (15.1%) |
| EV | 312,990 | 115 (0.0%) | 0 (0.0%) |
Regionwide lane-miles in this network: 9,014 (segment-direction rows).
This is system scale, not the site-comparison metric itself — it’s today’s regionwide congested-VHT backdrop that a 500–1000-household ΔVHT would be measured against. PM is the most congested period by a wide margin; AM is a distant second; MD and EV carry almost no V/C≥1.0 congestion. This confirms AM+PM is the right peak-period scope for the Burden Index, and suggests PM alone may show the clearest site-to-site differences.
What’s still missing for Control/Test scenarios
This base scenario only has the segment summary curated so far — the regionwide congestion-tier summary (Summary_HighwayNet.csv, needed for the Δ calculation once Control/Test scenarios exist) requires the custom driver-script edit described below, then re-registering base with that output included too. A 2055 counterpart to this base scenario doesn’t exist yet either — it needs the same one-step import-manual-run registration against the v10.0-beta.2 run set’s already-run Needs_2055 scenario, no new Cube Voyager run required (see “How this fits the run-management framework” below). Adding Control/Test scenarios for either year still needs real Cube Voyager runs — see “Decisions needed” and “Effort and runtime” below.
Candidate sites
Note
Candidates, not yet confirmed. Data-driven, but the final pick is a decision for the study lead — see “Decisions needed” above.
Method: spatially joined the TDM’s own TAZ shapefile (tdm/1_Inputs/1_TAZ/WFv1000_TAZ.shp) against WFRC’s Wasatch Choice 2050 Centers (Vision Map) feature service — the actual regional-centers layer referenced in the original ask, queried live from services1.arcgis.com/taguadKoI1XFwivx/.../Wasatch_Choice_2050_Centers_(Vision_Map)/FeatureServer — then cross-referenced household counts from SE_2023.csv. Household/city figures below are pulled live from those same local files on every render.
| Candidate | TAZID | City | HH | Pop | Note |
|---|---|---|---|---|---|
| Murray control | 1619 | Murray | 1,440 | 2,663 | Populous, ordinary residential TAZ – geographic-center reference |
| Western Davis – typical (recommended) | 684 | Syracuse | 751 | 2,511 | Large low-density subdivision, no designated center nearby |
| Western Davis – typical (alternate) | 602 | West Point | 404 | 1,747 | Further west by X-coordinate; smaller sample |
| Davis CTC – Syracuse City Center (recommended) | 674 | Syracuse | 398 | 1,367 | Same city as the recommended typical site – isolates center-vs-not |
| Davis CTC – Clinton Town Center (alternate) | 610 | Clinton | 185 | 626 | |
| Davis CTC – West Point City Center (alternate) | 600 | West Point | 346 | 1,051 | |
| Davis CTC – Station Park, Farmington (alternate, Urban Center) | 780 | Farmington | 301 | 1,130 | Larger/more significant center, for a bigger contrast |
| SW Salt Lake County – typical (recommended) | 2048 | Herriman | 793 | 2,853 | Largest typical TAZ in the county’s southwest corner |
| SW Salt Lake County – typical (alternate) | 2066 | Riverton | 691 | 2,426 | |
| SW Salt Lake CTC – Herriman Town Center (recommended) | 2039 | Herriman | 1,146 | 4,026 | Same city as the recommended typical site – isolates center-vs-not |
| SW Salt Lake CTC – Downtown Riverton (alternate) | 2080 | Riverton | 322 | 798 | |
| Western Utah County – typical (recommended) | 2467 | Eagle Mountain | 1,234 | 5,198 | Largest typical TAZ among the newly added target areas |
| Western Utah County – typical (alternate) | 2519 | Saratoga Springs | 1,134 | 4,337 | |
| Western Utah CTC – Eagle Mountain City Center (recommended) | 2313 | Eagle Mountain | 165 | 666 | Same city as the recommended typical site – isolates center-vs-not |
| Western Utah CTC – Crossroads, Saratoga Springs (alternate) | 2509 | Saratoga Springs | 0 | 0 |
Recommendation: start with the Syracuse typical site (684) paired against the Syracuse City Center (674) — same city, so the comparison isolates “designated center vs. not” rather than mixing in city-level differences, which is exactly the contrast the original ask describes. Combined with the Murray control (1619), that’s the minimal 3-scenario build (plus base) needed to prove the methodology end-to-end.
Once that’s proven, the recommended fuller site list repeats the same same-city typical-vs-center pairing in two more fast-growing, peripheral parts of the region (household counts in the table above): Herriman (2048) vs. Herriman Town Center (2039) for southwest Salt Lake County, and Eagle Mountain (2467) vs. Eagle Mountain City Center (2313) for western Utah County. That’s 3 typical-vs-center pairs plus Murray — 7 sites total, each run against both network vintages.
What the model already gives us to work with
This isn’t hypothetical — the pieces exist in the TDM today, just not wired together for this purpose:
| Need | Existing TDM piece | Status |
|---|---|---|
| Systemwide VMT/VHT by period, purpose, and congestion tier (V/C ≥ 0.8, ≥ 1.0) | 2_ModelScripts/7_PostProcessing/4_BCA_Summaries/02_Summarize_HighwayNet.s |
Exists, does exactly this — but its READ FILE line is commented out in the default driver script, so it doesn’t currently run |
| A way to add households to a specific TAZ without touching anything else | WFRC_SEFile / MAG_SEFile — plain TAZ-level TOTHH/HHPOP CSVs |
Exists; this framework already has a proven pattern for generating per-scenario SE variants (used for the non-motorized-2023 study) |
| 2023 and 2055 base networks to build on | The v10.0-beta.2 run set’s Base_2023 and Needs_2055 scenarios, both already run in this repo |
2023 done — registered as this run set’s own base scenario via import-manual-run. 2055 not yet registered, but the same one-step import-manual-run against the already-run Needs_2055 scenario is all it needs |
| Household composition (size, income, workers, autos) for the “typical household” | 1_HHDisag_AutoOwn/ (LifeCycle → HHDisaggregation → AutoOwnership) |
The model derives this itself from TOTHH/HHPOP, using distributions that already respond to local accessibility — there’s no separate lever to force a specific household profile |
How this fits the run-management framework
Mechanically, this is a new run set — household-location-burden — following the same pattern already proven by non-motorized-2023 and bring-work-trips-closer-to-home:
base(2023) — done. Registered by reusing the existingv10.0-beta.2-2023run rather than re-running full feedback from scratch. To pick up the BCA congestion-tier summary once the driver script is edited, its raw folder can be re-entered viastart_at_label(resuming just the post-processing steps) rather than a full re-run.base-2055— same treatment, reusingv10.0-beta.2’s already-runNeeds_2055scenario. Not yet registered.control-murray-2023/control-murray-2055and onesite-<name>-2023/site-<name>-2055pair per candidate location — each pointed at its own generated SE file (drawn from the matching year’s SE forecast) viaoverrides.WFRC_SEFile, the same relative-path mechanismnon-motorized-2023uses.- A shared custom driver script (this run set’s own copy of
__HailMary_1Subfolder.s, with the BCA summary line turned on) — the framework’s existingdriver_scriptmechanism, no core code changes needed. - Outputs curated: just the small
Summary_HighwayNet.csvper scenario — well under the size ceiling, no raw network/matrix files committed. - A small Burden Index calculation module, reported here once real runs exist — same shape as
non-motorized-2023’sreport_loader.py.
No changes to the TDM codebase, the orchestrator’s core logic, or how Cube Voyager runs are required — this is entirely new configuration plus one custom driver script, the same category of work as every other run set in this repo.
Effort and runtime
Each Test/Control scenario needs a full feedback run (mode choice logsums + four-period assignment) — households are added before disaggregation, so nothing upstream can be skipped or reused between sites. Only the two Base runs benefit from reuse (both already run, neither needs re-running). Running both the 2023 and 2055 vintages roughly doubles the Test/Control run count for the same site list. For the recommended 7-site list (Murray control + 3 typical-vs-center pairs), that’s 1 control run + 6 test runs, × 2 years = 14 Test/Control runs against two free Base runs — before counting any alternates. Runtime scales linearly with number of sites and years; max_parallel_runs (already supported, not yet exercised on a real multi-scenario batch) could help once Cube Voyager licensing/hardware limits on this workstation are confirmed.
Why not combine multiple sites into one run? Congestion is non-linear — that’s the whole reason V/C-tiered VHT is the metric. Adding households from two sites in the same run gives you their combined effect on network delay, with no way to split credit between them afterward (their trips might stack on the same congested links, or might not interact at all). Base and Control aren’t combinable either — they’re mutually exclusive states of the same synthetic population. Recovering true per-site effects from combined runs would need a full factorial design (every combination, solved for interaction terms), which needs more runs than one-at-a-time, not fewer. So N candidate sites need N separate Test runs against one shared Base — this design is already the minimal N+1, and the +1 is free (Base is reused, not re-run).
Suggested build order: 1. Confirm the Base-run reuse strategy and the driver-script edit; validate Summary_HighwayNet.csv comes out as expected on the existing 2023 Base run alone. 2. Register base-2055 the same way, and confirm it too. 3. Build SE generation + one real site + the Murray control for 2023 only; validate the ΔVHT / Burden Index math end-to-end on real output before committing to the full site list or the second year. 4. Once proven, replicate that same site + control for 2055, to confirm the pattern holds across both vintages. 5. Add the remaining sites from the confirmed list, for both years.
Bottom line
The metric, the SE-modification mechanism, and the run-set framework are all already proven in this repo for other studies — this is a matter of configuration and one small driver-script change, not new engineering. Every remaining decision above (N, congestion threshold, peak window, final site picks, network vintages) has a sensible default, so the build can proceed on the recommended picks — 2023 and 2055, both — unless told otherwise.