Extension of Vehicle Type Model to Include AVs

[dhensle]

RSG is extending ActivitySim to consider autonomous vehicles (AVs) for consortium partners MWCOG and SANDAG. One implementation option is to treat AV's as an extension of body type in the vehicle type model. e.g. car would be split into car and car_av. This new body type would just have to be included in the vehicle type data file and would require minimal code changes.

When including a new body type in the vehicle type data file, there is a check to make sure the vehicle type data exists for every alternative. This was a design decision to make sure the user assembling the vehicle type data file didn't miss any alternatives, especially when extending to future years. However, this results in a set of alternatives in the base-year that is more than twice as big as it needs to be, because there are alternatives for vehicles that did not exist in previous years (Hybrids, PEVs, HEVs). Though these alternatives are unavailable they still more than double the amount of RAM required for running the model.

Extending the body type to include AVs would again double the number of alternatives required, resulting in 4x the amount of RAM required for the model in the base-year, and more than double the necessary amount of RAM for future year files since there are many combinations of AV and fuel type that are not necessary.

We propose either putting a switch in the model yaml to distinguish between two options:

1. Strictly enforce that all alternatives have a matching row in the vehicle type data (which is how it currently works)
2. Just remove alternatives from the model that are not supplied with vehicle type data

Or, simply remove the assert statement from the code.

[bettinardi]

I'm curious if this issue exists for both implementations of the vehicle model. I forget what they are called now (we should ensure we have good names), but during construction I believe the two implementations that moved forward were option 4 and 2. Maybe we call them detailed and simplified or something. Anyway, I hope it is the intent to ensure that AV specification works for both options, and I would like to verify whether this issues exists for both options or just option 4 (detailed).

Also, I'm not sure I'm reading this right. Does the little vehicle model really impact the total RAM needed for ActivitySim... Like it needed 128GBs before the vehicle model and now it needs 256GBs... Or is this just saying that the vehicle model needed a GB of RAM and now it needs 2 or 4 GBs... Can you please verify the scale of this problem? If the vehicle model is doubling the total RAM overhead (hundreds of GBs), that is a significant design flaw and needs to go back to the design table (would be completely unacceptable).

[wusun2]

Removing the assert statement would relax the requirement that all vehicle type data must exist for every alternative? If so, would removing the assert statement resolve the negative memory impact? What is the downside of removing the assert statement?

[dhensle]

This issue does not apply directly to the option that uses probabilities to determine the fuel type because that option does not use the vehicle type data. The number of alternatives supplied to the model in that case is greatly reduced because the fuel type segmentation has been removed. There is a separate assert statement for this implementation that states that every combination of body type and age needs to be included in the fuel type probabilities file -- which I think is still necessary.

The vehicle type model does not require as much RAM as other models. This is due to the operation being performed only on a table of max length of the number of households (which is much less than tours or trips). However, there's no use hogging computational resources (RAM or CPU) for alternatives that will never be chosen.

Removing the assert statement would relax the requirement that all vehicle type data must exist for every alternative? If so, would removing the assert statement resolve the negative memory impact? What is the downside of removing the assert statement?

Yes, removing the assert statement would mean that if no vehicle type data existed for an alternative, that alternative would be removed from the choice set. By reducing the choice set, we reduce the computational resources to solve the problem.

The downside is that the user would not have an independent check on whether their vehicle type data file is consistent with the alternatives in the model. Ensuring consistency here was why the assert statement was included in the first place.

[dhensle]

This feature has been completed. The associated spec files can be found in the sandag abm3 example: https://github.com/ActivitySim/sandag-abm3-example/blob/main/configs/resident/vehicle_type_choice.yaml#L42