Agenda

• Discuss a presented Straw Man for an ActivitySim 2.0

Key Decisions, Action Items/Next Steps

• A major refactoring process is not recommended at this time. Maybe after a few years of ActivitySim being deployed and applied in various contexts will help drive consensus on what is working and not working, to better identify the most stable, tested version of the model(s), and then potentially go through a redesign effort.
• Develop a Phase 8+ road map that will guide ActivitySim efforts over the next X-X years.
• Develop a matrix of model features/components for current partners.
• Inventory what is working and not working from developers and partners.

Straw Man 2.0

• Codebase
  • All new ActivitySim codebase, with no promise of backwards compatibility
  • Stateless operation - every input is explicitly passed to every component
  • Immutable PyArrow and Xarray data structures
  • Rigorous unit testing, not just integration testing
• Curated Example Models
  • One (or very few) canonical "Generic" model (drop the "MTC" moniker) that enables feature under the sun
  • One "Intro" model that includes the minimal set of pieces that the smallest, least sophisticated ABM user could find useful
  • One maintenance model per consortium member who chooses to submit one.
• Concerns about the Straw Man approach
• Partners have spent a lot of time and money to get to this point and still don't have a version in application.
• Waiting another X years for a 2.0 version seems like too much additional time.
• Desire to utilize the work done to date.

Further Discussion

• What is the current state of all the implementations/development efforts?
  • Action Item: inventory the state of all the models during in development/application.
• What is Working
  • Many agencies have already started a transition to this new codebase.
  • Building a common, "rock solid" base that is well documented.
• What is not Working
  • Memory usage is very high
  • Not actually that easy to implement an ActivitySim model in a new place
  • End user "usability" and ability to see what's going on inside the model
  • Chunking
  • The relationship between upstream and downstream components
  • Certain components (esp. trip location choice) are so slow
  • Legibility of the code, organization issues
  • In practice, developing a model for implementation is like trying to hit a moving target, difficult when things are constantly in development.
  • Error reporting
• Modularity
  • Try to find a balance between modularity and clarity so that wehn there is a need to modify/insert/delete pieces, it doesn't break the model.
  • Model design/flow considerations as well as software considerations are required.
• Is refactoring/redesign necessary?
  • Focus on use cases. For example, not many agencies need to move to the cloud, Should this be a priority at this time if user's aren't likely to need to utilize all the benefits of refactoring.
  • ActivitySim models haven't been thoroughly tested and put into production yet. We may not have a good sense of what does or doesn't work yet. For example, do we really have a good grasp on two-zone vs three-zone vs one-zone, and what are the costs and benefits? It might be worth resolving these questions before a major redesign effort that might account for features that may not be used in a few years.
  • Focus on principles for building ActivitySim.
    • It wasn’t the intention to build the most sophisticated model.
    • Wanted to be rock solid, reliable, thoroughly tested model where users can learn from and utilize developments/work from others.