Class PathTurnFlowUpdateConsumer

  • All Implemented Interfaces:
    TriConsumer<OdZone,​OdZone,​Double>

    public class PathTurnFlowUpdateConsumer
    extends PathFlowUpdateConsumer<NetworkTurnFlowUpdateData>
    Consumer to apply during path based turn flow update for each combination of origin, destination, and demand

    Depending on the configuration which in turn depends on the active solution scheme a slightly different approach is taken to this update where:

    POINT QUEUE BASIC: Also update the current sending flow. Only during basic point queue solution scheme, sending flows are NOT locally updated in the sending flow update step. Therefore sending flows of most links are not updated during this sending flow update because it only updates the sending flows of outgoing links of potentially blocking nodes. When an incoming link of any node is not also an outgoing link of another potentially blocking node its sending flow remains the same even if it actually changes due to further upstream changes in restrictions. In this approach this is only identified when we make sure the sending flows are updated during (this) loading on the path level. Hence, we must update sending flows here.

    ANY OTHER SOLUTION APPROACH: Here we update all used nodes and sending flows are updated iteratively and locally propagated without the need of the loading in the sending flow update. Therefore, there is no need to update the sending flows. On the other hand we now update the turn flows on all used nodes rather than only the potentially blocking ones.

    Author:
    markr
    • Constructor Detail

      • PathTurnFlowUpdateConsumer

        public PathTurnFlowUpdateConsumer​(NetworkTurnFlowUpdateData dataConfig,
                                          OdPaths odPaths)
        Constructor, where sending flows are not to be updated, only turn flows
        Parameters:
        dataConfig - to use
        odPaths - to use
    • Method Detail

      • applySingleFlowUpdate

        protected double applySingleFlowUpdate​(EdgeSegment prevSegment,
                                               EdgeSegment currentSegment,
                                               double turnSendingFlowPcuH)
        Apply the flow to the turn (and update link sending flow if required)
        Specified by:
        applySingleFlowUpdate in class PathFlowUpdateConsumer<NetworkTurnFlowUpdateData>
        Parameters:
        prevSegment - of turn
        currentSegment - of turn
        turnSendingFlowPcuH - sending flow rate of turn
        Returns:
        accepted flow rate of turn after applying link acceptance factor
      • applyPathFinalSegmentFlowUpdate

        protected void applyPathFinalSegmentFlowUpdate​(EdgeSegment lastEdgeSegment,
                                                       double acceptedPathFlowRate)
        DO NOTHING - since this is a turn update and the final turn has no outgoing edge segment it is never tracked (because it does not exist), therefore, we can disregard updating the final segment flow in a turn flow update setting, even when tracking link segment sending flows (since this sending flow is never required as input to a node model update
        Specified by:
        applyPathFinalSegmentFlowUpdate in class PathFlowUpdateConsumer<NetworkTurnFlowUpdateData>
        Parameters:
        lastEdgeSegment - to use
        acceptedPathFlowRate - to use
      • getAcceptedTurnFlows

        public org.apache.commons.collections4.map.MultiKeyMap<Object,​Double> getAcceptedTurnFlows()
        The found accepted turn flows by the combined entry-exit segment hash code
        Returns:
        accepted turn flows