Within tour_frequency.py and joint_tour_destination.py, the non-mandatory tour types are hard-coded within the code.
While the ARC model does use the same tour types as MTC, they are implemented slightly differently. The ARC implementation shares the same tour mode choice coefficients across all non-mandatory tour types.
To get the ARC implementation to work, we had to duplicate the coefficients for each tour type. This is probably a good practice in the long-run, but its easy to imagine the hard-coded non-mandatory tour types being a constraining feature for other ABMs with different needs.
It looks like @toliwaga put some statements in the code to come back to this at some point. While we have a work around for ARC, this would be good to fix before moving a model into production.
The code could either interpret the non-mandatory tour types from the tour_frequency spec or tour_destination spec. Perhaps even better would to define it explicitly in the settings.yaml file and then check the specs all agree with the settings.yaml definition.
| non_mandatory_tour_flavors= {'escort': 2+MAX_EXTENSION, |
| 'shopping': 1+MAX_EXTENSION, |
| 'othmaint': 1+MAX_EXTENSION, |
| 'othdiscr': 1+MAX_EXTENSION, |
| 'eatout': 1+MAX_EXTENSION, |
| 'social': 1+MAX_EXTENSION} |
| non_mandatory_channels=enumerate_tour_types(non_mandatory_tour_flavors) |
| |
| # - mandatory_channels |
| mandatory_tour_flavors= {'work': 2, 'school': 2} |
| mandatory_channels=enumerate_tour_types(mandatory_tour_flavors) |
| |
| # - atwork_subtour_channels |
| # we need to distinguish between subtours of different work tours |
| # (e.g. eat1_1 is eat subtour for parent work tour 1 and eat1_2 is for work tour 2) |
| atwork_subtour_flavors= {'eat': 1, 'business': 2, 'maint': 1} |
| atwork_subtour_channels=enumerate_tour_types(atwork_subtour_flavors) |
| max_work_tours=mandatory_tour_flavors['work'] |
| atwork_subtour_channels= ['%s_%s'% (c, i+1) |
| forcinatwork_subtour_channels |
| foriinrange(max_work_tours)] |
| |
| # - joint_tour_channels |
| joint_tour_flavors= {'shopping': 2, 'othmaint': 2, 'othdiscr': 2, 'eatout': 2, 'social': 2} |
| joint_tour_channels=enumerate_tour_types(joint_tour_flavors) |
| joint_tour_channels= ['j_%s'%cforcinjoint_tour_channels] |
| # list of tour_types in order that doesn't change across the 3 joint_tour_destination models |
| # so that choices remain aligned with chooser rows. |
| # save space by using int8 not str to identify school type in sample df |
| TOUR_TYPE_ID=OrderedDict([ |
| # ('escort', 1), |
| ('shopping', 2), |
| ('othmaint', 3), |
| ('othdiscr', 4), |
| ('eatout', 5), |
| ('social', 6) |
| ]) |
Within tour_frequency.py and joint_tour_destination.py, the non-mandatory tour types are hard-coded within the code.
While the ARC model does use the same tour types as MTC, they are implemented slightly differently. The ARC implementation shares the same tour mode choice coefficients across all non-mandatory tour types.
To get the ARC implementation to work, we had to duplicate the coefficients for each tour type. This is probably a good practice in the long-run, but its easy to imagine the hard-coded non-mandatory tour types being a constraining feature for other ABMs with different needs.
It looks like @toliwaga put some statements in the code to come back to this at some point. While we have a work around for ARC, this would be good to fix before moving a model into production.
The code could either interpret the non-mandatory tour types from the tour_frequency spec or tour_destination spec. Perhaps even better would to define it explicitly in the settings.yaml file and then check the specs all agree with the settings.yaml definition.
activitysim/activitysim/abm/models/util/tour_frequency.py
Lines 46 to 71 in 7b57c94
activitysim/activitysim/abm/models/joint_tour_destination.py
Lines 37 to 47 in 7b57c94