Table of Contents

Overview

This document will walk you through the steps of setting up your programming environment, going through the interfaces that GTAModel exposes for interfacing in new modules, and going through some examples of modules designed for GTAModel.

This document will assume that you are familiar with the C# and the .Net Framework.

Programming Environment

To start programming custom modules for XTMF you will need to setup your environment you can click here for documentation regarding how to setup your programming environment and create your first modules for XTMF.

In addition to the standard XTMF interfaces you will also need to add references to TashaInterfaces.dll in your custom module library project to access the interfaces designed specifically for GTAModel.

Example Code

The following items are small tutorials that go over implementing common interfaces. A full list of interfaces can be found in the following section.

  • Counting Activities - This example will walk you through writing a new module using the IPostHousehold interface. It will execute at the after GTAModel has finished processing each household through the scheduler and mode choice algorithms allowing keeping track of how each activity type was generated by the scheduler.
  • New Mode - This example will walk you through the process of creating a new mode for GTAModel's mode choice algorithm. In for this example, we will implement a model for a teleporter.

GTAModel Interfaces

Beyond the standard interfaces for XTMF you will also be able to implement modules for integration below. The High Level Interfaces will let you access data while TASHA streams through, or implement your own scheduler and mode choice from scratch.

High Level Iterfaces

The following interfaces are used for integrating into TASHA's processing pipeline, or in one case re-implementing that pipeline without breaking compatability with other modules.

  • IAccessStationChoiceModel - Using this interface you can implement a new access station choice model and integrate it into the current Drive-Access-Transit model.

  • ILocationChoiceModel - Using this interface you can implement a new location choice model for TASHA. This module is responsible for picking discrete the destinations for other, market, and work-based-business activities when constructing the schedule.

  • IParkingCost - This interface is extended to implement a new model for computing parking costs given the gap between two activities.

  • IPostHousehold - This interface executes after the scheduler and mode choice have finished executing each household.

  • IPostIteration - This interface executes after all households have been processed through the scheduler and mode choice.

  • IPostScheduler - This interface executes after the scheduler has finished each household but before mode choice has executed.

  • IPreIteration - This interface executes before any household has been processed for the current outer-loop.

  • ITashaMode - This interface is extended to implement a new mode that can be chosen by TASHA.

  • ITashaModeChoice - This interface provides interopability for the ITashaRuntime to use different mode choice algorithms.

  • ITashaRuntime - This interface provides interopability for modules to target a generic TASHA interface without binding to a particular implementation. Though unexpected, this could be replaced to modify/extend the standard workflow of TASHA.

  • ITashaScheduler - This interface provides interopability for switching between different scheduler implementations for TASHA.

  • IPostHouseholdIteration - Using this interface you can implement a module that runs after the mode choice has finished processing a single mode choice iteration through the household. This allows you to see the combination of modes, access choice data, and other extremely detailed data that is recycled between the iterations of mode choice.

  • ITourDependentMode - This interface allows you to implement a mode where the utility of a trip using this mode changes depending on the tours composition. An example of this is the Drive Access Choice model where the utility of that mode requires the knowledge of both the access and egress portions of the tour.