-
Notifications
You must be signed in to change notification settings - Fork 96
Telecommute
This plan is for a person level telecommute model that will be developed in cooperation with SEMCOG. See Phase 6a Task 3 for more information on the task scope.
Telecommuting is defined as workers who work from home instead of going to work. It only applies to workers with a regular workplace outside of home.
The purpose of the model is to represent effects of telecommute program participation on model outcomes, to test implications of changes in telecommute program availability and participation, to account for likelihood of different worker characteristics, to model COVID and post-COVID scenarios, and to test telecommute program participation versus telecommuting on simulation day.
The telecommute model consists of two submodels - a person work from home model and a person telecommute frequency model.
- The work from home model would be run after usual work/school location choice and before the coordinated daily activity pattern (CDAP) model. It predicts for all workers whether they usually work from home.
- For all workers that work out of the home, the telecommute models predicts the level of telecommuting. The model alternatives are the frequency of telecommuting in days per week (0 days, 1 day, 2 to 3 days, 4+ days).
Explanatory variables include household and person level variables, including employment categories, sex, age, presence of children, industry/occupation, auto ownership and variables associated with accessibility to work, such as the mode choice logsum and parking costs.
With a person telecommute frequency variable now available to the system, several of the downstream models can be updated to include sensitivity. The downstream models that will be updated are the CDAP model, the Individual Non-Mandatory Tour Frequency Model, and the Non-Mandatory Tour Stop Frequency Model. The results of these models are all improved with an awareness of person telecommute frequency, and other models can be updated as well if desired by simply referencing the new person variable in the expressions.
The model design is largely inspired by the SANDAG model design, see the telework methodology starting on page 10 of the SANDAG ABM2+ Enhancements to support 2021 RTP (2020) and the telework testing starting on page 74 of the SANDAG ABM2+ Sensitivity Testing Report (2020). The model design was also inspired by the MAG telecommute model, which was specifically developed to address COVID scenarios and is sensitive to employment status, industry/occupation, distance to work, age, income, gender, and presence of young children in the household.
More information on the model design is in Joel's proposed design presentation.
Beyond the typical data required to estimate an ABM, person industry/occupation is also needed since these are key determinants of telecommuting. This data is not always available in a household travel survey, or not disaggregate enough, and so its optional. It is of course preferred to have this information in the synthetic population, but if it is not available, then it can be also be omitted from the model expression files.
- Should we include person occupation and work industry since these are key determinants of telecommuting but not in every synthetic population?
- Probably yes since the code should work in either case - with or without these additional person table columns
- Should we revise the usual work location model to include work from home or add a separate submodel for work from home?
- We decided to add a person work_from_home submodel after work location choice that makes use of the already output work_location_choice_mode_choice_logsum for the accessibility measures, which also overrides the work_zone field since it is no longer valid. This is cleaner since it separates the work from home model from the work location model, which has benefits for shadow pricing, estimation, model design flexibility, and software implementation flexibility.
- Can we make it any easier for the user to do what-if analysis? Maybe some kind of smart constant calculator for target telecommute shares or something like that? We decided to add this to the issues for a potential future improvement since it's principally about automating calculating smart constants rather than manually coding them, which is what is currently supported by the existing ActivitySim core.