Explicit Representation of Working from Home

[joecastiglione]

ActivitySim simulates telecommuters by increasing the probability of workers who are likely to telecommute to have a “non-mandatory” or “home” daily activity pattern, which then results in these persons not generating a mandatory tour (i.e., not traveling to work). While sufficient for many telecommuting analyses, this approach has important shortcomings, including: it does not identify telecommuters in the simulation, which reduces analysts ability to assess the sub-regional impact of telecommuting; it conflates the behavior of workers who do not travel to work due to vacation or illness with telecommuters, which will likely underestimate the travel telecommuters engage in when working from home; and it prevents the use of a “telecommuter” flag to be used in downstream models to impact the behavior of those telecommuting on the simulation day (instead relying on telecommuting frequency, which conflates possible and actual telecommuting behavior). With Version 1.5, telecommuters will be explicitly identified in the simulation and will explicitly engage in a work activity on the simulation day.

[jfdman]

One of the issues with just modeling telecommuting on a given day rather than telecommute frequency - workers who telecommute just one day per week behave differently than workers who telecommute 3-4 days per week. Workers who telecommute just one day per week tend to save up non-mandatory travel for their telecommute days. Workers who telecommute multiple days per week are much more likely to work a full day at home. This is reflected in the telecommute frequency coefficients in the coordinated daily activity pattern model. Any approach that models telecommute on the simulation day should still take into account telecommute frequency.

[i-am-sijia]

Hi Joel, the proposed approach will still have telecommute frequency as one of the long term models. What's different is that when modeling the choices on a simulation day, an explicit telecommuting model can be added e.g., after CDAP. Telecommuting on a given day (explicit telecommuting) will be dependent on the telecommute frequency.

I'm attaching the telecommuting slides I presented at the 2023 ITAP conference Improving the Representation of Telecommuting in Activity-Based Travel Models.pdf. The abstract below explains what the ActivitySim-type of telecommuting models lack, and the telecommuting improvements we made for Ohio DOT.

---

A key shortcoming of telecommuting representations in implemented activity-based travel models (ABMs) is that the formulations do not simulate workers working at home. Both ActivitySim and the initial CT-RAMP2 platforms include a telecommute frequency model that then informs the daily activity pattern model (i.e., mandatory, non-mandatory, or stay-at-home pattern). Workers with a higher telecommute frequency or working from home exclusively are less likely to generate a work tour. This assumption has several shortcomings, including: ● It misstates the “rebound” effect of telecommuting, as telecommuters’ non-mandatory activities are not constrained in the simulation by the need to work while at home. Because telecommuters are not working, the results are not realistic, which calls into question the model’s validity. ● It does not facilitate the analysis of the behavior of telecommuters vs. non-telecommuters because it does not explicitly identify telecommuters in the simulation (i.e., the models are silent as to why a worker is not working on the simulation day).

A step towards improving the representation of telecommuting is the subject of this paper. Specifically, the CT-RAMP2 model implemented for large MPOs in Ohio was modified, calibrated, and tested with the following key modifications: ● Telecommuters are explicitly represented in the simulation via a simple choice model that acts on the existing telecommute frequency model, allowing for their analysis. ● Workers working exclusively at home are just as likely to have a mandatory activity pattern (rather than a non-mandatory or at-home pattern) as workers working exclusively outside the home. ● Telecommuters have a mandatory activity pattern and therefore engage in a mandatory tour. The destination for the mandatory tour is the home location. ● Telecommuters are allowed to make stops on the mandatory tours to their at-home workplaces, which allows escorting and grocery shopping to occur at the beginning or end of the workday. This allows us to leverage the activity-scheduling intelligence of CT-RAMP2. ● In CT-RAMP2’s combinatorial mode choice model, telecommuting movements from home to the home-based workplace are tagged as a cost-free telecommuting mode and not assigned to the transportation network. This allows us to leverage the mode choice intelligence of CT-RAMP2 while representing telecommuting accurately. ● A calibration constant in the choice models is exposed to the user allowing easy adjustment of the telecommuting shares in response to dynamic post-pandemic conditions and future scenario testing. These shares are sensitive to the worker’s industry. (i.e., retail workers are much less likely to telecommute.)

The approach described above is a second-best solution. A first best solution would be a broader move to a truer “activity-based” formulation than those currently used in practice. Such an approach would first create a work activity and then locate it (either at home or at the usual workplace). The approach discussed here was simpler but was implemented quickly and responded to Ohio DOT agency needs motivated by the COVID pandemic. This approach is, to the authors’ knowledge, the first time a practical travel model includes an explicit representation of telecommuters engaged in working while at home.

---

[jfdman]

@i-am-sijia I am simply stating that modeling telecommuter's travel patterns (on the telecommute day) should take into account the frequency of telecommuting, because workers who telecommute only once per week have different travel patterns (on the days they telecommute) than workers who telecommute very frequently. People who telecommute one day per week tend to save up non-work travel for their telecommute day - hair/dr. appointments, personal business, shopping. People who telecommute multiple days per week are less likely to generate non-work travel on any given telecommute day. I don't think the Ohio work took that into account; it only converts the telecommute frequency into a probability that the worker telecommutes or not on the simulation day. Once the conversion is done, the telecommute frequency does not affect the frequency of non-work travel. The current ActivitySim approach does take that into account; the telecommute frequency is the explanatory variable in both the likelihood of generating a work activity as well as the generation of non-work travel (thus I don't think the "rebound" claim stated above is accurate, though that wasn't my original point).

I think there are other aspects of this that need careful consideration as well - ActivitySim currently schedules both activity and travel episodes together, surveys tend to be not very good at collecting in-home activity participation and timing, etc. But my initial point was that whatever form this takes needs to consider the frequency of telecommuting in the generation of travel patterns on the telecommute day in order for the model to maintain sensitivity to this important variable and explain differences between pre-and-post pandemic travel behavior.

[i-am-sijia]

@jfdman This is not an either-or situation - having explicit telecommuting does not diminish the need and use of telecommute frequency. Your initial comment made me believe that you thought we got rid of telecommute frequency, hence my last response. I agree with you it is reasonable for infrequent telecommuters to change their schedule on the telecommute day to accommodate perhaps more non-work travel. But to simulate this, you need both telecommute frequency and whether or not they are telecommuting on the simulation day. In Ohio, we have added the latter, which is a necessary pre-condition for representing the behavior you describe, setting the stage for subsequent model updates.