SEMCOG Model taking longer to run using ActivitySim 1.3.1 with Sharrow Disabled Comparing to using ActivitySim 1.2.0

[JilanChen]

Describe the bug

The SEMCOG model (10%, single process) takes longer to run with the official 1.3.1- Sharrow-Off (203 minutes) than with the previous 1.2.0 version (175 minutes). Key models taking longer: workplace location, non-mandatory tour scheduling, tour mode choice, and trip destination.

This issue has been reported as part of #864. While the workplace_Location run time issue related to the 1.3 Beta - Sharrow-On resolved with the official release of 1.3.1, the longer run time issue in a few models of 1.3.1 - Sharrow-Off still remains.

Screenshots
Reported run time in minutes - ActivitySim.log

[AndrewTheTM]

MWCOG's model is faster with 1.31 compared to 1.21. No sharrow, 1.31 is in explicit chunking (1.21 is uses regular chunking). The image below shows that 1.31 is significantly faster with vehicle type choice, joint tour models, and writing matrices; 1.31 is a little slower in trip destination.

Of the steps called out by Jilan:
Workplace location is 30 seconds slower in 1.31
NM tour sched is 7 minutes faster in 1.31
Tour mode choice is the same time
Trip destination is 9 minutes slower in 1.31.

cc: @xiex0055 @ray-ngo

[AndrewTheTM]

This is Metropolitan Council's. Similar to MWCOG, the overall is faster (226.7 with Asim 1.2 down to 196.8 with Asim 1.3.1. Almost every step either the same or faster with the exception of work location choice and school location. School location is slightly slower (4.2 to 4.5 minutes) and work location choice is MUCH slower (14.2 minutes to 43.1 minutes). I may be able to speed this up (I was able to get the speed down to ~14 minutes by commenting out some calibration adjustments... there's some easy ways to improve that).

cc: @dvfarmer

[AndrewTheTM]

Update on Met Council:

With work location choice having slowed significantly, from 1.2 to 1.3, I commented out the calibration adjustments and found that the step would run in comparable times.

The old UEC lines looked like this:

@(df.home_dist.isin([6, 7, 11, 12, 13, 14, 17, 18, 19])) & (_DISTRICT.isin([1, 2, 3, 4, 5, 15, 20, 21, 22]))

I ultimately created another variable in annotate_households (and annotate_persons_after_hh) to simplify the districts to the four districts I'm using (based on river crossings - the Mississippi, Missouri, Minnesota, and St. Croix rivers). I did the same on the _DISTRICT side (it's a pre-model script to build a matrix file). The current code is this (and a few more like it) and runs much faster:

@(df.home_wlc_dist == 1) & (_DISTRICT==2)

Now it's down to 169.6 minutes (1.3.1) from 226.7 minutes (1.2).

[jfdman]

Just pointing out that data like this is not appropriate for line charts which imply ordered values on the x-axis. a bar chart might be more appropriate but I think it would be even better to just see the times in minutes,

[ray-ngo]

Thanks, @AndrewTheTM! Do you know why trip destination takes longer with ActivitySim 1.3.1 compared to ActivitySim 1.2 for MWCOG's model, while the opposite is true for Met Council's model?

I also noticed a significant improvement in the runtime of the write_trip_matrices step in Met Council's model compared to MWCOG's and SEMCOG's models. Were any changes made to this step of Met Council's model?

[AndrewTheTM]

@ray-ngo Regarding trip destination I think it's probably the calibration adjustments (the last three lines of the spec). There's a lot of comparison items there that may be causing it to slow. These might be able to be moved to the preprocessor.

On writing the matrices, I didn't do anything different with Met Council for 1.3 that wasn't already done for 1.2. I don't know why there was such an improvement in their matrix writing step compared to yours.