clean up docs

.travis.yml

@@ -19,9 +19,9 @@ jobs:
     - env: TEST_SUITE=activitysim/core
 
     - stage: Examples
-      name: "MTC Example"
+      name: "Gondor Example"
       env: TEST_SUITE=activitysim/examples/example_gondor/test
-    - name: "MTC Extended Example"
+    - name: "Arnor Example"
       env: TEST_SUITE=activitysim/examples/example_arnor/test
     - name: "Multizone Example"
       env: TEST_SUITE=activitysim/examples/example_multiple_zone/test

activitysim/examples/example_arnor/README.MD

@@ -1,6 +1,6 @@
 
-### MTC Extended Example
+### Arnor Example
 
-The MTC example with the following additional models:
+The Gondor example with the following additional models:
 * vehicle type model
 * vehicle allocation model

activitysim/examples/example_gondor/README.MD

@@ -1,4 +1,4 @@
 
-### MTC Example
+### Gondor Example
 
 The primary ActivitySim example model.  See https://activitysim.github.io/activitysim for more information.

docs/cli.rst

@@ -15,7 +15,7 @@ Create
 ------
 
 Create an ActivitySim example setup.  See ``activitysim create -h`` for more information.
-More complete examples, including the full scale MTC 
+More complete examples, including the full scale Gondor
 regional demand model are available for creation by typing ``activitysim create -l``.  To create 
 these examples, ActivitySim downloads the large input files from 
 the `ActivitySim resources <https://github.com/rsginc/activitysim_resources>`__ repository.

docs/core.rst

@@ -438,7 +438,7 @@ Configure the Summarize Model
 
 Summary Expressions
 ^^^^^^^^^^^^^^^^^^^
-Example configuration files for the summarize model step (as listed above) are included in MTC example. These files will need to be adjusted to produce customized SimWrapper dashboards. These files are structured as standard ActivitySim expression (CSV) and configuration (YAML) files. More detailed information about configuration of the summarize model step is available in the Models documentation.
+Example configuration files for the summarize model step (as listed above) are included in Gondor example. These files will need to be adjusted to produce customized SimWrapper dashboards. These files are structured as standard ActivitySim expression (CSV) and configuration (YAML) files. More detailed information about configuration of the summarize model step is available in the Models documentation.
 
 You may wish to manipulate the default expression files to suit your particular needs. Expression files are formatted as CSVs and structured according to ActivitySim conventions with three columns:
 
@@ -471,7 +471,7 @@ The ``label_format`` parameter uses f-string formatting to specify how bins shou
 
 By default, bins are labeled with their extents using the following f-string: ``'{left:,.2f} - {right:,.2f}'``. The ``'{rank}'`` option demonstrated above would label each bin with its ordinal rank. Numeric labels are converted to numeric data types, if possible.
 
-Examples of each summarize function are included in the ``summarize.csv`` expression file for the MTC example. Consult the docstrings for each function in the ``/activitysim/abm/models/summarize.py`` module for complete specification of parameters.
+Examples of each summarize function are included in the ``summarize.csv`` expression file for the Gondor example. Consult the docstrings for each function in the ``/activitysim/abm/models/summarize.py`` module for complete specification of parameters.
 
 Preprocessing
 ^^^^^^^^^^^^^
@@ -503,7 +503,7 @@ Binning during the preprocessing stage uses the same convenience functions avail
           - High Income ($75k-$100k)
           - Very High Income (>$100k)
 
-Example uses of each binning function are included in the ``summarize.yaml`` configuration file in the MTC example.
+Example uses of each binning function are included in the ``summarize.yaml`` configuration file in the Gondor example.
 
 Table columns can also be aggregated, or "remapped," during the preprocessing stage. Aggregations are specified in the configuration YAML using a key-value  structure:
 
@@ -538,7 +538,7 @@ Table columns can also be aggregated, or "remapped," during the preprocessing st
           TNC_SHARED: Ride Hail
 
 
-Trip-level skim data are also made available in the preprocessing stage by attaching columns to the ``trips_merged`` table based on expressions in ``summarize_preprocessor.csv``. This process uses skim wrappers indexed by origin, destination, and time of day to gather distance, time, and cost data and each trip, enabling calculation of variables such as vehicle miles traveled (VMT). Preprocessing expressions are interpreted with standard ActivitySim annotation methods, including definition of scalar and vector temporary variables based on underscores and capitalization. The preprocessor expressions included in the MTC example demonstrate calculation of a number of skim-based variables involving distance, time, and cost. The system for joining skim data to trips is currently configured for the one-zone MTC example model and will need to be generalized for multi-zone systems in future work.
+Trip-level skim data are also made available in the preprocessing stage by attaching columns to the ``trips_merged`` table based on expressions in ``summarize_preprocessor.csv``. This process uses skim wrappers indexed by origin, destination, and time of day to gather distance, time, and cost data and each trip, enabling calculation of variables such as vehicle miles traveled (VMT). Preprocessing expressions are interpreted with standard ActivitySim annotation methods, including definition of scalar and vector temporary variables based on underscores and capitalization. The preprocessor expressions included in the Gondor example demonstrate calculation of a number of skim-based variables involving distance, time, and cost. The system for joining skim data to trips is currently configured for the one-zone MTC example model and will need to be generalized for multi-zone systems in future work.
 
 
 Install and Run Simwrapper

docs/development.rst

@@ -350,8 +350,8 @@ Furthermore, multiple versions of these examples can exist, and be used for vari
   questions related to runtime, such as improvements to methods indifferent to the size of the population and number of
   zones.
 * Other - a specific route/path through the code for testing.  For example, the estimation example tests the estimation
-  mode functionality.  The estimation example is a version of the example mtc example - it inherits most settings from
-  example mtc and includes additional settings for reading in survey files and producing estimation data bundles.
+  mode functionality.  The estimation example is a version of the example Gondor example - it inherits most settings from
+  Gondor and includes additional settings for reading in survey files and producing estimation data bundles.
 
 Regardless of the type or version, all functioning examples are described in a common list stored in
 `example_manifest.yaml <https://github.com/ActivitySim/activitysim/blob/master/activitysim/examples/example_manifest.yaml>`_.
@@ -425,7 +425,7 @@ When a new version of the code is pushed to develop:
   * If the agency example previous ran without error or future warnings (i.e. deprecation warnings and is therefore up-to-date), then the developer will be responsible for updating the agency example so it passes the tests
   * If the agency example previously threw errors or future warnings (i.e. is not up-to-date), then the developer will not update the example and the responsibility will fall to the agency to update it when they have time.  This will not preclude development from advancing since the agency specific test can fail while the other tests continue to pass.  If the agency example is not updated within an agreed upon time frame, then the example is removed from the test system.
 
-To help understand this case, the addition of support for representative logsums to :ref:`example_gondor` is discussed.  Example_mtc was selected as the test case for development of this feature because this feature could be implemented and tested against this example, which is the primary example to date.  With the new feature configured for this example, the automatic test system was run to ensure all the existing test examples pass their tests.  The automatic test system was also run to ensure all the cropped agency examples passed their tests, but since not of them include this new feature in their configuration, the test results were the same and therefore the tests passed.
+To help understand this case, the addition of support for representative logsums to :ref:`example_gondor` is discussed.  Example_gondor was selected as the test case for development of this feature because this feature could be implemented and tested against this example, which is the primary example to date.  With the new feature configured for this example, the automatic test system was run to ensure all the existing test examples pass their tests.  The automatic test system was also run to ensure all the cropped agency examples passed their tests, but since not of them include this new feature in their configuration, the test results were the same and therefore the tests passed.
 
 When an agency wants to update their example:
 

docs/examples.rst

@@ -38,7 +38,7 @@ This page describes the example models included with ActivitySim.  The current e
    contains example commands to create and run several versions of the examples.  See also :ref:`adding_agency_examples` for more
    information on agency example models.
 
-.. _example_mtc :
+.. _example_gondor :
 
 example_gondor
 --------------
@@ -65,7 +65,7 @@ individual decision-makers.
 Space
 ^^^^^
 
-TM1 uses the 1454 TAZ zone system developed for the MTC trip-based model.  The zones are fairly large for the region,
+The Gondor model uses the 1454 TAZ zone system developed for the MTC trip-based model.  The zones are fairly large for the region,
 which may somewhat distort the representation of transit access in mode choice. To ameliorate this problem, the
 original model zones were further sub-divided into three categories of transit access: short walk, long walk, and not
 walkable.  However, support for transit subzones is not included in the activitysim implementation since the latest generation
@@ -297,7 +297,7 @@ Inputs
 ^^^^^^
 In order to run example_gondor, you first need the input files in the ``data`` folder as identified in the ``configs\settings.yaml`` file and the ``configs\network_los.yaml`` file:
 
-* input_table_list: the input CSV tables from MTC travel model one (see below for column definitions):
+* input_table_list: the input CSV tables for Gondor (see below for column definitions):
 
     * households - Synthetic population household records for a subset of zones.
     * persons - Synthetic population person records for a subset of zones.
@@ -306,7 +306,7 @@ In order to run example_gondor, you first need the input files in the ``data`` f
 * taz_skims: skims.omx - an OMX matrix file containing the MTC TM1 skim matrices for a subset of zones.  The time period for the matrix must be represented at the end of the matrix name and be seperated by a double_underscore (e.g. BUS_IVT__AM indicates base skim BUS_IVT with a time period of AM).
 
 These files are used in the tests as well.  The full set
-of MTC TM1 households, persons, and OMX skims are on the ActivitySim `resources repository <https://github.com/rsginc/activitysim_resources>`__.
+of Gondor households, persons, and OMX skims are on the ActivitySim `resources repository <https://github.com/rsginc/activitysim_resources>`__.
 
 Additional details on these files is available in the original `Travel Model 1 repository <https://github.com/BayAreaMetro/modeling-website/wiki/DataDictionary>`_,
 although many of the files described there are not used in ActivitySim.
@@ -475,7 +475,7 @@ Area types
   OMX and HDF5 files can be viewed with the `OMX Viewer <https://github.com/osPlanning/omx/wiki/OMX-Viewer>`__ or
   `HDFView <https://www.hdfgroup.org/downloads/hdfview>`__.
 
-  The ``other_resources\scripts\build_omx.py`` script will build one OMX file containing all the skims. The original MTC TM1 skims were converted from
+  The ``other_resources\scripts\build_omx.py`` script will build one OMX file containing all the skims. The original MTC TM1 skims were converted for the Gondor example from
   Cube to OMX using the ``other_resources\scripts\mtc_tm1_omx_export.s`` script.
 
   The example_mtc_sf inputs were created by the ``other_resources\scripts\create_sf_example.py`` script, which creates the land use, synthetic population, and

docs/gettingstarted.rst

@@ -157,15 +157,15 @@ To setup and run the primary example (see :ref:`examples`), do the following:
 * Open a command prompt
 * Activate the conda environment with ActivitySim installed (i.e. ``conda activate asim``)
 * Type ``activitysim create -e example_gondor -d test_example_gondor`` to copy the very small Gondor example to a new test_example_gondor directory
-* Change to the test_example_mtc directory
+* Change to the test_example_gondor directory
 * Type ``activitysim run -c configs -o output -d data`` to run the example
 * Review the outputs in the output directory
 
 .. note::
    Common configuration settings can be overridden at runtime.  See ``activitysim -h``, ``activitysim create -h`` and ``activitysim run -h``.  
    ActivitySim model runs can be configured with settings file inheritance to avoid duplicating settings across model configurations.  See :ref:`cli` for more information.
 
-Additional examples, including the full scale MTC regional demand model, estimation integration examples, multiple zone system examples, 
+Additional examples, including the full scale Gondor regional demand model, estimation integration examples, multiple zone system examples,
 and examples for agency partners are available for creation by typing ``activitysim create -l``.  To create these examples, ActivitySim downloads the (large) input files from 
 the `ActivitySim resources <https://github.com/rsginc/activitysim_resources>`__ repository.  See :ref:`examples` for more information.
 
@@ -197,7 +197,7 @@ The computing hardware required to run a model implemented in the ActivitySim fr
 * The desired runtimes
 
 ActivitySim framework models use a significant amount of RAM since they store data in-memory to reduce
-data access time in order to minimize runtime.  For example, the example MTC Travel Model One model has 2.7 million
+data access time in order to minimize runtime.  For example, the example Gondor model has 2.7 million
 households, 7.5 million people, 1475 zones, 826 network skims and has been run between one hour and one day depending
 on the amount of RAM and number of processors allocated.  See :ref:`multiprocessing` and :ref:`chunk_size` for more information.