Closed fscottfoti closed 9 years ago
default/models
directory.household_type
in households.py
refers to household_type_map
in settings.yaml
settings.yaml
that you would have the household_type_map
. One refers to a run-spec, the other refers to something that will be static in your setup for the most part. workplace_location_simulate
vs destination_choice
) workplace_location_simulate()
, which seems ripe for somebody making an error. I think that maybe going through a few of these uber simple examples will highlight a few ways to make the code a little more manageable and less error-prone. The workplace location model predicts the zones in which various people will work. Interestingly there's not really any supply side to this model - we assume that in a properly calibrated model there are workplaces for the people to work.'''
Fun Stuff!
The workplace location model predicts the zones in which various people will work. Interestingly there's not really any supply side to this model - we assume that in a properly calibrated model there are workplaces for the people to work.’’'
One thing to consider for this is a workplace choice model design in which the worker chooses a specific (vacant) job, which happens to have a sector id and zone id. We’ve done that previously for the PSRC model (it was in the land use model side) and it worked rather well. Balancing origins and destinations of work trips becomes pretty trivial, by construction.
Travel Model One has shadow pricing for workplace location choice. You may be responding to an initial choice not to implement shadow pricing in the first pass through the model?
The ARC workplace location choice application procedure also utilizes an iterative shadow pricing mechanism in order to match workers to input employment totals. The shadow prices are written to a file and can be used in subsequent model runs to cut down computational time.
Right - I did forget about shadow pricing. And perhaps comments in the code are not the best place to pick highly theoretical fights about the best way to represent supply ;)
This fortnight we made progress on models 4-8 of the roadmap (list below). We have the basic flow between these models mostly operational, and a good portion of the relevant variables are defined. Generally, whenever something looked like it would take longer than a few hours I opened an issue and saved it for later. I wanted to get a pretty good idea of how the whole model system might look to know if there were any major gotchas, and there are some minor issues but nothing major as of yet.
Although there are a number of intermediate branches that haven't been merged yet, this is the branch that contains reorganized code and the one I will be walking us through tomorrow.
https://github.com/synthicity/activitysim/tree/file-reorg/activitysim/defaults
For reference, a run of the current modeling system is available here to show what it looks like to execute:
http://nbviewer.ipython.org/github/synthicity/activitysim/blob/file-reorg/example/simulation.ipynb
I'm also keeping a document of questions / issues which we can cover as time permits:
https://github.com/synthicity/activitysim/blob/file-reorg/example/README.md
Matt has also made significant progress with CDAP, with full testing, etc, but this is not yet complete.