Plan was to use off-the-shelf sparse processes as much as possible, use some standard sparse libraries from python to handle some of the data mgmt, and not do custom things too much. However, some new code needed.
Attach the sparse data into the array by using the redirection toolkit and use the sparse_blender code (identical to way ActivitySim is doing it today)
The redirection toolkit automatically creates a digitization of the MAZ-to-TAZ relationship, which is the offset position of the TAZ positions for the MAZs (origin and destination copies, respectively)
Additional array(s) include the sparse version of any attached skim (_s_...), using a generalized compressed spare array (GCXS), which also the data to be stored in an efficient way, based on the sparse package from the PyData family of tools.
Trips or tours are bound together with the skims into a DataTree, the same way as when using dense-only (i.e. 1-zone) skims.
Setting the blending distance – anything above that is coming directly from dense skims, and anything below that would be a blended mix of the sparse and dense values, mimicking the current ActivitySim approach.
Users would want to pick a blending distance that’s consistent with the sparse data.
Compiling includes the mapping and the blending – all that lookup math is in the compiled code.
This is not fully implemented with the MTC 2-zone example, yet.
Technical subcommittee update
First topic was to discuss approach to ActivitySim components and whether updates should be a new component or a switch.
Not much more resolution than the larger group in making a decision but there have been some good discussions.
They have broken things down to understand the differences between what’s best from the perspective of a developer versus a standard user.
Recognition that the group is mostly developers and they solicited for input/perspective from the users' side.
Next time, the group wants to come back to the larger group with something for them to react to.