agenda for meeting - 3/5/15

[fscottfoti]

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.

• Mandatory tour generation
• Non-mandatory tour generation (no joint tours)
• Non-mandatory tour location choice (no mode choice logsums)
• Mandatory tour scheduling
• Non-mandatory tour scheduling

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.

[e-lo]

1. I really like the re-org and break up of files in the default/models directory.
2. Along the same lines, it seems strange to have definitions for the same variable in a table spread throughout so many files

• i.e. household_type in households.py refers to household_type_map in settings.yaml
• on the opposite end, it seems strange to have the .h5 file and sampling rate in the same 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.
• Speaking of which, the sampling rate for many AB models changes every iteration.

3. This is not an important detail, but will be important for legibility to make sure that things that do essentially the same thing for each step are named in a similar format. For the most part this looks good, but when I looked at test_defaults.py I noticed that "running" each step of the model actually had a slightly different name for the function that was being called (i.e. workplace_location_simulate vs destination_choice)
4. I was going through the code and thinking of all the places I would have to change it in order to work with a minimally different setup (i.e. what if I wanted to add peak period travel time to workplace location choice utility equation). and found that there was actually a scattering of places that I would have to edit, including the list of variables that is input into 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.
5. there is some lingering magic (i.e. max autos, workplace location choice sample size, etc) that should probably be pulled into a config or at the VERY least made extremely obvious at the tops of files in all-caps.
6. Realizing that you just re-organized a bunch of files, it would be nice to eventually update the documentation of what they are. Some functions are extremely well documented while others (usually for the specific models) are less so.
7. Does Travel Model One really not have shadow pricing? Hmm, something to think about.

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!

[waddell]

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.

[DavidOry]

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?

[guyrousseau]

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.

[fscottfoti]

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 ;)