Project Meeting 2022.11.03

Agenda

• AMPO conference recap
• Update on Phase 8 scoping
• Review of how DaySim handles out-commuting
• Status of ODOT(Ohio) draft proposal to formalize a process for integrating code developed outside of the consortium into the official ActivitySim code
• Model Selection for ActivitySim Memory Profiling Task

Action Items

• Joe C to schedule side meeting with Rebekah Straub and other interested participants to further discuss the proposed process for code integration. Any consortium members wanting to join this call should email Joe.
• Jeff to isolate the SEMCOG extension incorporation and create a separate pull request for review.

Meeting Notes

AMPO conference recap

• Technical difficulties with virtual participants but valuable discussion at the end.
• No leads on new agencies interested in ActivitySim.
• Presentations to be available online at some point, but unknown as to when.
• For those that attended, look for the post-conference survey available.

Phase 8 Scoping

• Set an ambitious schedule in hopes of getting NTPs out before TRB.
• AMPORF anticipates the following schedule:
  • Nov 18: IRFP release
  • Dec 12: Proposals due
  • Dec 19: Draft task orders provided to bench contractors
  • Dec 23: Task order contract amendments finalized
  • Jan 6: Task order contracts executed

Review of how DaySim handles out-commuting:

• "The “out-commuting’ proportion of workers in each TAZ are assumed to go to work locations outside the model region. Since ABM involves simulating choices of each individual in the synthetic population, the workers that “out-commute” are determined as a probabilistic choice based on the fraction specified in the IXXI file. DaySim does not simulate the day patterns of such workers. Similarly, the “in-commuting” proportion results in a portion of job in each TAZ not being available for workers in the model region. These are assumed to be taken up workers from outside the model region." (from http://modelwiki.northfloridatpo.com/3.6_Daysim_Inputs).
• Current code only requires config changes for in-commuting, which is already incorporated into the pull request. It does not effect the ActivitySim code, so user can decide whether or not to use it.
• In application, CTPP can be used to estimate the in-commuting employment reduction. For MWCOG, county-level employment reduction factors were estimated and then applied to zones within the county.
• This discussion prompted follow-up from a previous meeting related to pulling in SEMCOG extensions to the core ActivitySim code. Jeff moved these into the code because it made it easier to test the model. In hindsight, Jeff should have made a separate pull request related to these extensions so that it could be reviewed - he will do this. RSG noted that the univesity extensions are very specific to SEMCOG and propose to keep those as an extension.

Status of ODOT(Ohio) draft proposal to formalize a process for integrating code developed outside of the consortium into the official ActivitySim code

• Rebekah sent out a draft process and received some comments that were reviewed with the group.
• Comments included a desire to have the consortium and its bench contractors be responsible for crafting procedures instead of partner agencies (or their consultants).
• It was noted that CS would likely do this work for Ohio, and they are a bench contractor. However, some noted that the decisions should be routed through the ActivitySim contract in order to allow the consortium to make decisions as to when and how to incorporate and maintain new code.
• This issue was not resolved and a separate meeting was proposed. Joe will coordinate with Rebekah; anyone else wanting to join the conversation should email Joe.

Model Selection for ActivitySim Memory Profiling Task

• Issue created on Github: https://github.com/ActivitySim/activitysim/discussions/621
• WSP would like to start this task soon and is looking for feedback this week.
• One of their hypotheses is that the memory requirement scales linearly with household samples, so we don't necessarily need a 100% sample run for profiling. For example, we currently see the memory pattern in a 25% sample MTC run, with mandatory tour scheduling being the peak, and we expect a similar pattern for other runs. We can do a 5%, 10%, 20% run to confirm this hypothesis. There were no objections from the group to using a smaller household sample.
• WSP noted that they could not run the ARC model without chunking. Jeff thought it unlikely to find a reasonable resource to do this. WSP will try with virtual machines with larger RAMs for 100% runs, see if any fits.
• On the call today, the group had expressed preferences on choosing:
  • prototype_arc
  • prototype_mwcog
  • prototype_mtc_extended

Status update on technical tasks and code review

• Topic moved to next Thursday meeting (11/10/2022)