# Implementation DTApy

[](https://hackmd.io/DyiHiWdqQxiq7aAVG5IRUg)

###### tags: `kul` `dtapy`
## observations and progress tracking

If someone starts working on this repository and runs into an issue it may be useful to search these notes for related terms. The idea is that eventually I will be able to turn this into documentation that's more structured and proofread

### 04.05.2021
- Testing on Antwerp case after convergence on cascetta test network
- measuring convergence on flows while you also smooth on them is a bad idea - duh. What you're measuring is just the amount that you reassigned, even worse with AON it's common that there are paths that go from unloaded to loaded.
:arrow_right: Costs should be used for measuring the gap if you smooth turning fractions. Flows will erratically flip flop depending on your smoothing mechanism.
Below is a snippet from [boyles book](https://sboyles.github.io/research/index.html#book), it's for the static case but can easily be adjusted to dynamic.


- Interesting discussion on numerical precision in DTA: how does it compare to the sensitivity of the input arguments both on the supply and demand side and what kind of differences can be expected in different model runs with *the same* input due to rounding errors?
-- what does this imply for distributed computations and error propagation, there ought to be some papers in that domain.
-- Patrickson and Bar Gera have a paper on this for the static case
- A common issue I keep on bumping into is that array casting isn't supported by numba in all it's variants as in numpy. The example below does work in numpy, but not in numba.

import numpy as np
arr=np.arange(10, dtype = np.float32)
np.array(arr, dtype=np.float64)

As far as I know in numba only the calling the astype method on arrays works. So the method below passes without errors.

from numba import njit
import numpy as np
@njit
def numba_casting(arr):
    return arr.astype(np.float64)
arr=np.arange(10, dtype = np.float32)
numba_casting(arr)

I ran some tests with the convergence criteria proposed above.I was trying to exploit the arrival maps for constructing the shortest path cost, e.g. just multiply the arrival map value for a given OD flow and time slice and get the lowest possible cost.
In the example network below I had excessive spillback on a connector, in that case the cost calculation doesn't work properly because it only considers vehicles that left the link during a given time period.
That means that the arrival time from the centroid on the left hand side is reported as if all vehicles had the opportunity to depart from the connector in the first time slice. Even though some of them left in later time periods, their travel time is reported as the travel time in those time slices even though they 'started' on the connector at `t=0`.


- [x] implement relative gap as convergence criteria in dta :memo:
- [ ] implement proposed relative excess cost convergence criteria for DTA :memo:

### 05.05.2021

- What are the conditions under which the network loading result can be labelled wrong?
-- while iterative LTM is running there may not be states with negative queues, results obtained in such a scenario cannot be trusted
- It makes sense to write a debugger for the inputs, odd results appear if the turning fractions do not follow some constraints which can easily happen if you're experimenting or implementing some new feature
-- turning fractions need to be between 0 and 1 and the sum of all turns with a given starting link needs to be 1
-- if the free flow costs (length/speed) of the link is smaller than single float precision results cannot be predicted
- [x] Figure out the U-Turn bug, see below
- Relative excess cost as convergence criteria yields some issues since the cost definition used in route choice and the one used in calculating the cost from the CVNs are not aligned yet. The cost experienced by the vehicle when making it's decision based on the arrival map does not line up with the prediction - even in equilibrium.
- [ ] Fix this inconsistency issue

### 02.06.2021
- fixed u-turn bug by going to turn based costs and the dual graph for the updating scheme of turning fractions,
- This doesn't resolve the issue at its core though: if travel times between two paths have a large enough delta vehicles may start departing on the longer path and still turn around if there is a low cost cycle in the network.
- added tests for flow continuity, turning fraction sums, monotonicty ..
### 03.06.2021
- adjusted deterministic route choice module to allow for arbitrary turn closures (not just U-Turns)
- added more tests