In destination choice, shadow pricing is a constant to doubly constrain the model. This is a simulation-based approach.
Scaling term in order to account for the fact that workers does not equal jobs in the model inputs
Added shadow pricing settings in a new yaml
Set method: “method3” but name could be changed
Set the land use file fields for scaling
Shadow_pricing.py includes the iterating and most of the shadow pricing code
Location_choice.py includes the sampling process
Status
Code is mostly in place
Tested with a small sample from a 2-zone system
Currently running without errors
Number of workers to simulate plateau at iteration 4, 5, and 6 due to multiprocessing – currently testing without multiprocessing
Questions
Since shadow prices cannot be estimated, and calculating new shadow prices can be time-consuming in terms of computational time, should shadow prices be updated when the modeled transportation improvements are significant enough to modify the usual workplace distribution?
Judgment call
Purpose of this process to make it faster so it’s easier to rerun if needed
Tests after implementation: how do things change iteration to iteration and in the end, look for potential bias. Metrics could include:
Compare flow from old method, new method, and observed
TLFDs, average trip lengths
Segment by zone size
There is documentation about this process but maybe not enough detail on the tests, could be expanded if requested (RSG edit: documentation is not in scope but there is a write up in the tasks that can be expanded upon to add detail on testing that will be conducted, or we can just continue to use slide decks as we go)