Project Meeting 2020.11.17

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
  • Proposed revised design here - https://github.com/ActivitySim/activitysim/issues/352
  • 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
• We discussed the DaySim PNR lot choice with ActivitySim page I drafted
  • PSRC is interested in trying it once they get their ActivitySim model working
  • Let's let this idea simmer for a bit and come back to it when we have an example to work with