Project Meeting 2023.05.04

Agenda

• Admin
• Status Update on Current Tasks

Meeting Notes

Replace Orca (CS)

• #654 Ready for review.

New Data Pipeline File Format (CS)

• Reviewed, incorporated into #654

Configuration Documentation & Input Checking (CS)

• Started framework to get all the pieces that are pretty common (such as logsums, tracing options, etc) into building blocks. Then, the individual model documentation can be turned around relatively efficiently.
  • Building blocks
  • Free Parking

Component Documentation (CS)

• A lot of the pieces are generated with the config documentation discussed
  • Free Parking

User's Guide (CS)

• Not started.

Input Data Checker (RSG)

• Presentation: input_checker_pt3_pydantic.pptx • RSG provided an overview of how the input checker would work with a data model / pydantic process under the hood.
• Pros/Cons of Input Checker as it was originally envisioned • Pros
  • Adheres to ActivitySim paradigm
  • Simple to edit and change expressions
  • Familiar to agencies which use it already
  • Already have working functionality
  • Input checker would be more easily adaptable to checking files outside of ActivitySim (networks, for example). It would take more work to incorporate that into the data model approach. It’s more likely that we’ll need to check networks than synthetic populations, for example. Populations tend to be pretty stable, in application. • Skims would be important to check. Original proposal included some numpy expressions to check skims and not sure how that would work under the data model approach. • Cons
  • No connection to data model
  • A little less flexibility in writing python expressions - you’d have to write the whole expression in one line.
• Pros/Cons of Input Checker that would work with a data model / pydantic process • Pros
  • Better integration with data model
  • Data checking handled “automatically”
  • Ensures consistency between data model and input data • Cons
  • Less user friendly
  • Have to code python - however, you could utilize tools/libraries that are already available, instead of having to write all the expressions and would take a lot of time.
  • Files wouldn’t follow the traditional ActivitySim model structure
  • Input checker wouldn’t instantly check everything. It would crash as soon as it failed, instead of checking everything. You could get around that with some custom code and have it capture validation errors.
• Other Considerations • We need to consider performance, at the scale of actual implementation. • Sharrow could be integrated into either approach. The data model/pydantic approach doesn’t change what the data is and how we would want to store it. • Need to consider the balance between easy of development and user-friendliness (outside of developers)