Petroleum Refining Library Key Features
Petroleum Refining Library (PRL) is an additional palette library for Anylogic. It is based on Anylogic Fluid library and helps to build a different kind of imitation models for Oil & Gas refining. Like Anylogic, Petroleum Refining Library fully supports Java.
Base Petroleum Refining Library features:
• building a different kind of imitation models like "digital twins" in Oil & Gas industry;
• performing an accurate "balance" calculations of incoming flows and resulting products;
• make detailed optimization flows calculations within Oil & Gas refining;
• taking into account all unique features of specific Oil & Gas companies for maximum accurate forecasting;
• setting and solving any tasks of the current processing management in Oil & Gas industry.
More detailed information is available in our Knowledge and Solutions sections.
Base Petroleum Refining Library features:
• building a different kind of imitation models like "digital twins" in Oil & Gas industry;
• performing an accurate "balance" calculations of incoming flows and resulting products;
• make detailed optimization flows calculations within Oil & Gas refining;
• taking into account all unique features of specific Oil & Gas companies for maximum accurate forecasting;
• setting and solving any tasks of the current processing management in Oil & Gas industry.
More detailed information is available in our Knowledge and Solutions sections.
Base Petroleum Refining Library includes the following agents:
Source that generates and controls incoming material flows. The Source supports multiple planning modes (daily and monthly) and is capable of reading production plans from a database. It provides mechanisms for flow rate control,
including smoothing of monthly plan transitions and automatic recalculation of output rates.
Source that generates and controls incoming material flows. The Source supports multiple planning modes (daily and monthly) and is capable of reading production plans from a database. It provides mechanisms for flow rate control,
including smoothing of monthly plan transitions and automatic recalculation of output rates.
The Source agent allows to:
• set an arbitrary number of oil, gas and unstable natural gas liquid sources, as well as daily and monthly plans for the supply of hydrocarbons;
• generation of incoming material flows (e.g., oil, NGL, gas);
• perform "smoothing" of monthly oil, gas and condensate flows to ensure smooth transitions from one value to another;
• establish user-defined plans, as well as limit the rate of their receipt at arbitrary points in time;
• collect various statistics on the performance of sources and the extent to which they have fulfilled their plans.
• set an arbitrary number of oil, gas and unstable natural gas liquid sources, as well as daily and monthly plans for the supply of hydrocarbons;
• generation of incoming material flows (e.g., oil, NGL, gas);
• perform "smoothing" of monthly oil, gas and condensate flows to ensure smooth transitions from one value to another;
• establish user-defined plans, as well as limit the rate of their receipt at arbitrary points in time;
• collect various statistics on the performance of sources and the extent to which they have fulfilled their plans.
Process unit is an agent, that represents a Process Units in the Oil & Gas industry capable of performing flow-splitting operations such as Rectification, Catalytic Reforming and similar processes. This agent provides flexible configuration options to simulate various types of Process Units. Process unit agent allows user to set a lot of different kind of options, which allow to configure it with maximum accuracy for any Oil & Gas specificity.
These settings include:
Optimization algorithm for best separating the incoming flow between Process Unit lines. Petroleum Refining Library contains both automatic and manual algorithms for separating incoming flow across Process Units lines. The automatic algorithm takes into account multiple conditions, such as minimum and maximum each line loads, lines states (whether a line is under repair), the composition of inner flows, and their effect on minimum or maximum line load, among others. Alternatively, there is a manual algorithm, where the results of separation along the lines are independently redirected by the user.
If the Process Unit entering flow exceeds maximum load, the “residual” flow (that is not accepted) can be withdrawn from the Process Unit and sent to another node of the refining. Additional requirements (for example minimum flow to valves) can be established for residual flow, which completely replicates the operation of a real processing Process Unit.
Process Unit agent also has the ability to automatically control the modes, depending on the established pumping plans. The selection of modes can be carried out by the Process Units automatically (in conjunction with the control agent) or manually (after the user's click). The key calculation element of every oil and gas processing Process Units are the "recipes". Recipes are the rules that relates the mass of the incoming flow to the outgoing flows of semi-products and products, as well as the flow of losses. The recipes affect the output flows values and represent the separation coefficients.
Optimization algorithm for best separating the incoming flow between Process Unit lines. Petroleum Refining Library contains both automatic and manual algorithms for separating incoming flow across Process Units lines. The automatic algorithm takes into account multiple conditions, such as minimum and maximum each line loads, lines states (whether a line is under repair), the composition of inner flows, and their effect on minimum or maximum line load, among others. Alternatively, there is a manual algorithm, where the results of separation along the lines are independently redirected by the user.
If the Process Unit entering flow exceeds maximum load, the “residual” flow (that is not accepted) can be withdrawn from the Process Unit and sent to another node of the refining. Additional requirements (for example minimum flow to valves) can be established for residual flow, which completely replicates the operation of a real processing Process Unit.
Process Unit agent also has the ability to automatically control the modes, depending on the established pumping plans. The selection of modes can be carried out by the Process Units automatically (in conjunction with the control agent) or manually (after the user's click). The key calculation element of every oil and gas processing Process Units are the "recipes". Recipes are the rules that relates the mass of the incoming flow to the outgoing flows of semi-products and products, as well as the flow of losses. The recipes affect the output flows values and represent the separation coefficients.
Process Unit agent also includes many additional fields that allow to specify any extra features of their work. For example, the "Link" field enables to set the connection option of a particular Process Unit line to another one. If any line uses stable condensate, which may come from one of the lines of the previous Process Unit, this must be taken into account in the calculations. Moreover, this connection may vary over time.
Accumulative Tank Farm is advanced park agent, that contains many options, which are necessary for "cumulative" reservoir parks. This agent implements procedures of accumulation, passportization (compounding), and shipment of products. In addition, Accumulative Tank Farm contains built-in mechanisms for tracking product shipment plans. Determination of arbitrary duration of compounding and passportization of products, including taking into account weekends and holidays, shipping at an arbitrary speed and only on working days. As a rule, a shipment always implements one of three algorithms: as quickly as possible, by days (in accordance with a set schedule) or evenly throughout the month (for continuous mixing with other products). Accumulative Tank Farm and Shipment Node agents supports all these algorithms.
The execution of plans is implemented in Accumulative Tank Farm by using the "requests" mechanism. An request is a requirement transmitted from the Accumulative Tank Farm to the Process Unit, containing the required mass and it’s purpose. Accumulative Tank Farm implements four types of purposes:
• priority A: additional mass to fulfill the product shipment plan (received from ShipmentNode agent),
• priority B: additional mass to fulfill the plan for the next month (creating reserves),
• priority C: additional loading of the active tank to the minimum acceptable level,
• priority D: additional user mass.
• priority A: additional mass to fulfill the product shipment plan (received from ShipmentNode agent),
• priority B: additional mass to fulfill the plan for the next month (creating reserves),
• priority C: additional loading of the active tank to the minimum acceptable level,
• priority D: additional user mass.
Flowing Tank Farm is an advanced park agent, that characterized by continuous inflows and outflows that fill and unload parallel connected tank (called "maps"), Flowing Tank Farm is used for "smoothing" outgoing flow products. Every Flowing Tank Farm can operate in two different "smoothing" flow modes.
Mode 1: The out speed (Vout(t)) at each moment is determined automatically by the out speed at the previous moment (Vout(t-1)) and the maximum out speed change per step (∆Vout). It also takes into account restrictions on the maximum (Vmax) and minimum (Vmin) values of out speed. This mode is usually used when Flowing Tank Farm is set at the end of the scheme, and the outflow goes to a pipeline. In this case, the minimum and maximum pumping speeds are determined by the performance of the pumping equipment, and the maximum speed change per simulation step is dictated by the need for the tanks to "breathe," as well as the inadmissibility of excessive hydrodynamic effects on the receiving gas pipeline.
Mode 2: Flowing Tank Farm is located within the scheme and also performs the function of "smoothing" the outgoing flow. However, in this case, the out speed flow is entirely determined by the restrictions imposed by subsequent nodes (for example, the total capacity of the Process Units located behind Flowing Tank Farm).
Mode 1: The out speed (Vout(t)) at each moment is determined automatically by the out speed at the previous moment (Vout(t-1)) and the maximum out speed change per step (∆Vout). It also takes into account restrictions on the maximum (Vmax) and minimum (Vmin) values of out speed. This mode is usually used when Flowing Tank Farm is set at the end of the scheme, and the outflow goes to a pipeline. In this case, the minimum and maximum pumping speeds are determined by the performance of the pumping equipment, and the maximum speed change per simulation step is dictated by the need for the tanks to "breathe," as well as the inadmissibility of excessive hydrodynamic effects on the receiving gas pipeline.
Mode 2: Flowing Tank Farm is located within the scheme and also performs the function of "smoothing" the outgoing flow. However, in this case, the out speed flow is entirely determined by the restrictions imposed by subsequent nodes (for example, the total capacity of the Process Units located behind Flowing Tank Farm).
Control is an agent that provides a control interface for managing and executing control commands. The agent functionality is divided into two main groups:
1) Dynamic model control: manages dynamic control parameters (i.e., parameters that can change during simulation runtime) across the entire model.
2) Scenario lifecycle management: handles creation, persistence, and replay of scenarios representing sequences of control command changes.
The class maintains a collection of ControlCommand objects that represent configurable parameters and executable actions available in the control UI. The ControlCommand collection is defined by the user at model design time. Each element must provide an overridden execute() method that defines the changes to be applied to the model when the corresponding ControlCommand value is modified.
Dynamic model control:
- allows defining and modifying runtime control parameters
- supports parameters such as operating mode orientation, flow rate limits, target utilization levels, and other control variables
- propagates user changes from the UI to the model via ControlCommand execution
- ensures consistent synchronization between UI state and internal model state
Scenario lifecycle management:
1 Creation (recording mode):
- captures all changes of ControlCommand values during simulation runtime
- records only changes performed via the Control agent; state changes in other agents are not tracked (such agents must be integrated via Control if tracking is required)
- for each change, stores the simulation time and the new value
- writes changes to a JSON scenario file located in scenarios\*.json
2 Persistence:
- stores recorded scenarios in a structured and reusable format
- allows scenarios to be reused across simulation runs
3 Replay:
- loads a previously recorded scenario file
- applies stored command changes at corresponding simulation timestamps
- reproduces the exact sequence of control actions and parameter updates
This approach ensures deterministic, reproducible, and debuggable simulation runs.
1) Dynamic model control: manages dynamic control parameters (i.e., parameters that can change during simulation runtime) across the entire model.
2) Scenario lifecycle management: handles creation, persistence, and replay of scenarios representing sequences of control command changes.
The class maintains a collection of ControlCommand objects that represent configurable parameters and executable actions available in the control UI. The ControlCommand collection is defined by the user at model design time. Each element must provide an overridden execute() method that defines the changes to be applied to the model when the corresponding ControlCommand value is modified.
Dynamic model control:
- allows defining and modifying runtime control parameters
- supports parameters such as operating mode orientation, flow rate limits, target utilization levels, and other control variables
- propagates user changes from the UI to the model via ControlCommand execution
- ensures consistent synchronization between UI state and internal model state
Scenario lifecycle management:
1 Creation (recording mode):
- captures all changes of ControlCommand values during simulation runtime
- records only changes performed via the Control agent; state changes in other agents are not tracked (such agents must be integrated via Control if tracking is required)
- for each change, stores the simulation time and the new value
- writes changes to a JSON scenario file located in scenarios\*.json
2 Persistence:
- stores recorded scenarios in a structured and reusable format
- allows scenarios to be reused across simulation runs
3 Replay:
- loads a previously recorded scenario file
- applies stored command changes at corresponding simulation timestamps
- reproduces the exact sequence of control actions and parameter updates
This approach ensures deterministic, reproducible, and debuggable simulation runs.
ProductMixer is an advanced product mixing agent, that allows for the optimal mixing of input flows and product additives to create a desired product (such as petrol, kerosene, etc.). It is known that the creation of most products is accompanied by a number of requirements (such as sulfur content, saturated vapor pressure, aromatics, etc.). This agent takes these requirements into account and mixes incoming flows in an optimal way to ensure their simultaneous fulfillment. For example, It is known that automobile petrol production characterized by a number of requirements, for example: octane number (ON im), saturated vapor pressure (SVP), aromatics and many others. Each of incoming flow, that are used for petrol production, has own values of the requirement parameters. Sometimes, no single mixture variant of the incoming flows allows to meet all requirements at the same time. In this case, we can use a special balance additives, for example Methyl tert-butyl ether (MTBE). However, due to the high cost of additive, it is desirable to minimize use MTBE and to maximize result product. Take a look at the picture below. It schematically shows how Product Mixer allows to link enter, exit and residual flows and estimate the amount of product.
FlowQuota controls and enforces flow quotas for product pumping over defined time intervals. Tracks the accumulated flow within a rolling time window (e.g., daily or monthly) and ensures that operations do not exceed specified capacity limits. Used to define external constraints on product transfer volumes and to model technological limitations such as equipment capacity (e.g., pumping systems). Once the quota is reached, the internal valve is closed to stop further flow. Any unused portion of the quota is not carried over to the next period.
ShipmentNode represents a shipment control node typically located at the beginning or end of a production flow scheme.
Placement at the beginning of the scheme enables independent control of incoming flows without direct reliance on the Source agent. Placement at the end of the scheme enables execution tracking and control of product shipment plans
in daily, monthly, or other aggregation periods. Supports configurable shipment execution algorithms, including uniform distribution,
maximum-throughput shipment strategies, plan over fulfillment handling, working-hour restrictions, and other operational constraints. Supports automatic collection and storage of operational statistics in the internal database.
Placement at the beginning of the scheme enables independent control of incoming flows without direct reliance on the Source agent. Placement at the end of the scheme enables execution tracking and control of product shipment plans
in daily, monthly, or other aggregation periods. Supports configurable shipment execution algorithms, including uniform distribution,
maximum-throughput shipment strategies, plan over fulfillment handling, working-hour restrictions, and other operational constraints. Supports automatic collection and storage of operational statistics in the internal database.
Exporter is responsible for periodic export of simulation results. Collects model output data during simulation runtime and writes it at a specified frequency to external targets such as Excel files or database systems. Supports exporting data from Source}, Process Unit, and Tank Farm agents based on configurable templates. Provides options to sort exported results, exclude specific objects, and include additional rows with intermediate statistics and aggregated values.