Java Interfaces for Flexible Refinery Simulation in AnyLogic
Java interfaces for refinery simulation in AnyLogic can separate flow information from physical flow connections. In refinery simulation, flow statistics are normally collected from streams directly connected to a model component. This works well when the physical flow structure matches the structure required for analysis. However, production planning may require several flows to be combined upstream before they reach the Tank Farm. The Tank Farm then receives a single physical flow while still needing detailed information about the original flows. This creates a need to separate physical flow connections from the source of flow information.
Java Interfaces for Separating Flow Information in Refinery Simulation
The key architectural principle in refinery simulation in AnyLogic is to separate where material physically flows from where flow information is obtained. Java interfaces allow a downstream component to request the information it needs through a common interface rather than depend on a specific physical connection or data source.
Designing the FlowProvider Java Interface
The FlowProvider architecture is organized as a hierarchy of Java interfaces that reflects the main flow configurations used in refinery simulation models within the Petroleum Refining Library.
FlowsProvider defines the common operations for multiple flows, including total and individual flow rates, product identification, and flow contributions.
InputFlowsProvider extends this functionality with input-flow mixing factors and ratios, while OutputFlowsProvider adds separation factors and ratios for output flows.
SingleFlowProvider is used for components whose flow structure is based on a single stream.
This hierarchy allows each Petroleum Refining Library component to implement the flow abstraction that matches its physical behavior while sharing a common contract for flow information. As a result, downstream components depend on the interface rather than on a specific provider implementation or physical connection.
FlowsProvider defines the common operations for multiple flows, including total and individual flow rates, product identification, and flow contributions.
InputFlowsProvider extends this functionality with input-flow mixing factors and ratios, while OutputFlowsProvider adds separation factors and ratios for output flows.
SingleFlowProvider is used for components whose flow structure is based on a single stream.
This hierarchy allows each Petroleum Refining Library component to implement the flow abstraction that matches its physical behavior while sharing a common contract for flow information. As a result, downstream components depend on the interface rather than on a specific provider implementation or physical connection.
Implementing FlowProvider in Petroleum Refining Simulation Components
The FlowProvider interfaces are implemented in the Statistics classes of the main Petroleum Refining Library refinery simulation components, according to their flow configuration. Components with multiple incoming or outgoing streams use the corresponding InputFlowsProvider and OutputFlowsProvider, while components with a single stream can use SingleFlowProvider. For example, a Tank Farm supports both incoming and outgoing flow providers, while a ShipmentNode uses InputFlowsProvider for multiple incoming flows and SingleFlowProvider for its single output flow. A Separator combines these patterns by using SingleFlowProvider for its input and OutputFlowsProvider for its multiple outputs. This approach provides a consistent flow-information architecture across the library while matching the specific flow structure of each component. The detailed implementation and flow configuration of individual components are described in the dedicated Petroleum Refining Library articles for these components.
Using Shipment Node as a Flow Provider in AnyLogic Refinery Simulation
Consider an AnyLogic refinery simulation model where several Process Units supply the same product to a Tank Farm. In the original configuration, the individual flows enter the Tank Farm directly, allowing it to collect detailed statistics for each stream. When a ShipmentNode is introduced for production planning and production plan analysis, these flows are combined before entering the Tank Farm, resulting in a single physical flow. To preserve the original flow information, the Tank Farm's Input Flow Provider is assigned to the ShipmentNode. The Tank Farm continues to receive one physical flow while obtaining the original flow structure through the InputFlowsProvider interface. The Tank Farm therefore does not need to know where the flow information is collected, and its internal calculations remain unchanged.
Benefits of FlowProvider for Refinery Simulation
The FlowProvider approach separates the physical structure of the model from the source of flow information.
This provides several practical benefits for refinery simulation:
Preserved flow detail — original flow structure remains available after physical aggregation.
Loose coupling — components depend on an interface rather than a specific provider implementation.
Flexible refinery modeling — physical connections and statistical sources can be changed independently.
Extensibility — new flow providers can be introduced without modifying existing component logic.
This is particularly useful in complex AnyLogic refinery simulation models, where production planning, storage, blending, and shipment operations may require different views of the same material flows.
This provides several practical benefits for refinery simulation:
Preserved flow detail — original flow structure remains available after physical aggregation.
Loose coupling — components depend on an interface rather than a specific provider implementation.
Flexible refinery modeling — physical connections and statistical sources can be changed independently.
Extensibility — new flow providers can be introduced without modifying existing component logic.
This is particularly useful in complex AnyLogic refinery simulation models, where production planning, storage, blending, and shipment operations may require different views of the same material flows.
Physical Flow vs. Information Flow in Refinery Simulation
In a refinery simulation model, physical flow and flow information do not always need to follow the same structure. Consider a Tank Farm supplied by several Process Units. In the original configuration, each physical flow enters the Tank Farm directly, so the Tank Farm can collect detailed statistics for each incoming stream. After introducing a ShipmentNode for production plan analysis, the flows are first combined in the ShipmentNode and only one physical flow enters the Tank Farm. However, the Tank Farm can still obtain the original flow structure through the Shipment Node configured as its Input Flow Provider.
This creates two independent paths:
This creates two independent paths:
Physical flow: Process Units → Shipment Node → Tank Farm
Flow information: Process Units → Shipment Node → InputFlowsProvider → Tank Farm
The Tank Farm therefore works with one physical flow but multiple original flow records for analysis. Its calculations do not depend on where the information is collected, allowing physical connectivity and information flow to evolve independently.Conclusion
Java interfaces provide a flexible way to decouple flow information from physical connections in AnyLogic refinery simulation models. The FlowProvider architecture allows a Tank Farm to preserve detailed flow information even when physical flows are aggregated upstream by a Shipment Node. This approach keeps component logic independent from the location of flow statistics and provides a flexible foundation for extending Petroleum Refining Library components.
FAQ
1. What is the purpose of the FlowProvider interface in refinery simulation?
The FlowProvider interface separates flow information from physical flow connections, allowing a component to obtain flow statistics from another point in the model without changing its internal logic.
2. What flow information can a FlowProvider provide?
It can provide information such as total and individual flow rates, flow structure, product identification, flow contributions, mixing factors, separation factors, and related flow statistics.
3. Why are separate InputFlowsProvider and OutputFlowsProvider interfaces used?
They reflect different flow configurations in refinery components. InputFlowsProvider provides functionality related to incoming flows and their mixing, while OutputFlowsProvider handles outgoing flows and their separation characteristics.
4. When is SingleFlowProvider used?
SingleFlowProvider is used for components that work with a single flow, providing access to the flow itself and its associated valve and flow parameters.
5. Can a Tank Farm use a different source of flow statistics than its physical inputs?
Yes. The Tank Farm has an Input Flow Provider property that can be assigned to another component implementing InputFlowsProvider, such as a Shipment Node.
6. How does a Shipment Node preserve the original flow structure?
Although the Tank Farm physically receives one combined flow from the Shipment Node, it can obtain the original individual-flow structure through the Shipment Node used as its Input Flow Provider.
7. Does the Tank Farm need to know where its flow information comes from?
No. The Tank Farm works with the InputFlowsProvider interface and does not depend on the specific implementation or physical location of the provider.
8. What is the main architectural benefit of this approach?
It separates physical connectivity from information connectivity, allowing the physical flow structure and the source of flow statistics to evolve independently.
The FlowProvider interface separates flow information from physical flow connections, allowing a component to obtain flow statistics from another point in the model without changing its internal logic.
2. What flow information can a FlowProvider provide?
It can provide information such as total and individual flow rates, flow structure, product identification, flow contributions, mixing factors, separation factors, and related flow statistics.
3. Why are separate InputFlowsProvider and OutputFlowsProvider interfaces used?
They reflect different flow configurations in refinery components. InputFlowsProvider provides functionality related to incoming flows and their mixing, while OutputFlowsProvider handles outgoing flows and their separation characteristics.
4. When is SingleFlowProvider used?
SingleFlowProvider is used for components that work with a single flow, providing access to the flow itself and its associated valve and flow parameters.
5. Can a Tank Farm use a different source of flow statistics than its physical inputs?
Yes. The Tank Farm has an Input Flow Provider property that can be assigned to another component implementing InputFlowsProvider, such as a Shipment Node.
6. How does a Shipment Node preserve the original flow structure?
Although the Tank Farm physically receives one combined flow from the Shipment Node, it can obtain the original individual-flow structure through the Shipment Node used as its Input Flow Provider.
7. Does the Tank Farm need to know where its flow information comes from?
No. The Tank Farm works with the InputFlowsProvider interface and does not depend on the specific implementation or physical location of the provider.
8. What is the main architectural benefit of this approach?
It separates physical connectivity from information connectivity, allowing the physical flow structure and the source of flow statistics to evolve independently.