Project Meeting 2023.10.31

Agenda

Component Documentation
Circle back regarding testing (and testing budget) in Phase 9. Open pull request back into ActivitySim for review? Decisions to be made include:
- What should be included in CI testing?
- Should improvements be generalized, or should we wait for Phase 9? Enhancements, thus far, have been made to keep SANDAG moving.
- What additions should be kept for, for example, external models that aren’t part of the ActivitySim code base?

Reference Jeff’s list of code changes.
- Green: Done
- Yellow: Partially/mostly done by staff at CS. Requires second set of eyes, as well, before pushed out.
- Red: Have been looked at; Complex. Jeff to work on.
- No color: Not complete.
Documentation of Components
- Each component has its own page:
  - Definition,
  - Structure,
  - Configuration,
  - Links to examples, and
  - Implementation
A bug exists in one of Activity Sim’s dependencies - not rendering properly. Needs correct version of dependencies to do so. Jeff to de-bug.
As far as design decisions, not much to discuss. Not changing how ActivitySim works, or changing how users interact with it.
Bug found in school escorting model:
- If PERSON_WEIGHT is not defined, then the values used for the gender_weight will equal person weight and the values used for age_weight will equal gender_weight.
- Additionally, issues with global settings for number of escortees (NUM_ESCORTEES) and number of chaperones (NUM_CHAPERONES).
Optional within the component documentation scope are recommended optional sections: Context variables, additional related functions, etc. Some have been added in the documentation of individual components.
Wrapping Up
- Approximately 2-3 weeks before all code changes and component configuration is complete.
- Anyone from partnering agencies may start reviewing code by poking around.

The school escorting model is not the single point of concern, as far as ActivtySim goes. Bad inputs are not tested much within ActivitySim, overall. This leads to discussion regarding testing effort to ease out some of ActivitySim’s bugs…
Moving towards unit testing (providing inputs and settings that vary) will allow us to cover all bases.
Q: Does it make sense, long term, to include all settings in one place?
- A: Documentation is key. However, as time goes on, more settings and configurations will be added. Having everything in one place will force users to continue updates. We should be able to run ActivitySim without one comprehensive list of every possible setting.
The testing world is vast. What type of testing is necessary? Are we able to reference a comparable project to indicate a direction?
- Additionally, how do we manage contributions to the testing effort? What is the consortium’s responsibility in this particular instance?