AnyLogic 9
Expand
Font size

“Pull” vs. “Push” agent flow protocol

AnyLogic supports two alternative agent flow protocols for Process Modeling Library flowcharts.

  • The “pull” way of ejecting agents. The agent passing protocol is roughly as follows: the sending block notifies the receiving block that there is an agent ready to exit. If the receiving block can accept the agent, it will request it from the sending block, and, if the agent is still available, it will be passed over.
    The “pull” protocol is used in the blocks that can wait for the receiving block to be ready to accept the agent. Flowchart blocks will stop and wait until the next blocks are ready.
  • The “push” way of ejecting agents. The block simply pushes the agent out and does not wait for the receiving blocks. If the agent is unable to leave a “push” port in zero model time, a runtime error is generated. Therefore, AnyLogic does not allow implicit (hidden) buffering or blocking, and you will always be notified of an overflow situation and will be able to locate the bottleneck. The port implementing the “push” protocol can therefore hold a number of agents, but only for zero time. This buffering is necessary to allow truly asynchronous execution of concurrent events between agent generation and consumption.

The following blocks support the “pull” protocol and also provide the “push” protocol as an option: Source, Enter, Delay, Pickup, Dropoff, Seize, Batch, Unbatch, Combine. Select the advanced Forced pushing option to enable the “push” protocol for the block:

Blocks with internal storage for agents

Some blocks can store agents internally until they are moved further through the flowchart. These storages typically serve as internal queues or temporary holding areas for agents that are waiting for certain conditions to be met before they can proceed further in the flowchart.

Internal storages help regulate the flow of agents through the model. They ensure that agents do not proceed until the necessary conditions are met, such as a service becoming available or a resource being seized. In scenarios where resources are limited, internal storages allow agents to queue up while waiting for resources to become available. They also provide a way to collect data on agent wait times of agents, queue lengths, and other useful metrics for analyzing the model.

The blocks with internal storage typically expose functions that allow you to interact with the agents they contain, such as calculating the number of such agents, removing them, or modifying them by iteration.

The following blocks have the ability to store agents:

Block Description
Delay Has the adjustable capacity for delaying multiple agents. Provides functions to get the size of the block (the number of agents inside it), and to remove, get, or iterate over those agents.
Queue Acts as a buffer for agents to be accepted by the next block. Provides functions to get, remove, or iterate over the agents in the block.
Match Checks whether the both of two incoming agents meet certain criteria; the agents to be checked are stored in two queues.
Provides functions to get information about the number of agents in both internal queues of the block, or to remove specific agents from their respective queues.
Assembler Has multiple internal queues and can use resources to process the incoming agents.
Provides functions to remove specific agents from a queue, suspend agents, resume suspended agents, and get information about the number of agents in a particular queue or a specific agent within a queue.
MoveTo Keeps the agent inside itself while the agent moves from the starting point to the destination by the shortest route.
Provides functions to get information about the number of agents currently being moved by the block, to remove specific agents from the block, and to iterate over all agents in the block.
Seize Has an embedded, fully functional Queue block, with all of its functions available.
Provides functions for retrieving information about the number of agents in the internal queue, retrieving agents based on their position in the queue, removing specific agents from the queue, suspending agents, and resuming suspended agents.
Service Has the fully functional Queue and Delay blocks embedded, with their agent storages thus available.
Provides functions for retrieving information about the number of agents waiting within the block, removing specific agents from the block, and managing the internal queue.
ResourceSendTo
Keeps the agent in itself while the resource being sent by the block moves from the starting point to the destination by the shortest route.
Has a function which allows to get the number of agents within this block.
ResourceTaskStart Has a storage for agents that are not currently accepted by the subsequent flowchart block (for example, because the required resource unit has not yet arrived at its destination).
Has a function which allows to get the number of agents within this block.
Batch
Has an embedded Queue block where it stores the incoming agents to be added to the batch.
Has functions to get information about the number of agents waiting within the block, remove specific agents from the block, and iterate through the agents.
ResourcePool Given that the block models the set of resource units (which are agents), it has the internal storage that holds the currently idle resource units.
Provides functions to get information about the number of idle and busy resource units, the total number of units within the ResourcePool block, and the active units in the current shift, and to check if a specific unit is included in the pool.
RackStore
RackPick
Both of these legacy blocks have internal queues and functions that allow to calculate how many agents are currently in those queues.
How can we improve this article?