🚀 Feature: Replace Akcelik Curves with BPR Curves

User Story

Inherited from TM2.1, the current TM2.2 uses BPR curves for freeway (ft 1) and expressway (ft 2), and Akcelik curves for all others including ramps (ft 3), major (ft 4) and minor (ft 5) arterials, collectors (ft 6), residentials (ft 7), and services roads (ft 99).

The akcelik curves in TM2.2 have the following two characteristics:

It has a much steeper slope compared to BPR
It has a distance based terms, which causes an exploded delay on very short links with high v/c

This excel workbook demonstrates the two characteristics. Akcelik plots.xlsx

In Task Order 5, we refined network fidelity to remove assignable and use FT based rules to keep links for highway assignment. We tested keeping FT <= 6 (Run 8) and keeping FT <= 7 (Run 11). During which we also tried re-connecting centroid connectors to local and residential links. However, it caused the run time to increase even when we had fewer links in the network than before. We then noticed due to the new centroid connectors dumping traffic onto locals and residentials, there were many local and residential links with high volumes (v/c > 1). Using akcelik curves, such links had large delay and therefore caused the assignment to take longer to converge. We then did another test (Run 15) with the old centroid connectors which compared to the new ones, did not load as much traffic to locals and residentials. The test run showed run time improvements and we decided to go with Run 15 as the final run for changing network fidelity, and ended up keeping FT <=7 and the old centroid connectors. See more details in Sijia's comment

Greg then suggested doing another run with Run 11's network, replace the akceliks with BPRs for local and residential links. See Greg's comment, using SFCTA's BPR curves for locals. This will help to see if we should use BPRs for most links.

Dave called out that currently the bridge toll plazas are coded as FT 7. It makes sense for them to use akcelik curves due to the high delay unique to them.

Taking in inputs from both Greg and Dave, I did two more runs:

Run 16: use Run 11 network, which is kepping FT <= 7 and connecting connectors to FT 7, replace akceliks with SFCTA BPRs for locals and residentials.
Run 17: same as Run 16, but keep akcelik for bridge toll plazas.

Run	Description	Assignment Iterations[EA,AM,MD,PM,NT]	TAZ Assign and Skim Run Time (hours)
3	The `assignable` based network, starting point of TO5, relative_gap=0.05	3,10,9,19,4	5
8	Keep FT <= 6, rebuild connectors to FT6, relative_gap=0.05	3,21,19,51,4	7
11	Keep FT <= 7, rebuild connectors to FT7, relative_gap=0.05	3,15,14,32,4	11.5
15	Keep FT <= 7, use connectors from the `assignable` network, relative_gap=0.05	3,11,9,17,3	5
16	Keep FT <= 7, rebuild connectors to FT7, relative_gap=0.05	3,12,9,24,4	6
17	Keep FT <= 7, rebuild connectors to FT7, relative_gap=0.05	3,12,9,24,4	6

The two runs showed very similar results that are close to Run 15 (run time, volumes, skims), and almost no difference on the toll plaza links. The toll plaza links coded have large number of lanes, large capacity, and their v/c is lower than 1. Therefore, the akcelik curves did not make a different on toll plazas.

This means the following:

Changing Akcelik to BPR is worth trying for all links, and it will allow us to rebuild centroid connectors to locals and residentials
We might need special treatment for toll plaza links to increase their delay.

Progress:

[ ] Sufficiently defined
[ ] Approach determined
[ ] Tests developed
[ ] User story satisfied
[ ] Doc strings
[ ] General documentation
[ ] Passing tests

Priority

Low?

Level of Effort

Low - Medium

Resolution Ideas

Project

Who should be involved?

Users: @gregerhardt @lmz @FlaviaTsang Reviewers: @DavidOry

Risk

Have not tested replacing for all FTs. Once replaced, need to check acceptance criteria.

Tests

[ ] Test for...

BayAreaMetro / tm2py