Initialize LOS

The initialize LOS model isn’t really a model, but rather a series of data processing steps in the data pipeline. The initialize LOS model does two things:

• Loads skims and cache for later if desired

• Loads network LOS inputs for transit virtual path building (see transit_virtual_path_builder, pre-computes tap-to-tap total utilities and cache for later if desired

The main interface to the initialize LOS step is the initialize_los function. The main interface to the initialize TVPB step is the initialize_tvpb function. These functions are registered as Inject steps in the example Pipeline.

Implementation

activitysim.abm.models.initialize_los.initialize_los(state: State, network_los: Network_LOS) → None

Currently, this step is only needed for THREE_ZONE systems in which the tap_tap_utilities are precomputed in the (presumably subsequent) initialize_tvpb step.

Adds attribute_combinations_df table to the pipeline so that it can be used to as the slicer for multiprocessing the initialize_tvpb s.tep

FIXME - this step is only strictly necessary when multiprocessing, but initialize_tvpb would need to be tweaked FIXME - to instantiate attribute_combinations_df if the pipeline table version were not available.

activitysim.abm.models.initialize_los.compute_utilities_for_attribute_tuple(state, network_los, scalar_attributes, data, trace_label)

activitysim.abm.models.initialize_los.initialize_tvpb(state: State, network_los: Network_LOS, attribute_combinations: DataFrame) → None

Initialize STATIC tap_tap_utility cache and write mmap to disk.

uses pipeline attribute_combinations table created in initialize_los to determine which attribute tuples to compute utilities for.

if we are single-processing, this will be the entire set of attribute tuples required to fully populate cache

if we are multiprocessing, then the attribute_combinations will have been sliced and we compute only a subset of the tuples (and the other processes will compute the rest). All process wait until the cache is fully populated before returning, and the locutor process writes the results.

FIXME - if we did not close this, we could avoid having to reload it from mmap when single-process?