Project Meeting 2020.11.17 - ActivitySim/activitysim GitHub Wiki
Technical call
Update from Jeff on TVPB multiprocessing
We have two versions of TVPB - dynamic and static
Dynamic computes on demand and is good for small samples, single threaded development, etc.
This works well single process
Static, or precomputed, which pre-computes tap-to-tap total utls for the 20 segments (time-of-day, demographic segment, access mode) and stores them in skim like data structures for later use
This is done in a new initialize_los submodel
Also works single process
But works better multiprocessed since shared memory usage becomes read only
Static / pre-compute is working multiprocessed now using shared memory arrays
Currently working on multiprocessing the pre-computer
The pre-computer is multiprocessed by segment - time-of-day, demo segment, access mode - and not origin zone since faster/easier to just calc each segment tap-to-tap matrix at once
Should have working later this week
We will then see how fast it is
Could possibly reduce data types to ints/scalars like we've discussed a few times to save memory and maybe speed it up
Jeff will wrap up this week and then I'll run the full scale Marin work tour mode choice example
We're keeping the little 3 zone toy example working too, which exercises the functionality for a complete model run
We're still doing the maz to maz best path ranking in tour mode choice...can we pre-compute/cache that as well?
CT-RAMP doesn't do that, but maybe we can and then we can get it to run even faster
We have three basic options
do maz-to-maz ahead of time, which may mean wasted calculations and a giant cache
precompute and intelligently cache - which we did in CT-RAMP and we're doing now
do all on-demand - which is not efficient
The important thing to do is to avoid as much duplication of calculations as we can
TVPB does a lot more calculations than one or two zone approaches so runtimes will be longer
Of course runtimes, and acceptable performance, depends on a number of things - input data, RAM, processors, network coding settings, etc.
TM2 is slower than TM1 because of TVPB but also for other reasons. Yet you also get much more detailed transit modeling capabilities
I'll test the full scale example soon and then we can discuss performance with more information
There's also interest in simplifying the design to save runtime
We're building it with flexibility/ease of revisions in mind as well for future updates/improvements/revisions
Let's stand up a solid version 1, get it in use, and get some feedback
Maybe, implementing the scalars/factor data types stuff we've discussed will be good once we're done with TVPB
MTC plans to take TVPB even further - to add tap / parking lot capacity constraint
And we can use the time dimension of an ABM to watch the lots fill up and then shut them off / reduce their attractiveness
This is planned for later down the road
Update from Ben on telecommute model spec
I shared an example settings/configs file setup for work_away_from_home and telecommute_frequency models
This is based on the ActivitySim TM1 example + the existing SANDAG model expressions
Need to think some more about how to get an origin based accessibility measure - multimodal accessibility to total employment - available to the work_away_from_home model
Can we just use the existing auto accessibility to total employment measure we already have in the example?
All things being equal, the multimodal accessibility measure would be better
The TM1 example has a simpler aggregate accessibility model than SANDAG's more feature rich accessibility calculator
Update from Jeff Newman on interaction_simulate estimation recipe
Seems straightforward and Doyle to implement after TVPB
Only file level changes so we don't have to change what's inside the files
Newman not waiting on Jeff since he modified the example for testing
Update from Clint on ARC model via email:
We got the ARC multi-processor setup last week, and the run times came down from about 18 hours for the scheduling models to around 4 hours. We still haven’t tested the MTC multiprocessor run on a the same machine.
I have an outstanding pull request which encompasses two issues. The first is removing the hard-coded person types from CDAP. The second allows for time of day labels to be re-used in the settings.yaml file for different time intervals. In the case of ARC, this allows us to define the Evening skims for time periods just after midnight and just before midnight.
We are aiming to finalize the ARC modeling work in the next several days, and the pull requests for parking location choice and trip scheduling will be coming before the end of the month.
Adaptive chunking could help ARC as well
PSRC wants to test the adaptive chunking too
It's in the multizone branch so need to wait until that's released later this year
ActivitySim runs faster on Linux and so PSRC is looking into a Linux EMME/Asim setup
Linux machines also cheaper on AWS than Windows machines