Preliminary results show similar results between CT-RAMP and Activity Sim
Exceptions: potentially inconsistent utilities in mode choice (tour and trip levels)
Run time is about 5 minutes
Disaggregate Accessibilities
Current Progress
Complete: generate a user-defined proto-population
Currently working on running ASIM models and extracting the logsums
How to run
Added new component is “compute_disaggregate_accessibilities”
Should this replace the compute_accessibilities or keep as a separate option?
Created a new module, python script
New class called ProtoPop
Data frames that are injected into the pipeline
These get annotated
New function that runs the mandatory and non-mandatory destination choice to extract logsums
Disaggregate_accessibilities.yaml
Define variables for segments of proto pop
Map fields option, if you want to map a variable 1:1
Annotation options/specs, currently working on this
Next steps
Finalize logsum extraction (still need to do non-mandatory destination)
Develop efficient pipeline handling
Challenges - Need to make sure it disaggregate accessibility outputs don't overwrite actual model results. Possible solution is to run a whole separate pipeline and feed back into main model. Soliciting feedback from the group: Put it back into the pipeline and keep separate?
More resource efficient to use same pipeline, but there are so many hard-codes that it would be difficult to implement
Should there be concerns about resource efficiency? There might not be much overhead since the proto pop is small, it might not add too much time/memory requirements. Accessing skims might be the one exception to this.
Worried about messing with too much of ActivitySim’s code.
Separate pipeline makes sense because it is like a mini ActivitySim that has a separate purpose.
RSG originally proposed/intended to make minimal changes to ActivitySim’s code.
Option 1: create a new table of disaggregate accessibilities to be put into the data pipeline, a completely separate subprocess to generate that table
If it’s a subprocess, it can be called by settings.yaml
Close the pipeline and only keep what’s needed when it’s done, to keep resources low. Merge the results with the actual synthetic population to run ActivitySim.
Write outputs to disk and then read in when you go back to the main process
If it’s done this way, then it’s more difficult to run separately
Option 2: If the idea is to run the model once and be done (more often than running through multiple iterations), having it live as a totally separate tool (run from a command line, separate from ActivitySim)
This approach leaves ActivitySim alone
!! Consensus to go with Option 2 !!
Memory Concerns
The context of this discuss stems from the previous meeting (July 21), whether or not to hold off on sharrow runtime and memory comparisons to the legacy model, make data type changes to the skims/processing in the legacy model to speed it up.
WSP proposes, before we dive into a solution, systematically explore where are the memory peaks and what are causing them. It’s not skims alone. They would produce a memo that summarizes their assessment and then present the consortium with potential solutions.
Group to make consensus decision on best solution, revisit this topic next meeting.
Note that WSP only has 8 hours left in their general support budget, and this is what they can do with that budget.