Input/Output Files

The input to fast-trips consists of:
  • A Transit Network directory, including schedules, access, egress and transfer information, specified by the gtfs_plus
  • A Transit Demand directory, including persons, households and trips, specified by the dyno_demand
  • fast-trips Configuration, specified below

Passenger Demand

Passenger demand is specified in the the dyno_demand format of one to three csv files.
  • trip_list.txt
  • person.txt
  • household.txt

trip_list.txt

  • File MUST contain a record for each trip to be assigned.
  • File MUST be a valid CSV file.
  • The first line of each file MUST contain case-sensitive field names.
  • Field names MUST NOT contain tabs, carriage returns or new lines.
Field DType Description
person_id int or str ID that uniquely identifies the traveller. Use 0 (zero) to identify trips that do not have a disaggregate person-record associated with them.
person_trip_id int or str ID that uniquely identifies the trip within a given household/person. ID MAY be sequential.
o_taz int or str Trip origin zone
d_taz int or str Trip destination zone
mode str

Trip mode, which must match a valid specification for route choice and the modal hierarchy. For transit, the mode should encapsulate access + egress modes separated by hyphens. Example:

  • walk-local_bus-walk
  • PNR-commuter_rail-walk
Example main modes:
  • local_bus
  • premium_bus
  • light_rail
  • commuter_rail
  • street_car
  • ferry
Example access or egress modes:
  • walk
  • bike_own
  • bike_share
  • PNR
  • KNR
purpose str

Trip purpose, which can include any segmentation of purpose that is deemed appropriate for segmenting the route choice model so long as there are corresponding parameters specified in the route choice controls file. Examples include:

  • work
  • school
  • personal_business
  • shopping
  • meal
  • social
  • work_based
  • other
  • visitor
departure_time HH:MM:SS Desired departure time.
arrival_time HH:MM:SS Desired arrival time.
time_target str

Arrival/Departure rigidity indicator. Options include:

arrival: arrival time is more important departure: dept time is more important
vot float Value of time for trip in dollars / hour
pnr_ids list of int Available park and rides. A comma-delimited list of stations within brackets. Example: [1219, 3354, 9485] An empty list implies any accessible park and ride can be used.
person_tour_id int or str ID that uniquely identifies the tour within a given household/person. ID MAY be sequential.

Transport Network

The transport network is specified in the the gtfs_plus format of text files. It can be generated by augmenting existing GTFS files, or by converting travel model files to gtfs_plus using a tool like `network_wrangler`_

Fares

`GTFS-plus`_ fare inputs are similar to GTFS fare inputs but with additional fare periods for time period-based fares.

However, since the columns route_id, origin_id, destination_id and contains_id are all optional in fare_rules.txt <https://github.com/osplanning-data-standards/GTFS-PLUS/blob/master/files/fare_rules.md>`_ and therefore may be specified in different combinations, fast-trips implements fares with the following rules:

  • contains_id is not implemented in Fast-Trips, and its inclusion will result in an error
  • Specifying origin_id and not destination_id or vice versa will result in an error. Each fare rule must specify both or neither.
  • These combinations of route_id, origin_id, and d`estination_id` will be used to match a fare_id to a transit trip, in this order. The first match will win. - Matching route_id, origin_id and destination_id - Matching route_id only (no origin_id or destination_id specified) - Matching origin_id and destination_id only (no route_id specified) - No match (e.g. fare_id specified with no other columns)

Discount and free transfers specified in fare_transfer_rules_ft.txt <https://github.com/osplanning-data-standards/GTFS-PLUS/blob/master/files/fare_transfer_rules_ft.md>`_ are applied to transfers from one fare period to another fare period, and these links need to be back-to-back. So if a passenger transfers from A to B to C and the discount is specified for fare period A to fare period C, they will not receive the discount.

Free transfers are also specified within fare periods (possibly time-bounded) in fare_attributes_ft.txt <https://github.com/osplanning-data-standards/GTFS-PLUS/blob/master/files/fare_attributes_ft.md>`_`. These free transfers are applied after the discounts from fare_transfer_rules_ft.txt <https://github.com/osplanning-data-standards/GTFS-PLUS/blob/master/files/fare_transfer_rules_ft.md>`_` and they do not need to be back-to-back. So if a passenger transfers from A to B to A and fare period A has 1 free transfer specified, but a transfer from B to A has a transfer fare of $.50, the passenger will receive the free transfer since these rules are applied last (and override).

There are four places where fares factor into fast-trips.

  1. During path-finding (C++ extension), fares get assessed as a cost onto links, which translate to generalized cost (minutes) via the traveler’s value of time. Fare transfer rules here are complicated, because we don’t know which is the next/previous fare, and we can only guess based on probabilities. The fare is estimated using [Hyperlink::getFareWithTransfer()](src/hyperlink.cpp).

    Free transfers as configured in fare attributes are implemented here in a simplistic way; that is, a free transfer is assumed if the fare attributes have granted any free transfers without looking at transfer_duration or the number of transfers. Also, this transfer is required to be back-to-back also. A future enhancement could include keeping a transfer count for each fare period so that the back-to-back requirement is not imposed, and also so that a certain number of free fares could be tallied, but at this time, a simpler approach is used because it’s not clear if this kind of detail is helpful.

    Turn this off using configuration option transfer_fare_ignore_pathfinding.

  2. During path-enumeration (C++ extension), when the paths are being constructed by choosing links from the hyperpath graph, at the point where each link is added to the path, the fare transfer rules are applied to adjust fares with more certainty of the the path so far. This is done in [Hyperlink::setupProbabilities()](src/hyperlink.cpp) which calls Hyperlink::updateFare() and updates the link cost as well if the fare is affected. Free transfers as configured in fare attributes are looked at here as well, but without the transfer duration component.

  3. During path-enumeration (C++ extension), after the path is constructed, the trip cost is re-calculated at the end using [Path::calculateCost()](src/path.cpp). At this moment in the process, the path is complete and final, so the fare transfer rules are relatively easy to apply given that links are certain. The initial fare and cost are saved and passed back to python to show the effect of step 1.

    Free transfers as configured in fare attributes are also addressed here.

    Turn this off using configuration option transfer_fare_ignore_pathenum.

  4. During simulation (python), while the path is being adjusted due to vehicle times, the fares are calculated via [Route.add_fares()](fasttrips/Route.py). This is unlikely to change anything unless the fare periods changed due to the slow-down of vehicles – so consider deprecating this in favor of using the pathfinding results? For now, it’s a good test that the C++ code is working as expected; running with simulation off should result in identical fare and cost results from pathfinding and the (non-vehicle-updating) python simulation.

Configuration Files

There are two required configuration files:
  • pathweights_ft.txt : weights assigned to each component of a transit path
  • config_ft.txt : system, run setup and pathfinding configurations
An optional third configuration file:
  • config_ft.py : defines user classes in python.

Pathweights Specification

The pathweight_ft.txt file is a required file that tells Fast-Trips how much to value each attribute of a path. This will be used for the stop-labeling stage but also the path selection, which is done in a logit model. Therefore, the weights should be consistent with with utility.

A good rule of thumb to consider is that typical in-vehicle-time coefficients for mode choice logit models range from 0.01 to 0.08. If you consider route choice to be a nest of mode choice, you would divide whatever the in-vehicle-time coefficient is for mode choice by whatever that nesting coefficient is. One assumption is that the nesting coefficient for route choice should have a smaller value than a typical mode choice model, meaning that people are more likely to switch routes than modes. So, if a mode-choice utility coefficient for in-vehicle time is 0.02 and an assumed nesting coefficient is 0.2, the value for route choice would be 0.10 (0.02 / 0.2).

The file can be a csv or fixed-format. If you use a fixed-format, make sure pathweights_fixed_width = True in the run configuration file (e.g., config_ft.txt).

pathweights_ft.txt must have the following columns:

The following is an example of a minimally specified pathweight_ft.txt :

demand_mode_type demand_mode supply_mode weight_name weight_value
access walk walk_access time_min .02
egress walk walk_egress time_min .02
transit transit local_bus wait_time_min .02
transit transit local_bus in_vehicle_time_min .01
transfer transfer transfer transfer_penalty .05
transfer transfer transfer time_min .02

Determining supply modes and weight values

If a supply mode exists in pathweight_ft.txt, it is assumed to be a valid mode to use for the associated demand mode.
  • Demand modes for each person are determined from each component of mode in trip_list.txt plus an implied transfer.
  • If the trip list were to specify that someone takes commuter_rail, then they can still take a local bus or any supporting mode on their trip in addition to commuter rail so long as it is specified in pathweight_ft.txt.
  • If for some reason a supply mode (i.e. rocket_ship) shouldn’t be used for a particular demand mode (i.e. land_based_transit), then don’t put a row with both of them there.
Weight values should make sense relative to each other
  • Weights are often assumed to be higher for “supportive” modes and lower for “main” modes to induce them to select a path with the selected demand mode, as in the example below.
demand_mode supply_mode weight_name weight_value
commuter_rail local_bus in_vehicle_time_min 0.015
commuter_rail heavy_rail in_vehicle_time_min 0.01
local_bus local_bus in_vehicle_time_min 0.01
Weight values should have appropriate meaning w.r.t. path choice context.
  • If a logit model is being used to select which path a traveler selects, the weights need to be scaled to be appropriate to that context.
  • Based on work summarized in NCHRP Report 716 (http://www.trb.org/Publications/Blurbs/167055.aspx), values for in-vehicle-travel-time for mode choice range from 0.01 to 0.05 per minute of travel
  • By assuming that path choice is a nested logit of a mode choice model, one can divide these values by a reasonable nesting parameter (ranging from ~0.2-0.8) to get a rough reasonable range of 0.01 to 0.20.

Weight Names

The column weight_name must conform to a set of constraints as discussed below.
  • For most of the weights prefix mode is not needed. E.g. there is no need to label weight_name time_min for supply_mode walk_access as walk_time_min, because the fact that the supply_mode is walk_access means it is only assessed on walk links.
  • The drive option (PNR/KNR access/egress), however, should have walk_ and drive_ prefixes, because the access can have both components: driving to the station from the origin and walking from the lot to the station. So for example, for supply_mode pnr_access there will be two weights associated with travel time: walk_time_min and drive_time_min.

The following is a partial list of possible weight names based on the demand mode / supply mode combinations.

demand_mode_type demand_mode supply_mode weight names
access walk walk_access time_min depart_early_min depart_late_min
egress walk walk_egress time_min arrive_early_min arrive_late_min
access PNR pnr_access walk_time_min drive_time_min arrive_early_min arrive_late_min
transfer transfer transfer transfer_penalty time_min ``wait_time_min
transit transit   in_vehicle_time_min wait_time_min

Note

Note that the cost component is handled at the path level using the value of time column in trip_list.txt.

Weight Qualifiers

By default, Fast-Trips will apply all weights as a constant on the appropriate variable. Fast-Trips also supports weight qualifiers which allow for the weights to be applied using more complex models. The supported qualifiers are listed below. Certain qualifiers also require modifiers to shape the cost function.

If no qualifier is specified, constant will be assumed.

Qualifier Formulation Required Modifiers
constant (default) \(f(x) = weight * x\) N/A
exponential \(f(x) = { (1 + weight) }^{x}\) N/A
logarithmic \(f(x) = weight*{log_{base}}*x\) log_base
logistic \(f(x) = \frac{logistic\_max}{1+e^{-weight*(x-sigmoid)}}\) logistic_max logistic_mid

Example:

#Pathweights_ft.txt snippet
user_class purpose demand_mode_type demand_mode    supply_mode  weight_name                                   weight_value
# default constant
all        other   transit          transit        rapid_bus    wait_time_min                                 1.77

# Explicitly constant
all        other   transit          transit        rapid_bus    wait_time_min.constant                        1.77

all        other   access           walk           walk_access  depart_early_min.logistic                     0.2
all        other   access           walk           walk_access  depart_early_min.logistic.logistic_max        10
all        other   access           walk           walk_access  depart_early_min.logistic.logistic_mid        9

all        other   egress           walk           walk_egress  arrive_late_min.logarithmic                   0.3
all        other   egress           walk           walk_egress  arrive_late_min.logarithmic.log_base          2.71828

# Exponential
all        work    access           walk           walk_access  depart_early_min.exponential                  0.02

# Logarithmic
all        other   egress           walk           walk_egress  arrive_late_min.logarithmic                   0.3
all        other   egress           walk           walk_egress  arrive_late_min.logarithmic.log_base          2.71828

Config_ft File

config_ft.txt is a required file whose location is specified at runtime. If the same options are specified in both, then the version specified in the Transit Demand input directory will be used. (Two versions may be specified because some configuration options are more relevant to demand and some are more relevant to network inputs.)

The configuration files are parsed by python’s ConfigParser module <https://docs.python.org/2/library/configparser.html#module-ConfigParser>`_ and therefore adhere to that format, with two possible sections: fasttrips and pathfinding.

Configuration Options: fasttrips

Option Name Type Default Description
bump_buffer float 5 Not really used yet.
bump_one_at_a_time bool False  
capacity_constraint bool False Hard capacity constraint. When True, fasttrips forces everyone off overcapacity vehicles and disallows them from finding a new path using an overcapacity vehicle.
create_skims bool False ##TODO Not implemented yet.
debug_num_trips int -1 If positive, will truncate the trip list to this length.
debug_trace_only bool False If True, will only find paths and simulate the person ids specified in trace_person_ids
debug_output_columns bool False If True, will write internal & debug columns into output.
fare_zone_symmetry bool False If True, will assume fare zone symmetry. That is, if fare_id X is configured from origin zone A to destination zone B and there is no fare configured from zone B to zone A, we’ll assume that fare_id X also applies.
max_iterations int 1 Maximum number of pathfinding iterations to run.
number_of_processes int 0 Number of processes to use for path finding.
output_passenger_trajectories bool True Write chosen passenger paths? ##TODO: deprecate. Why would you ever not do this?
output_pathset_per_sim_iter bool False Output pathsets for each simulation iteration? If false, just outputs once per path-finding iteration.
prepend_route_id_to_trip_id bool False This is for readability in debugging; If True, then route ids will be prepended to trip ids.
simulation bool True Simulate transit vehicles? After path-finding, should fast-trips update vehicle times and put passengers on vehicles? If False, fast-trips: - still calculates costs and probabilities and chooses paths, - doesn’t update vehicle times from those read in from the input network, - doesn’t load passengers onto vehicles This is useful for debugging path-finding and verifying that pathfinding calculations are consisten twith cost/fare calculations done outside of pathfinding.
skim_start_time string 5:00 ##TODO Not implemented yet.
skim_end_time string 10:00 ##TODO Not implemented yet.
skip_person_ids string ‘None’ A list of person IDs to skip.
trace_ids string ‘None’ A list of tuples, (person ID, person trip ID) for whom to output verbose trace information.

Configuration Options: pathfinding

Option Name Type Default Description
max_num_paths int -1 If positive, drops paths after this IF probability is less than ``
min_path_probability float 0.005 Paths with probability less than this get dropped IF max_num_paths specified AND hit.
min_transfer_penalty float 0.1 Minimum transfer penalty. Safeguard against having no transfer penalty which can result in terrible paths with excessive transfers.
overlap_chunk_size int 500 How many person’s trips to process at a time in overlap calculations in python simulation (more means faster but more memory required.)
overlap_scale_parameter float 1 Scale parameter for overlap path size variable.
overlap_split_transit bool False For overlap calcs, split transit leg into component legs (A to E becauses A-B-C-D-E)
overlap_variable string count

The variable upon which to base the overlap path size variable. Can be:

  • None
  • count
  • distance
  • time
pathfinding_type string stochastic
Pathfinding method. Can be:
  • deterministic
  • file
  • stochastic
pathweights_fixed_width bool False If true, read the pathweights file as a fixed width, left-justified table (as opposed to a CSV, which is the default).
stochastic_dispersion float 1.0 Stochastic dispersion parameter. TODO: document this further.
stochastic_max_stop_process_count int -1 In path-finding, how many times should we process a stop during labeling? Specify -1 for no max.
stochastic_pathset_size int 1000 In path-finding, how many paths (not necessarily unique) determine a pathset?
time_window float 30 In path-finding, the max time a passenger would wait at a stop.
utils_conversion_factor float 1.0 In the path-finding labeling stage, multiplies the utility by this factor to prevent negative costs.
transfer_fare_ignore_pathfinding bool False In path-finding, suppress trying to adjust fares using transfer rules. For performance.
transfer_fare_ignore_pathenum bool False In path-enumeration, suppress trying to adjust fares using transfer rules. For performance.
user_class_function string generic_user_class A function to generate a user class string given a user record.
depart_early_allowed_min float 0.0 Allow passengers to depart before their departure time time target by this many minutes
arrive_late_allowed_min float 0.0 Allow passengers to arrive after their arrival time target by this many minutes.

More on Overlap Path Size Penalties

The path size overlap penalty is formulated by Ramming and discussed in Hoogendoorn-Lanser et al. (see [References](#references) ).

When the pathsize overlap is penalized (pathfinding overlap_variable is not None), then the following equation is used to calculate the path size overlap penalty:

\(PS_i = \sum_{a\in\Gamma_i}\frac{l_a}{L_i}*\frac{1}{\sum_{j\in C_{in}} \left(\frac{L_i}{L_j}\right)^\gamma*\delta_{aj}}\)

Where
  • i is the path alternative for individual n
  • \(\Gamma_i\) is the set of legs of path alternative i
  • \(l_a\) is the value of the overlap_variable for leg a. So it is either 1, the distance or the time of leg a depending of if overlap_scale_parameter is count, distance or time, respectively.
  • \(L_i\) is the total sum of the overlap_variable over all legs \(l_a\) that make up path alternative i
  • \(C_{in}\) is the choice set of path alternatives for individual n that overlap with alternative i
  • \(\gamma\) is the overlap_scale_parameter
  • \(\delta_{ai} = 1\ and\ \delta_{aj} = 0\ \forall\ j\ \ne i\)

From Hoogendoor-Lanser et al.:

Consequently, if leg a for alternative i is unique, then
  • the denominator is equal to 1 and
  • the path size contribution of leg a is equal to its proportional length \(\frac{l_a}{L_i}\)
If leg l<sub>a</sub> is also used by alternative j, then:
  • the contribution of leg \(l_a\) to path size \(PS_i\) is smaller than \(\frac{l_a}{L_i}\)
If \(\gamma = 0\) or if routes i and j have equal length, then
  • the contribution of leg a to \(PS_i\) is equal to \(\frac{l_a}{2L_i}\)
If \(\gamma > 0\) and routes i and j differ in length, then
  • the contribution of leg a to \(PS_i\) depends on the ratio of \(L_i\) to \(L_j\).
If route i is longer than route j
  • and \(\gamma > 1\), then
  • the contribution of leg a to \(PS_i\) is larger than \(\frac{l_a}{2L_i}\)
  • otherwise,
  • the contribution is smaller than \(\frac{l_a}{2L_i}\).
If \(\gamma > 1\) in the exponential path size formulation, then
  • long routes are penalized in favor of short routes.
If overlapping routes have more or less equal length, then
  • The use of parameter \(\gamma\) is questionable and should therefore be set to 0.
  • Overlap between those alternatives should not affect their choice probabilities differently.
  • The degree to which long routes should be penalized might be determined by estimating \(\gamma\).
  • If \(\gamma\) is not estimated, then an educated guess with respect to \(\gamma\) should be made.
  • To this end, differences in route length between alternatives in a choice set should be considered.

User Class Configuration: config_ft.py

config_ft.py is an optional python file containing functions that are evaluated to ascertain items such as user classes. This could be used to programmatically define user classes based on person, household and/or trip attributes.

The function name for user class is specified in the pathfinding input parameter user_class_function

Example::

def user_class(row_series):
    """
    Defines the user class for this trip list.

    This function takes a single argument, the pandas.Series with person, household and
    trip_list attributes, and returns a user class string.
    """
    if row_series["hh_id"].lower() in ["simpson","brady","addams","jetsons","flintstones"]:
        return "fictional"
    return "real"

Passenger Path Output

Fast-Trips uses the dyno_path data standard to convey sets of paths, or a pathset. Each Path is comprised of a set of links. Each dyno-path pathset is comprised of two sets of files, a path-file, and a link file, described in the following sections.

enumerated_links.csv and enumerated_paths.csv
Paths that are enumerated after the path-finding/labeling step.
pathset_links.csv and pathset_paths.csv
Paths that are considered by passengers in the path choice process.
chosen_links.csv and chosen_paths.csv
Paths that are selected by passengers.

Path files

Path-based output files depict the available and enumerated paths in the path choice set in the dyno_path format.

Dyno-path path file required attributes:

variable Description
person_id Corresponds to person_id field in dyno-demand-formatted demand
trip_list_id_num Corresponds to line number field in dyno-demand-formatted trip_list.txt where 1 is the first trip. To be replaced when dyno-demand issue#2 is resolved.
pathdir Direction. 1 for outbound, 2 for inbound.
pathmode Demand mode. Corresponds to mode field in dyno-demand-formatted trip_list.txt

Dyno-path Path file optional attributes

variable description
pf_iteration Path-finding iteration.
pathnum ID within a pathset.
pf_cost Debug. The generalized cost as calculated by the path finder.
pf_probability Debug. The probability of the path as calculated by the path finder.
description Text description of the path, including all nodes and links.
chosen Chosen status for path. -1 if not chosen, -2 if chosen but rejected, otherwise iteration + simulation_iteration/100.
missed_xfer 1 if the path has a missed transfer.
sim_cost Generalized cost calculated in the assignment/simulation.
logsum_component Debug. Portion of the total logsum from this path.
logsum Debug. Total logsum for the pathset.
probability Debug. Probability of this path as calculated by the route choice model.
iteration Iteration in which this path was found.

Vehicle Based Output

veh_trips.csv

Contains a record for each vehicle-trip, stop and iteration, pathfinding_iteration, simulation_iteration combination.

Vehicle-based output depicts ridership by transit vehicle. Eventually it will be translated into the `gtfs_ride`_ data standard.

Variable Description
iteration global fast-trips iteration
pathfinding_iteration pathfinding iteration
simulation_iteration simulation iteration
direction_id 0 or 1, as coded in trips.txt in GTFS_PLUS
service_id As coded in trips.txt in GTFS_PLUS
route_id As coded in trips.txt in GTFS_PLUS
trip_id As coded in trips.txt in GTFS_PLUS
stop_sequence As coded in stop_times.txt in GTFS_PLUS
stop_id As coded in stop_times.txt in GTFS_PLUS
arrival_time As coded in stop_times.txt in GTFS_PLUS
arrival_time_min As coded in stop_times.txt in GTFS_PLUS
departure_time As coded in stop_times.txt in GTFS_PLUS
departure_time_min As coded in stop_times.txt in GTFS_PLUS
travel_time_sec Travel time from previous stop, as coded in stop_times.txt in GTFS_PLUS
dwell_time_sec Dwell time for stop, calculated based on dwell_formula equation in vehicles_ft.txt in GTFS_PLUS
capacity Passengers that can be on board the vehicle, per vehicles_ft.txt in GTFS_PLUS
boards Passengers boarding at stop, per Fast-Trips.
alights Passengers alighting at stop, per Fast-Trips.
onboard Passengers on-board vehicle as it approaches the stop.
standees Standees on vehicle as it approaches the stop.
friction boards``+``alights``+``standees. Can be used in dwell time calculations.
overcap Initializes at -1, then onboard- capacity

Trace Output

Output from person traces is currently contained in a very lengthy .log file as well as specially labeled link- and path- output csvs in the dyno_path formats.

output_trace_<trace_label>.log
A comprehensive debug log of every calculation for the specified rider.
fasttrips_labels_<trace_label>_<iteration>.csv

Pathfinding for specified rider with link info. Has a row for the A and B node of each link for each label iteration.

Variable Description
label_iter Stop labeling iteration; each iteration updates another set of labels emanating from current node
link link #, starting from 1
node ID node id, which is either the start or end of the link
time cumulative time passed based on least cost label [?]
mode Link supply mode.
trip_id If a transit link, trip_id from GTFS_PLUS. Else, non-motorized mode type.
link_time Time of the specific link.
link_cost Cost of the specific link.
cost Cumulative composit label (logsum) of the node.
fasttrips_labels_ids_<trace_label>_<iteration>.csv

Pathfinding for specified rider, for debugging.

Variable Description
stop_id the stop id per GTFS_PLUS
stop_id_label_iter Stop labeling iteration; each iteration updates another label
is_trip boolean; did the labeling algorithm reach this stop via a transit trip, or a non-motorized link? The algorithm alternates between the two.
label_stop_cost Cost given to that stop for that iteration based on the cost of the previous stop and the link used to get here

Computing Performance Output

ft_output_performance.csv
Outputs start- and end- time and memory for each iteration of each step of fast-trips: read_configuraiton, pathfinding, assignment, simulation iteration, and output. Note that mid-process memory is not able to be logged :-(
ft_output_performance_pathfinding.csv
Detailed output for each trip on path finding performance. Includes
  • process number,
  • pathfinding ieration,
  • number of paths labelled,
  • if it was traced,
  • the label iterations it took,
  • the max times each stop was processed
  • the time it took in clock hours and seconds
  • time it took enumerating in clock hours and seconds
  • memory usage and time of memory timestamp

Settings Output

ft_output_config.txt
Just in case you threw away any record of the settings you used to run Fast-Trips, the input files you used, …or if you wanted to know what settings Fast-Trips actually used when you gave it multiple layers of direction, you can review them here.