Project Meeting 2022.07.26

Agenda

• Visitor model and disaggregate accessibilities models (RSG): consortium_update_7-26-2022.pptx
• Update on plan for addressing memory usage

Meeting Notes

Visitor Model

• Similar to cross border model
• Convert from CTRAMP to ActivitySim
• Visitor model tour enumeration
  • Generate parties
  • Simulate tour types and features
• Preliminary results show similar results between CT-RAMP and Activity Sim
  • Exceptions: potentially inconsistent utilities in mode choice (tour and trip levels)
• Run time is about 5 minutes

Disaggregate Accessibilities

• Current Progress
  • Complete: generate a user-defined proto-population
  • Currently working on running ASIM models and extracting the logsums
• How to run
  • Added new component is “compute_disaggregate_accessibilities”
    • Should this replace the compute_accessibilities or keep as a separate option?
  • Created a new module, python script
    • New class called ProtoPop
      • Data frames that are injected into the pipeline
      • These get annotated
    • New function that runs the mandatory and non-mandatory destination choice to extract logsums
  • Disaggregate_accessibilities.yaml
    • Define variables for segments of proto pop
    • Map fields option, if you want to map a variable 1:1
    • Annotation options/specs, currently working on this
• Next steps
  • Finalize logsum extraction (still need to do non-mandatory destination)
  • Develop efficient pipeline handling
• Challenges - Need to make sure it disaggregate accessibility outputs don't overwrite actual model results. Possible solution is to run a whole separate pipeline and feed back into main model. Soliciting feedback from the group: Put it back into the pipeline and keep separate?
  • More resource efficient to use same pipeline, but there are so many hard-codes that it would be difficult to implement
  • Should there be concerns about resource efficiency? There might not be much overhead since the proto pop is small, it might not add too much time/memory requirements. Accessing skims might be the one exception to this.
  • Worried about messing with too much of ActivitySim’s code.
  • Separate pipeline makes sense because it is like a mini ActivitySim that has a separate purpose.
  • RSG originally proposed/intended to make minimal changes to ActivitySim’s code.
• Option 1: create a new table of disaggregate accessibilities to be put into the data pipeline, a completely separate subprocess to generate that table
  • If it’s a subprocess, it can be called by settings.yaml
  • Close the pipeline and only keep what’s needed when it’s done, to keep resources low. Merge the results with the actual synthetic population to run ActivitySim.
  • Write outputs to disk and then read in when you go back to the main process
  • If it’s done this way, then it’s more difficult to run separately
• Option 2: If the idea is to run the model once and be done (more often than running through multiple iterations), having it live as a totally separate tool (run from a command line, separate from ActivitySim)
  • This approach leaves ActivitySim alone
• !! Consensus to go with Option 2 !!

Memory Concerns

• The context of this discuss stems from the previous meeting (July 21), whether or not to hold off on sharrow runtime and memory comparisons to the legacy model, make data type changes to the skims/processing in the legacy model to speed it up.
• WSP proposes, before we dive into a solution, systematically explore where are the memory peaks and what are causing them. It’s not skims alone. They would produce a memo that summarizes their assessment and then present the consortium with potential solutions.
• Group to make consensus decision on best solution, revisit this topic next meeting.
• Note that WSP only has 8 hours left in their general support budget, and this is what they can do with that budget.