Project Meeting 2023.03.21

Agenda

• Update on initial interview
• Review of outstanding issues

Meeting Notes

Update on initial interviews

• Presentation - activitysim-roadmap-wip-22-mar-2023.pdf
• Provided list of initial interviewees, schedule, and early feedback on the process
• Reflections
  • Scheduling challenges
  • Sending topics in advance was helpful to interviewees
  • Too early to report any themes
  • Consensus reached that WSP should continue current approach
  • Non-consortium interviews have been very helpful
    • Marty and Ben’s perspectives and ideas were very different
    • Up to 6 sounds like a reasonable number of non-consortium interviewees
  • Check back in in about 2 weeks with feedback from interviews to date
• Establish 3 visions (inward facing)
  • Objectives
    • The objectives will set the roadmap to those visions, which would include the product and project management, for example.
    • Currently working on 9-10 objectives that WSP can present at a future update.
  • Behavioral representations
  • Software

Issues Review

• Issue 640: maz_to_maz tables potentially cause duplicate index key error in los.py when using zero-based zone_id setting
  • Issue related to some original code that was developed as a hacky solution.
  • Resolving this issue is necessary to keep legacy code functional.
  • Pull request forced 64-bit integer format, but then this fix causes problems later on.
  • Jeff is working on a fix to make this work with/without sharrow, multiprocessing, etc. This hasn’t been resolved yet, but he is working on it. ETA is approximately a week but unsure.
  • Lessons learned: try not to hack things with original code and instead utilize generalized/standard libraries. These tools are used by many other people for various application and leads to more robust solutions instead of building something on our own that just fixes one thing which could break later on under different circumstances.
• Issue 658: home_is_rural appears incorrectly defined in MTC example (and others)
  • This issue led the consortium to consider if they are in the business of building the infrastructure but not validating the details/implementation?
  • Issue created to let others know this is an issue in the example, so they know it’s not necessarily correct.
  • There is likely a simple fix but haven’t landed on or implemented a solution.
  • Implication is that this can vary from region to region.
  • This might be a good example of something that an input checker could address.
  • Next steps: Assign to Lisa this issue
    • Lisa Zorn (MTC) would be willing to investigate if this is an error or not. (ARC’s area types go up to 7 so this could be where the variable came from and it’s not a mistake.)
• Issue 656: tot_tours Hidden in Non-Mandatory Tour Frequency Code
  • This issue is an example of not great programming, where the creation of a variable is buried in the code. Suggestion that this should be moved to be user-defined in the alternatives file by adding a total tours in the alternatives as a new column in the file instead of code that calculates it.
  • This is being computed within the code but there is an opportunity for someone to create a variable that uses that name and then it gets written over. There’s not a process that prevents this.
  • On the flip side, there’s a possibility of user error for someone to not update this field correctly, if moved to alternatives file. *** Next steps**: RSG to make a change, but a solution wasn't established by the end of the meeting. Some considerations included:
    • Suggestion to make the variable more descriptive, not just tot_tours – but that’s more work.
    • Potential for people to not see that there is a change required to the spec file.
    • Make sure this change is included in the Release Notes.
    • Better to make it crash, with a good crash note, so that it forces people to change their spec file to make it compatible with the release.