Project Meeting 2022.04.19

Agenda

• Sharrow progress update
• Draft disaggregate accessibilities implementation plan

Action Items / Next Steps

• Comments on Disaggregate Accessibilities Implementation Plan are due by Friday, April 22, 2022.
• Presentations on state of the practice/best practices on refactoring/model design. Suggestions for presentations by Jim Hick for CT-RAMP2s and Emme Agent.
• Potentially schedule an in-person charrette to determine what it is that we want (in terms of model design).

Disaggregate Accessibilities

• Proposed implementation plan document shared with the group, includes the following information
  • Process includes building prototypical synthetic population and tours and trips, running through mode choice
  • How it would be implemented in the code
  • How it would be merged with the actual synthetic population
  • How it would be incorporated into the model
• Waiting for all the comments to come in, by the end of the week, to send out an updated draft
  • Will be adding a flow chart per Alex’s suggestion
• Question about why there are o accessibilities for school or university
  • Those logsums are typically used in origin/destination which are already handled by the code pretty well for these types of travel.
  • Included work logsum included because it’s could be used for User Benefits, or integration with Land Use, but probably wouldn’t be used much in the actual model system.

Performance Enhancements

• Visualizations of comparisons of run time

  • Specified in a .yaml file
  • Can produce reports in an html
  • Issues in the workflow that relate to the issues that we’ve discussed before related to modularity
  • This proposed workflow change is made to better test the system but more so that we can break it apart more easily (testing is another great reason but not the only reason)

• Question about type, extent, level of effort for such a proposal? How it relates to other work program items that we’ve already done, etc?

  • Jeff says it’s a fairly big effort. Much more that 0-40k type effort. Large undertaking to rewrite a lot of ActivitySim code.
  • What would stay the same: how you interface with ActivitySim, might have a workflow file that looks like the .yaml file Jeff presented and less like the 14 lines of code that specifies the 14 models to run. It would provide a little more detail about what goes in and goes out of each model.
  • Wouldn’t necessarily need to list every variable that are being used in each model, that can be pulled from the UECs, which is similar to what sharrow is already doing.

• Discussion turned to how ActivitySim might be restructured/refactored. Many agree that it is worthwhile but a huge effort that needs to be very intentional

  • Be intentional about the redesign – understand implications, what others are doing, and clearly map out what would be done
  • Develop a refactor design document. Maybe spend some of the Phase 7 code review/consultant hours to specify that “version 2” design document.
  • Then fund it, once there’s agreement on what to do

Other

Github Discussions: https://docs.github.com/en/enterprise-cloud@latest/discussions

• Discussion forum – could be useful to ask questions related to implementation that aren’t necessarily software issues
• This feature has been activated and available for testing.
• We'll leave it open for a while and then assess whether it's a helpful feature or another place to maintain that's not as helpful.