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.
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)