Dynamic Flow Loss Monitoring in AnyLogic Refinery Simulation Using FlowDiscrepancy

       An AnyLogic refinery simulation can run successfully while valuable intermediate products are diverted into residual flows because of downstream capacity constraints. This article explains how the FlowDiscrepancy component in Petroleum Refining Library (PRL) 2.5.5 supports dynamic flow monitoring using custom Java classes and message storage. These streams are transferred to tank farms, routed to product mixers for blending, stored in product tanks, and eventually shipped to customers through loading racks. However, downstream components cannot always accept the incoming flow. A tank farm may have insufficient available capacity, a product mixer may reach its maximum throughput, or equipment may become temporarily unavailable because of maintenance or other operational restrictions. Imbalances between production and shipment plans can create similar situations. When these constraints are correctly represented in the simulation model, an affected stream may be redirected into a residual flow. This mechanism preserves the model's operational constraints and allows the simulation to continue without requiring upstream process units to discharge material into unavailable or capacity-constrained destinations. From a simulation-engineering perspective, the model may behave exactly as intended. From a production and economic perspective, however, the result may be undesirable. The problem becomes particularly significant when the diverted stream contains a valuable intermediate product that has already passed through several processing, separation, or purification stages. Instead of reaching its intended destination for further processing or blending, the material accumulates in a residual flow, potentially reducing the economic value of the production process.

       A refinery simulation can complete its entire simulation horizon without errors while generating substantial residual flows of valuable products. The model may correctly enforce material-flow constraints, tank capacities, and equipment throughput limits. Nevertheless, the resulting production scenario may be economically inefficient because valuable streams cannot be used as planned. Such situations may arise from insufficient storage capacity, blending restrictions, equipment downtime, imbalances in production and shipment plans, incorrect model configuration, or user interventions during simulation execution. Importantly, a residual flow does not necessarily represent a physical loss of material from the refinery. It can instead indicate that the material has been diverted from its intended route or that its planned use has become impossible under the current operating conditions. This distinction is essential when interpreting simulation statistics and evaluating production performance.

       To investigate these situations, engineers need more than aggregate statistics collected at the end of a simulation run. They need to identify when residual flows appear, how their flow rates change over time, and which downstream constraints may have caused the diversion. Dynamic monitoring makes it possible to capture these changes as the simulation progresses. By recording flow-rate variations and associating them with relevant model information, engineers can investigate potentially undesirable events and identify the components that warrant further analysis. The Petroleum Refining Library addresses this requirement through the FlowDiscrepancy component. Combined with user-defined Java classes and event-driven message handling, it provides a foundation for monitoring residual-flow dynamics and collecting information for subsequent analysis. The objective is not to eliminate residual flows regardless of operating constraints. It is to make potentially significant flow diversions visible, measurable, and easier to investigate within an AnyLogic refinery simulation.

       The FlowDiscrepancy component can be placed at selected locations in an AnyLogic refinery simulation to monitor flow behavior. When installed on a residual flow, it provides an observation point for tracking flow-rate changes and passing relevant information to custom Java logic.

       In a refinery simulation, not every flow requires the same level of monitoring. The most valuable insights often come from observing locations where unexpected or economically undesirable flow diversion can occur. For example, a FlowDiscrepancy component can be placed at a residual-flow location associated with a tank farm or product blending system. When operating conditions prevent the intended material transfer, the component can serve as an observation point for the resulting flow.
       Depending on the model configuration and the events generated by the component, this information can be used to identify:
        - when a residual flow first appears;
        - when its flow rate changes;
        - how the flow evolves as operating conditions change;
        - which events warrant further investigation.
       This approach does not require engineers to rely exclusively on final production statistics. Instead, it provides a basis for collecting time-dependent information while the simulation is running.

       Observing a flow is only the first step. To support operational analysis, the model must also be able to react to relevant changes and preserve the information associated with them. This is where event-driven monitoring becomes important. Changes in flow rate can trigger user-defined logic that records the event and stores relevant information in a structured form. The resulting records can then be examined during or after the simulation to reconstruct the evolution of a residual flow. The FlowDiscrepancy component provides the foundation for this approach through its flow-monitoring functionality and, in Petroleum Refining Library version 2.2.5, its message-handling methods. By combining the component with custom Java classes, engineers can extend basic flow observation into a monitoring mechanism tailored to the requirements of a particular refinery model. The following sections explain how message handling and user-defined Java classes can be used to implement this functionality.

       Starting with Petroleum Refining Library version 2.2.5, the FlowDiscrepancy component provides a message storage mechanism that can be used to implement custom flow monitoring and event tracking. The key feature of this mechanism is its flexibility: messages can be instances of any user-defined Java class. No specific message class, interface, or predefined data structure is required. This allows model developers to define the information they need to capture and retain when monitoring flow behavior. PRL 2.2.5 allows the FlowDiscrepancy component to store user-defined message objects without requiring a specific message class or interface. Developers can therefore define their own data structures for recording flow events and the information needed for subsequent analysis. The message storage mechanism remains independent of the application-specific monitoring logic.

       In refinery simulation, different monitoring tasks may require different types of information. A simple flow-rate event may require only a timestamp and the current flow rate, while a more advanced monitoring application may need additional information about the material, the monitored location, or the operating conditions associated with the event. With the PRL message mechanism, developers can define Java classes tailored to these requirements. Each message can contain any fields and supporting logic appropriate to the application. For example, a custom message class used for residual-flow monitoring could store:
       - the time at which a flow event occurred;
        - the observed flow rate;
        - the change in flow rate relative to the previous observation;
        - an identifier for the monitored flow or component;
        - additional information required for subsequent analysis.
       These fields are illustrative rather than mandatory. The actual message structure depends entirely on the monitoring requirements and the information available to the model. This approach keeps the message format independent of the FlowDiscrepancy component itself. The same message storage mechanism can therefore support different monitoring applications without requiring the library to define a separate message type for each use case.

       The message mechanism also establishes a clear separation between the library infrastructure and application-specific behavior. The FlowDiscrepancy component provides the message storage facility, while custom Java classes determine what information to collect, how to represent it, and when a message should be created. This makes it possible to extend the component's monitoring capabilities without embedding every application-specific rule into the library. In a dynamic loss monitoring application, for example, user-defined logic can respond to relevant changes in flow rate, construct a message containing the observed event and its context, and add that message to the component's message store. The resulting collection can then be retrieved by other parts of the model for display, analysis, or further processing. Because the messages are user-defined objects, the application can preserve structured information rather than reducing every event to a text string. This flexibility is particularly valuable when monitoring residual flows of high-value refinery components. The model developer can determine which details are necessary to investigate flow diversions and adapt the message structure as monitoring requirements evolve. The message mechanism does not determine the cause of a flow diversion by itself. Instead, it provides a flexible way to preserve event-related information that can later be correlated with the state of tank farms, product mixers, process units, and other components in the refinery model.

      The message storage mechanism introduced in Petroleum Refining Library 2.2.5 provides the foundation for implementing dynamic flow monitoring. By combining the FlowDiscrepancy component with custom Java classes, developers can capture flow-rate changes, record relevant events, and preserve information for subsequent analysis. When a monitored flow changes, user-defined logic can create a message containing relevant data, such as the simulation time, current flow rate, magnitude of the change, and monitored location. The message structure is entirely application-specific and can be extended to include any additional information available in the model. Recorded messages can be retrieved by other model components for display, statistical analysis, or further processing. For example, an event history can help identify when a residual flow appears, how its rate evolves, and how long the flow persists. Recorded flow events can serve as input for custom calculations of the material diverted into a residual flow. Such estimates require flow-rate data, simulation timestamps, and an appropriate calculation method that accounts for changes in flow rate over time.

       Detecting a residual flow is only the first step in understanding why valuable material cannot reach its intended destination. To investigate the cause, engineers can correlate flow events recorded by FlowDiscrepancy with the operating conditions and statistics of other components in the refinery simulation model. For example, if a valuable intermediate stream is diverted into a residual flow, the relevant tank farm may have reached its storage capacity, or a ProductMixer may be unable to accept additional material because of its throughput limitations. Equipment downtime and production plan imbalances can create similar situations.
By examining the state of these components at the time of a flow-rate change, engineers can identify potential constraints and narrow down the causes that require further investigation. This approach does not guarantee automatic identification of the root cause. Instead, it provides a structured way to investigate flow diversion using event timestamps, flow statistics, and information about connected process units, tank farms, and blending systems. Combining dynamic flow monitoring with component-level statistics makes the refinery digital twin more useful for operational analysis. Rather than observing only the final quantity of residual material, engineers can investigate when flow diversion occurred and which operating constraints may have contributed to it.

       Dynamic flow monitoring in AnyLogic refinery simulation helps engineers investigate residual flows and potential refinery bottlenecks. By combining the FlowDiscrepancy component in Petroleum Refining Library 2.2.5 with custom Java classes and message storage, developers can record flow events and analyze operating conditions that may affect refinery production plans.

1. What is dynamic loss monitoring in AnyLogic refinery simulation?
Dynamic loss monitoring tracks changes in residual flows during simulation execution, helping engineers identify when valuable intermediate products are diverted from their intended routes.

2. What is the FlowDiscrepancy component in Petroleum Refining Library?
FlowDiscrepancy is a PRL component that provides flow-monitoring functionality and message storage capabilities. It can be used as a foundation for implementing custom monitoring solutions in AnyLogic refinery models.

3. Which version of Petroleum Refining Library supports the message-handling functionality?
The message-handling functionality described in this article is available starting with Petroleum Refining Library version 2.2.5.

4. Can FlowDiscrepancy store custom Java objects?
Yes. Its message storage mechanism accepts objects of any user-defined Java class. No specific message class or interface is required.

5. How can residual flows help identify refinery bottlenecks?
Residual-flow events can be correlated with the operating conditions of tank farms, product mixers, and other downstream components. This helps engineers investigate potential capacity constraints and other causes of flow diversion.

6. Does FlowDiscrepancy automatically identify the cause of a material loss?
No. The component provides a foundation for monitoring flow changes and storing event-related information. Identifying potential causes requires additional analysis of connected components, operating conditions, and model statistics.

7. Can dynamic flow monitoring improve refinery production planning?
It can provide additional information about flow diversions and downstream constraints, helping engineers investigate discrepancies between planned production and available storage, blending, and shipment capacity.

8. Can the monitoring logic be customized for different refinery models?
Yes. Developers can define custom Java message classes and application-specific monitoring logic to meet the analytical requirements of individual refinery simulation models.