About
I am building a computational framework that makes activity-based DDCM estimation tractable at city scale, and re-specifying its utility function so that activity timing emerges from preferences rather than from hard-coded rules.
Two bottlenecks in activity-based demand modelling:
- State-space explosion — a single city has ~145 million states (time × zone × activity × duration × mode × history). Estimating on that is a 1000-CPU-day / 6.7 TB problem.
- Timing is usually assumed, not estimated — classic specs bolt hard time windows onto the model ("work happens 6am–10pm"), so behaviour is partly an input, not an output.
| # | Contribution | What it does |
|---|---|---|
| 1 | DDCM as a DAG | Time only moves forward → no cycles. Backward induction is a reverse topological sort, so a GPU processes each time level in one batched kernel. |
| 2 | Reachability pruning | Forward BFS with Hägerstrand space-time-prism constraints keeps only reachable states. 145M → 1.5M (~1%), no approximation. |
| 3 | μ(t) utility | Each activity gets a time-varying marginal-utility profile μₐ(t). Trip-making emerges from the gradient. Timing becomes an output. |
End-to-end: ~69 hours → 105 seconds (~2,400×) ·
memory 6.7 TB → 6.5 GB · 144-zone Higashi-Hiroshima network
DDCM Implementation Reports
Research Presentation Deck
Interactive Slidev presentation — computational framework, reachability pruning, μ(t) utility, and estimation results. Updated each semester.
Profile LL Scan — c_change (K=10 v7, Zone-Agnostic)
1D profile likelihood sweep over c_change (16 grid points, 569 workers, all 29 groups).
Interior MLE confirmed at −0.615; v7 checkpoint (−0.756) is 1.6 LL units sub-optimal;
HH MNL prior (−0.301) firmly rejected (−99.9 LL units). c_change is identified. v9 iter 4: LL=−7590 (+358 over v7), converging.
Root Cause Investigation — Why δ Converged to Near-Zero
Two bugs identified in all prior runs (v1–v5): (1) zone-matching bug made WORK steps invisible
in Uobs for 701/702 workers; (2) non-worker data biased δ downward through V(s₀).
Both fixed. v9 running: iter 4 best LL=−7590.01 (+358 over v7), δ=0.043, c_change=−0.770, converging.
Note: c_change was a separate earlier issue, already resolved by
forbidden_mask fix.
Profile LL Scan — δ × μ_home (K=10)
K=10 profile likelihood heatmap over δ and μ_home. The flat δ axis was the diagnostic clue
that exposed the zone bug — Uobs was completely δ-invariant because WORK steps
were silently dropped. Interactive heatmap and slices.
Work Timing Analysis — K=10 NFXP
Why simulated work start is ~14:51 vs observed ~8:30.
Interactive utility plots, parameter sliders, and simulation validation (N=934 agents).
Based on v5 estimates (zone bug active) — shows how the model behaves mechanically;
timing results will change after v6 converges.
Lab Meeting Reports — M2 Spring 2026
2026-05-11
Research Progress (M2, May 11, 2026)
K=10 convergence + BHHH SEs, work timing gap, JSPS outline, 11 lit reviews
M2 Spring
Web
GitHub
Slides
Lab Meeting Reports — M1 Fall 2025 (Archive)