DOWNHOLE VALVE OPTIMIZATION FOR PUMP INTAKE PRESSURE USING MACHINE LEARNING

Description

BACKGROUND

Various operations are performed at a well site during the lifetime of a producing well to maintain hydrocarbon recovery. Wells that produce from more than one zone may use a downhole valve or choke in hydraulic communication with one or more zones to control the flow from each of the zones. Electrical submersible pumps (ESPs) in hydraulic communication with the downhole chokes may provide hydraulic lift to the produced fluids. The downhole chokes may be used to control the flow from each zone to the inlet of the ESP. The settings of the downhole chokes and the operational conditions of the ESP may be adjusted to decrease risk of production problems such as production losses, and to increase operational efficiencies.

SUMMARY

This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in limiting the scope of the claimed subject matter.

This disclosure presents, in accordance with one or more embodiments, a method that includes obtaining static well data for a well. The static well data describes one or more well design parameters of the well. The method includes obtaining dynamic well data for the well. The dynamic well data describes one or more well properties that change over time. The method includes obtaining first choke index setting data regarding a first choke disposed in a producing zone of interest of the well. The method includes generating, by a computer processor, first predicted electrical submersible pump (ESP) input data for a first ESP in hydraulic connection with the first choke based on the static well data, the dynamic well data, and the first choke index setting data using a recurrent neural network. The method includes determining, by the computer processor, well performance data for the well based on the first predicted ESP input data. The method includes determining, by the computer processor, well operations for the well based on the well performance data and transmitting, by the computer processor and to a control system coupled to the well, a command that causes the well operations to be performed at the well.

This disclosure presents, in accordance with one or more embodiments, a system that includes a well control system coupled to a well at a well site. The well includes a plurality of choke components that are installed in a wellbore. The system includes a well performance manager coupled to the well control system. The well performance manager includes a computer processor and the well performance manager is configured to perform a method. The method includes obtaining static well data for a well. The static well data describes one or more well design parameters of the well. The method includes obtaining dynamic well data for the well. The dynamic well data describes one or more well properties that change over time. The method includes obtaining first choke index setting data regarding a first choke included in the plurality of choke components. The first choke is disposed in a producing zone of interest of the well. The method includes generating first predicted electrical submersible pump (ESP) input data for a first ESP in hydraulic connection with the first choke based on the static well data, the dynamic well data, and the first choke index setting data using a recurrent neural network. The method includes determining well performance data for the well based on the first predicted ESP input data and determining well operations for the well based on the well performance data. The method includes transmitting to the well control system a command that causes the well operations to be performed at the well.

This disclosure presents, in accordance with one or more embodiments, a non-transitory computer-readable memory including computer-executable instructions stored thereon that, when executed on a processor, cause the processor to perform various steps. The steps include obtaining static well data for a well. The static well data describes one or more well design parameters of the well. The steps include obtaining dynamic well data for the well. The dynamic well data describes one or more well properties that change over time. The steps include obtaining first choke index setting data regarding a first choke disposed in a producing zone of interest of the well. The steps include generating first predicted electrical submersible pump (ESP) input data for a first ESP in hydraulic connection with the first choke based on the static well data, the dynamic well data, and the first choke index setting data using a recurrent neural network. The steps include determining well performance data for the well based on the first predicted ESP input data. The steps include determining well operations for the well based on the well performance data and transmitting to a control system coupled to the well a command that causes the well operations to be performed at the well.

Other aspects and advantages of the claimed subject matter will be apparent from the following description and the appended claims.

BRIEF DESCRIPTION OF DRAWINGS

Specific embodiments of the disclosed technology will now be described in detail with reference to the accompanying figures. Like elements in the various figures are denoted by like reference numerals for consistency.

FIG. 1 shows systems in accordance with one or more embodiments.

FIG. 2A, FIG. 2B, FIG. 2C, and FIG. 2D show a system in accordance with one or more embodiments.

FIG. 3 shows a system in accordance with one or more embodiments.

FIG. 4 depicts a workflow, in accordance with one or more embodiments.

FIG. 5 depicts a neural network, in accordance with one or more embodiments.

FIG. 6A depicts a recurrent neural network, in accordance with one or more embodiments.

FIG. 6B depicts an unrolled recurrent neural network, in accordance with one or more embodiments.

FIG. 6C depicts a long short-term memory network, in accordance with one or more embodiments.

FIG. 7 shows an example in accordance with one or more embodiments.

FIG. 8 shows a flowchart in accordance with one or more embodiments.

FIG. 9 shows a computer system in accordance with one or more embodiments.

DETAILED DESCRIPTION

In the following detailed description of embodiments of the disclosure, numerous specific details are set forth in order to provide a more thorough understanding of the disclosure. However, it will be apparent to one of ordinary skill in the art that the disclosure may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

Throughout the application, ordinal numbers (e.g., first, second, third, etc.) may be used as an adjective for an element (i.e., any noun in the application). The use of ordinal numbers is not to imply or create any particular ordering of the elements nor to limit any element to being only a single element unless expressly disclosed, such as using the terms “before,” “after,” “single,” and other such terminology. Rather, the use of ordinal numbers is to distinguish between the elements. By way of an example, a first element is distinct from a second element, and the first element may encompass more than one element and succeed (or precede) the second element in an ordering of elements.

Regarding the figures described herein, when using the term “down” the direction is toward or at the bottom of a respective figure and “up” is toward or at the top of the respective figure. “Up” and “down” are oriented relative to a local vertical direction. In the oil and gas industry, one or more activities take place in a vertical, substantially vertical, deviated, substantially horizontal, or horizontal well. Therefore, one or more figures may represent an activity in deviated or horizontal wellbore configuration. “Uphole” or “upper” may refer to objects, units, or processes that are positioned relatively closer to the surface entry in a wellbore than another. “Downhole” or “lower” may refer to objects, units, or processes that are positioned relatively farther from the surface entry in a wellbore than another. Measured depth (MD) is the length of the wellbore. True vertical depth (TVD) is the vertical distance from a point in the well at a location of interest to a reference point on the surface.

In general, embodiments of the disclosure include systems and methods for determining a well performance optimization using machine learning (ML). In some embodiments, for example, a well performance optimization may be selected based on predicted well performance inputs that include various well performance considerations. The considerations may be based on real-time data, recent data, and historical data from well performance such as well production flowrate, well production temperature, electrical submersible pump (ESP) data, etc., and from inflow control valve, interval control valve (ICV, hereafter choke) index setting data such as those from zone control chokes, etc. As such, well performance optimization may be a complex process based on the variables from static well data, dynamic well data, ESP data, and choke data. Accordingly, some embodiments include a well performance manager that may be a smart system or expert system that automatically predicts well performance, generates well performance scenarios, selects well performance scenarios, then selects priorities for implementing the scenarios. A well performance manager may be an artificial intelligence entity operation on a well management network (e.g., as a network controller) that performs such functionality.

Moreover, some embodiments include a well performance manager with self-decision functionality that operates independently and with flexibility. For example, the well performance manager may perform a learning process that detects well performance issues in oil and gas wells. For example, a well performance manager may detect well performance problems, such as a flowrate discrepancy between a predicted flowrate and a measured flowrate, that can lead to well performance issues. Manual inspections or rule-based systems may be used for identifying these issues. Manual approaches may be time-consuming, subjective, and less accurate. The disclosed system and method use a machine-learned model and predictive modelling of a well performance manager along with static and dynamic well data, inflow control valve index data, and ESP data to predict ESP input data, well performance data, and to recommend one or more well operations.

The well performance manager may determine statistical trends based on well data (such as static and dynamic data), inflow control valve (choke) index data, and/or ESP operational data. Likewise, a well performance manager may determine one or more additional values or weights for arranging the well performance operations based on the priority ranking. This flexibility may accommodate changes in real time, e.g., on-the-fly observed matters, like health, environment, safety, and production concerns. Historical well data builds trends and improves robustness of various well performance plans by advising about possible issues. These different factors may provide the data inputs that are adjusted over time to optimize a particular performance operation criterion.

Furthermore, some embodiments use one or more machine-learning algorithms to determine which data inputs to use for a well performance criterion. For example, different sets of data inputs may maximize operational efficiency and hydrocarbon production at one or more wells, while also minimizing operational costs for those same wells. For example, an optimized set of data inputs may be a subset of a larger aggregated set of data inputs identified over a well management network. These aggregated data inputs may be recognized by a well performance manager, where the well performance manager may prescribe different weights or significances to various data inputs. Thus, a well performance manager may provide a flexible method to accommodate multiple performance criteria (e.g., swapping importance/relevance of different data inputs that correspond to various incidents, inspection results, maintenance activities, production performances, the static well data, and the dynamic well data, etc.) in real time (as applicable) to re-arrange different well performance plans. Thus, a well performance manager may automatically readjust variables for a well performance plan based on predicting their future importance to a user. In some embodiments, a well performance plan may be updated based on real-time observed matters during actual performance of the well performance plan (e.g., in response to changing safety concerns, dynamic well data, etc.)

Some embodiments describe, as a suitable solution, a predictive model that utilizes machine-learned methods to detect performance problems such as well performance issues in oil and gas wells. Well performance refers to wellbore pressure and/or fluid communication between a first location and a second location. Pressure or fluid communication in this context is, for example, pressure variations, i.e., pressure increases or decreases, and fluid flows between the first location and the second location. Downhole isolation refers to lack of communication between the locations. Pressure and fluid communication are a performance issue when the well design calls for downhole isolation but well zone-to-zone communication happens. A suitable solution is leveraging machine-learned methods and predictive modeling with machine learning methods to improve well performance management, optimize operations, and mitigate risks in oil and gas wells applications.

Some embodiments use a data-driven approach by analyzing input variables (e.g., relevant input variables, primary input variables, and combinations of input variables) such as wellhead pressures, well flowrates, ESP input frequencies, choke index settings, and other relevant parameters, to accurately predict these outputs, namely, well performance and ESP wear. The data-driven decision making may overcome limitations of subjective or experience-based decision making. Well performance issues such as reduced hydrocarbon production may be discovered through evaluation and processing, e.g., with a machine-learned model and with quantities such as flowrate, water cut, and pressure. Some embodiments may enable proactive well management and maintenance, leading to improved operational efficiency and reduced downtime. Embodiments may detect or capture complex relationships between input variables and well performance issues and provide an output, including a ranking of outputs. For example, an output may include zone index settings and ESP maintenance intervals.

Some embodiments may be robust to noise and variability in the data for handling real-world well data that may contain uncertainties or measurement errors, thereby providing reliable predictions in diverse operational conditions. Some embodiments may include ranking of the input variables and feature engineering to extract meaningful information from a dataset. Selection of relevant features improves model performance and interpretability. The model may include practical implementation considerations, such as computational efficiency, scalability, and integration into existing well performance management systems, thereby contributing to the practicality and usability of the developed predictive model. Some embodiments include data gathered and curated to form a comprehensive dataset of problematic and non-problematic zones, wells, or equipment. The data may include the input parameters collected and preprocessed for training the model to form an accurate and reliable predictive model.

By accurately predicting well performance issues, some embodiments facilitate early detection, identification, and proactive management, enabling timely well operations (such as well interventions), choke operations (such as index changes or index setting changes), and/or ESP operations (such as frequency changes) to prevent or mitigate potential problems before they escalate. Utilizing machine-learning techniques, the machine-learning model may uncover non-linear patterns, relationships, and interactions. The proactive assessment of well performance issues may help optimize well operations, minimize production losses, reduce downtime, and improve overall operational efficiency. Some embodiments assist in optimizing well performance management practices by prioritizing maintenance activities, allocating resources effectively, and identifying potential risks before they lead to costly failures. The predictive model may provide decision support for well operators and engineers, aiding in risk mitigation strategies, resource allocation, and maintenance planning based on predicted well performance issues.

In accordance with one or more embodiments the disclosed system and method enhance the maintenance of optimal pump intake pressure for ESPs for efficient and safe extraction. One or more embodiments use a type of machine learning model known as a long short-term memory (LSTM) network to predict the outcomes of choke indexer settings on well performance, specifically focusing on intake pressure, temperature, and flow rate. LSTMs are capable of learning from sequences of data, making them particularly suited for time-series data that characterizes well operations. The LSTM-driven system can continuously learn from new data to improve its predictions over time. This adaptability makes it highly effective in dynamic well environments where conditions change frequently. The LSTM-driven system optimizes choke indexer settings using predictions from the LSTM, potentially incorporating a broader range of operational data into the decision-making process.

In accordance with one or more embodiments the disclosed system and method adapt in real time. The real-time adaptability using the LSTM-driven system offers real-time advice on choke indexer settings, leveraging the ability of the LSTM model to quickly process new information and update predictions. The LSTM-driven system allows customization to specific well characteristics and scalability across different operational scenarios without significant reconfiguration.

The LSTM-Driven downhole valve optimization system represents a significant advancement in the application of deep learning to downhole valve optimization. Its use of LSTM networks for real-time, adaptive prediction and optimization of ICV settings offers potential improvements over traditional simulation-based approaches in terms of adaptability, prediction accuracy, and operational efficiency.

FIG. 1 shows a schematic diagram in accordance with one or more embodiments. As shown in FIG. 1, FIG. 1 illustrates a well site 100 that includes a hydrocarbon reservoir (e.g., reservoir 102) located in a subsurface hydrocarbon-bearing (e.g., formation 104) and a well system 106. The formation 104 may include a porous or fractured rock formation that resides underground, below the surface of the earth or below a seabed (hereafter surface e.g., surface 108). In the case of the well system 106 being a hydrocarbon well, the reservoir 102 may include a portion of the formation 104. The formation 104 and the reservoir 102 may include different layers of rock having varying characteristics, such as varying degrees of permeability, porosity, and resistivity. In the case of the well system 106 being operated as a production well, the well system 106 may facilitate the extraction of hydrocarbons from the reservoir 102.

In some embodiments, the well system 106 includes a wellbore 120 and a well control system 126. The well control system 126 may control various operations of the well system 106, such as well production operations, well completion operations, well maintenance operations, and reservoir monitoring, assessment, and development operations. In some embodiments, the well control system 126 includes a computer system that is the same as or similar to that of computer system (e.g., a computer 902) described below in FIG. 9 and the accompanying description.

The wellbore 120 may include a bored hole that extends from the surface 108 into a target zone of the formation 104, such as the reservoir 102. An upper end of the wellbore 120, terminating at or near the surface 108, may be referred to as the “up-hole” end of the wellbore 120, and a lower end of the wellbore, terminating in the formation 104, may be referred to as the “downhole” end of the wellbore 120. The wellbore 120 may facilitate the circulation of drilling fluids during drilling operations, conveyance of produced fluids including the flow of hydrocarbon (e.g., oil and gas) production (e.g., production 128) from the reservoir 102 to the surface 108 during production operations, the injection of substances (e.g., water) into the formation 104 or the reservoir 102 during injection operations, or the communication of monitoring devices (e.g., logging tools) into the formation 104 or the reservoir 102 during monitoring operations (e.g., during in situ logging operations).

In some embodiments, during operation of the well system 106, the well control system 126 collects and records wellhead data 150 for the well system 106 and other data regarding downhole equipment and downhole sensors (e.g., using an automatic computer-controlled management system described herein.) The wellhead data 150 may include, for example, a record of measurements of wellhead pressure (P_wh) (e.g., wellhead pressures (measured pressures at the wellhead) including flowing wellhead pressure (FWHP), shut-in wellhead pressure (SIWHP)), wellhead temperature (T_wh) (e.g., including flowing wellhead temperature), wellhead production rate (Q_wh) over some or all of the life of the well system 106, and water cut data (data regarding water cut.) In some embodiments, the measurements are recorded in real time, and are available for review or use within seconds, minutes, or hours of the condition being sensed (e.g., the measurements are available within 1 hour of the condition being sensed). In such an embodiment, the wellhead data 150 may be referred to as “real-time” wellhead data. Real-time wellhead data may enable an operator of the well system 106 to assess a relatively current state of the well system 106, and to make real-time decisions regarding development of the well system 106 and the reservoir 102, such as on-demand adjustments in regulation of production flow from the well.

With respect to water cut data, the well system 106 may include one or more water cut sensors. For example, a water cut sensor may be hardware and/or software with functionality for determining the water content in oil, also referred to as “water cut.” Measurements from a water cut sensor may be referred to as water cut data and may describe the ratio of water produced from the wellbore 120 compared to the total volume of liquids produced from the wellbore 120. In some embodiments, a water-to-gas ratio (WGR) is determined using a multiphase flow meter. For example, a multiphase flow meter may use magnetic resonance information to determine the number of hydrogen atoms in a particular fluid flow. Since oil, gas and water all contain hydrogen atoms, a multiphase flow may be measured using magnetic resonance. In particular, a fluid may be magnetized and subsequently excited by radio frequency pulses. The hydrogen atoms may respond to the pulses and emit echoes that are subsequently recorded and analyzed by the multiphase flow meter.

In some embodiments, the well system 106 includes a wellhead 130. The wellhead 130 may include a rigid structure installed at the “up-hole” end of the wellbore 120, at or near where the wellbore 120 terminates at the surface 108. The wellhead 130 may include structures for supporting (or “hanging”) casing and production tubing extending into the wellbore 120. Production 128 may flow through the wellhead 130, after exiting the wellbore 120, including, for example, the casing and the production tubing. In some embodiments, the well system 106 includes flow regulating devices that are operable to control the flow of substances into and out of the wellbore 120. For example, the well system 106 may include one or more of a production valve 132 that are operable to control the flow of production 128. For example, a production valve 132 may be fully opened to enable unrestricted flow of production 128 from the wellbore 120, the production valve 132 may be partially opened to partially restrict (or “throttle”) the flow of production 128 from the wellbore 120, and production valve 132 may be fully closed to fully restrict (or “block”) the flow of production 128 from the wellbore 120.

Keeping with FIG. 1, in some embodiments, the well system 106 may include sensor devices for sensing characteristics of substances passing through the well system 106, including production 128. The characteristics may include, for example, pressure, temperature, and flowrate of production 128 flowing through the wellhead 130, or other conduits of the well system 106, after exiting the wellbore 120.

In some embodiments, the well system 106 includes a surface pressure sensor 136 operable to sense the pressure of production 128 after it exits the wellbore 120. The surface pressure sensor 136 may include, for example, a wellhead pressure sensor that senses a pressure of production 128 flowing through or otherwise located in the wellhead 130, referred to as “wellhead pressure” (P_wh). In some embodiments, the well system 106 includes a surface temperature sensor 138 operable to sense the temperature of production 128 after it exits the wellbore 120. The surface temperature sensor 138 may include, for example, a wellhead temperature sensor that senses a temperature of production 128 flowing through or otherwise located in the wellhead 130, referred to as “wellhead temperature” (T_wh). In some embodiments, the well system 106 includes a flowrate sensor 140 operable to sense the flowrate of production 128 after it exits the wellbore 120. The flowrate sensor 140 may include hardware that senses a flowrate of production 128 (Q_wh) passing through the wellhead 130.

Keeping with FIG. 1, when completing a well, one or more well completion operations may be performed prior to delivering the well to the party responsible for production or injection. Well completion operations may include casing operations, cementing operations, perforating the well, gravel packing, directional drilling, hydraulic stimulation of a reservoir region, and/or installing a production tree or wellhead assembly at the wellbore 120. Likewise, well operations may include open-hole completions or cased-hole completions. For example, an open-hole completion may refer to a well that is drilled to the top of the hydrocarbon reservoir. Thus, the well may be cased at the top of the reservoir and left open at the bottom of a wellbore. In contrast, cased-hole completions may include running casing into a reservoir region.

In one well completion example, the sides of the wellbore 120 may require support, and thus casing may be inserted into the wellbore 120 to provide such support. After a well has been drilled, casing may ensure that the wellbore 120 does not close in upon itself, while also protecting the wellstream from outside contaminants, like water or sand. Likewise, if the formation is firm, casing may include a solid string of steel pipe that is run in the well and will remain that way during the life of the well. In some embodiments, the casing includes a wire screen liner that blocks loose sand from entering the wellbore 120.

In another well operation example, a space between the casing and the untreated sides of the wellbore 120 may be cemented to hold a casing in place. This well operation may include pumping cement slurry into the wellbore 120 to displace existing drilling fluid and fill in this space between the casing and the untreated sides of the wellbore 120. Cement slurry may include a mixture of various additives and cement. After the cement slurry is left to harden, cement may seal the wellbore 120 from non-hydrocarbons that attempt to enter the wellstream. In some embodiments, the cement slurry is forced through a lower end of the casing and into an annulus between the casing and a wall of the bored hole of the wellbore 120. More specifically, a cementing plug may be used for pushing the cement slurry from the casing. For example, the cementing plug may be a rubber plug used to separate cement slurry from other fluids, reducing contamination and maintaining predictable slurry performance. A displacement fluid, such as water, or an appropriately weighted drilling fluid, may be pumped into the casing above the cementing plug. This displacement fluid may be pressurized fluid that serves to urge the cementing plug downward through the casing to extrude the cement from the casing outlet and back up into the annulus.

Keeping with well operations, some embodiments include perforation operations. More specifically, a perforation operation may include perforating casing and cement at different locations in the wellbore 120 to enable hydrocarbons to enter a wellstream from the resulting holes. For example, some perforation operations include using a perforation gun at one or more reservoir levels to produce holed sections through the casing, cement, and sides of the wellbore 120. Hydrocarbons may then enter the wellstream through these holed sections. In some embodiments, perforation operations are performed using discharging jets or shaped explosive charges to penetrate the casing around the wellbore 120.

In another well completion, a filtration system may be installed in the wellbore 120 in order to prevent sand and other debris from entering the wellstream. For example, a gravel packing operation may be performed using a gravel-packing slurry of appropriately sized pieces of coarse sand or gravel. As such, the gravel-packing slurry may be pumped into the wellbore 120 between a the slotted liner of a casing and the sides of the wellbore 120. The slotted liner and the gravel pack may filter sand and other debris that might have otherwise entered the wellstream with hydrocarbons. In another well completion, a wellhead assembly may be installed on the wellhead of the wellbore 120. A wellhead assembly may include a production tree (also called a Christmas tree) that includes valves, gauges, and other components to provide surface control of subsurface conditions of a well.

In some embodiments, a wellbore 120 includes one or more casing centralizers. For example, a casing centralizer may be a mechanical device that secures casing at various locations in a wellbore to prevent casing from contacting the walls of the wellbore. Thus, casing centralization may produce a continuous annular clearance around the casing such that cement may be used to completely seal the casing to walls of the wellbore. Without casing centralization, a cementing operation may experience mud channeling and poor zonal isolation. Examples of casing centralizers may include bow-spring centralizers, rigid centralizers, semi-rigid centralizers, and mold-on centralizers. In particular, bow springs may be slightly larger than a particular wellbore in order to provide complete centralization in vertical or slightly deviated wells. On the other hand, rigid centralizers may be manufactured from solid steel bar or cast iron with a fixed blade height in order to fit a specific casing or hole size. Rigid centralizers may perform well even in deviated wellbores regardless of any particular side forces. Semi-rigid centralizers may be made of double crested bows and operate as a hybrid centralizer that includes features of both bow-spring and rigid centralizers. The spring characteristic of the bow-spring centralizers may allow the semi-rigid centralizers to compress in order to be disposed in tight spots in a wellbore. Mold-on centralizers may have blades made of carbon fiber ceramic material that can be applied directly to a casing surface.

In some embodiments, well performance operations may also be performed at a well site. For example, well performance operations may include various operations carried out by one or more service entities for an oil or gas well during its productive life (e.g., hydraulic fracturing operations, coiled tubing, flow back, separator, pumping, wellhead and production tree maintenance, slickline, braided line, coiled tubing, snubbing, workover, subsea well performance, etc.). For example, well performance activities may be similar to well completion operations, well delivery operations, and/or drilling operations in order to modify the state of a well or well geometry. In some embodiments, well performance operations are used to provide well diagnostics, and/or manage the production of the well. With respect to service entities, a service entity may be a company or other actor that performs one or more types of oil field services, such as well operations, at a well site. For example, one or more service entities may be responsible for performing a cementing operation in the wellbore 120 prior to delivering the well to a producing entity.

In some embodiments, well performance operations may include various operations carried out by one or more automatic systems such as control systems. For example, well performance activities may be similar to sliding sleeve choke indexing operations, automatic valve operations, etc., carried out by automatic control systems. The automatic control systems may be coupled to a reservoir simulator or other well control systems or software platforms.

Turning to the reservoir simulator (e.g., a reservoir simulator 160) may include hardware and/or software with functionality for performing a well simulation (e.g., well simulations of the wellbore of one or more wells) such as storing and analyzing well logs, production data, sensor data (e.g., from a wellhead, downhole sensor devices, or flow control valves, inflow control valves, inflow control devices), and/or other types of data to generate and/or update one or more geological models of one or more reservoir regions. Geological models may include geochemical or geomechanical models that describe structural relationships within a particular geological region. Likewise, the reservoir simulator 160 may also determine changes in reservoir pressure and other reservoir properties for a geological region of interest, e.g., in order to evaluate the health of a particular reservoir during the lifetime of one or more producing wells.

While the reservoir simulator 160 is shown at a well site, in some embodiments, the reservoir simulator 160 or other components in FIG. 1 may be remote from a well site. In some embodiments, the reservoir simulator 160 is implemented as part of a software platform for the well control system 126. The software platform may obtain data acquired by a control system as inputs, which may include multiple data types from multiple sources. The software platform may aggregate the data from these systems in real time for rapid analysis. In some embodiments, the well control system 126 and the reservoir simulator 160, and/or a user device coupled to one of these systems may include a computer system that is similar to the computer system (e.g., computer 902) described below with regard to FIG. 9 and the accompanying description.

In some embodiments, the reservoir simulator 160 may include software configured with machine learning capabilities and artificial intelligence (AI) that learns from trends of the one or more parameters tracked by the well control system 126. In one or more embodiments, the AI and machine learning (ML) capabilities employed by the reservoir simulator may include any suitable algorithms and processes for predicting well behavior using historical data as input. For example, the ML models or machine-learning algorithms may include supervised algorithms, unsupervised algorithms, deep learning algorithms that use artificial neural networks (ANN), etc. More specifically, supervised ML models include classification, regression models, (support vector machines or support vector networks) etc. Unsupervised ML models include, for example, clustering models.

Turning to FIG. 2A, FIG. 2A shows a schematic diagram in accordance with one or more embodiments. FIG. 2A illustrates a well site 200 at a surface location (e.g., a surface 208). The well site includes a hydrocarbon reservoir (e.g., a reservoir 202), located in a subsurface hydrocarbon-bearing formation (e.g., a formation 204), and a well system 206. The well system includes a sub-surface system (e.g., a well sub-surface system 220) and an electrical submersible pump (ESP) system (e.g., an ESP P 214) with an ESP flow inlet (e.g., an ESP Flow Inlet I 215). As known in the art, a well with one or more zones may include a packer above and/or below the zone to isolate the zone from other zones. The well may include one or more choke components in hydraulic communication with each of the respective zones. FIG. 2A shows a formation with three zones, a lower zone (e.g., a Lower Zone L 272), a middle zone (e.g. a Middle Zone M 274), and an upper zone (e.g., an Upper Zone U 276). Each zone may have a choking component, in this example, an inflow control valve (ICV).

As known in the art, the flow control valve may be variously known as a flow control choke, an interval control valve (ICV), a flow control valve, an inflow control valve, a downhole choke, smart valve, smart control valve, a smart choke, etc. A flow control choke with only an on position and an off position may be considered an on/off valve. The Lower Zone L 272 may have a first flow control choke (a choke L 280) disposed in the lower zone. The Middle Zone M 274 may have a second flow control choke (e.g., a choke M 285) disposed in the middle zone. The Upper Zone U 276 may have a third flow control choke (e.g., a choke U 290) disposed in the upper zone. The zones are zones of interest such as zones that bear hydrocarbons.

Each choke may have a cross-sectional area that may change in increments from a closed position such as a fully-choked position to a first (1^st) choked position, to a second (2^nd) choked position, to an n^th position, and so on incrementally up to an n_max^th choked position. Each choke position may be associated with a different cross-sectional flowpath area. In this manner the flowrate may be regulated by selecting different choke positions for different flowpath areas. The fully-choked position may be considered a fully-closed position. The n_max^th choked position may be considered a fully-open position. Each choke may have an indexer device configured to change the cross-sectional area of the flowpath of each choke. Indexer devices have index settings. Index settings are associated with choke positions.

Each choke may be incremented between each choked position using an indexer. The indexer changes the choke position in the various increments by indexing the internal components of the chokes. In this manner the indexer indexes from one index setting to another index setting and each index setting corresponds with a choke position. The indexer indexes each choke from one choke index setting corresponding to a choke position to another choke index setting corresponding to another choke position. For example, the choke L 280 may have an indexer L (e.g., an Indexer L 230), the choke M 285 may have an indexer M (e.g., an Indexer M 235), and the choke U 290 may have an indexer U (e.g., an Indexer U 240).

In this manner choke positions refer to positions of the internal components such as a sliding sleeve within the choke. Choke locations refer to the location in the well, such as a total vertical depth or a measured depth of the choke in the wellbore. Index settings refer to the setting of choke internal components such as the indexer within the choke. An indexer has index settings to move the choke from one choke index setting to another setting. An index parameter refers to the specification of the index setting. The index parameters are the numbers of the choke index setting, e.g., “3” is a specific index parameter of a choke index setting. A choke index setting parameter of three indicates that the indexer is set at index setting three which sets the sliding sleeve of the choke in the choking position three. Choke index data may include data regarding one or more choke index settings, e.g., choke index parameters.

In accordance with one or more embodiments each choke may have two to twelve or more index settings. A twelve settings-position table (e.g., First Settings-Position Table 255) illustrated in FIG. 2B shows, for example a ten-choking position choking valve may have twelve index settings (e.g., twelve index settings 256) corresponding to twelve positions (e.g., twelve choke positions 257) ranging from fully choked, i.e., fully closed (a first index setting pl corresponding to a choke position one) to fully open (a twelfth index setting p12 corresponding to a choke position twelve) with ten intermediate choking flow index settings between the first and the twelfth positions. E.g., a choke index setting of three configures the choke in the choke position three. The second of ten intermediate choking flow index settings may be a choke position three or 3^rd choked position. The 3rd choked position may correspond to the second intermediate choking flow setting which may correspond to a cross-sectional area of the flowpath (e.g., Flowpath Areas 258) equivalent to 20% of the cross-sectional area of the production tubing to which the choke is hydraulically coupled. In a well with three zones, one choke per zone, twelve index settings per choke, the total is 1,9928 combinations of valve positions and zones (12{circumflex over ( )}3).

FIG. 2C shows an example four settings-position table (e.g., Second Settings-Position Table 245) for another choke example. In FIG. 2C the two-choking position choke L 280 may have four index settings (e.g., four index settings 246) corresponding to four positions (e.g., four choke positions 247) ranging from fully choked, i.e., fully closed (a first index setting p1 corresponding to a choke position one) to fully open (a fourth index setting p4 corresponding to a choke position four) with two intermediate choking flow index settings between position one (the first position) and position four (the fourth position). The second of two intermediate choking flow index settings may be a choke position three or 3^rd choked position. The 3rd choked position may correspond to the second intermediate choking flow setting which may correspond to a cross-sectional area of the flowpath (e.g., Flowpath Areas 248) equivalent to 66% of the cross-sectional area of the production tubing to which the choke is hydraulically coupled. The choke positions correspond with four index settings, e.g., choke index settings, such that each choke position is determined by a choke index setting. Each choke position corresponds with a predetermined cross-sectional flow area of the choke. In an example well with three zones, one choke per zone, four index settings per choke, the total is sixty-four combinations of valve positions and zones (4{circumflex over ( )}3). The example sixty-four combinations (e.g., a combinations matrix 260) are partially illustrated in FIG. 2D.

Returning to FIG. 2A, the choke L 280 may have a first index setting (e.g., an indexer L first index setting 231) corresponding to the first (1^st) choked position (e.g., a choke L first position 281), a second index setting (e.g., an indexer L second index setting 232) corresponding to the second (2^nd) choked position (e.g., a choke L second position 282), a third index setting (e.g., an indexer L third index setting 233) corresponding to the third (3^rd) choked position (e.g., a choke L third position 283), and a fourth index setting (e.g., an indexer L fourth index setting 234) corresponding to the fourth (4^th) choked position (e.g., a choke L fourth position 284).

For example, choke M 285 may include four index settings, a first index setting (e.g., an indexer M first index setting 236) corresponding to the first choked position (e.g., a choke M first position 286), a second index setting (e.g., an indexer M second index setting 237) corresponding to the second choked position (e.g., a choke M second position 287), a third index setting (e.g., an indexer M third index setting 238) corresponding to the third choked position (e.g., a choke M third position 288), and a fourth index setting (e.g., an indexer M fourth index setting 239) corresponding to the fourth choked position (e.g., a choke M fourth position 289).

For example, choke U 290 may include four index settings, a first index setting (e.g., an indexer U first index setting 241) corresponding to the first choked position (e.g., a choke U first position 291), a second index setting (e.g., an indexer U second index setting 242) corresponding to the second choked position (e.g., a choke U second position 292), a third index setting (e.g., an indexer U third index setting 243) corresponding to the third choked position (e.g., a choke U third position 293), and a fourth index setting (e.g., an indexer U fourth index setting 244) corresponding to the fourth choked position (e.g., a choke U fourth position 294).

Each indexer may be configured to move from their respective first index settings to their respective second index settings in response to an actuation pressure input. The actuation pressure input may be positive (e.g., pressurizing) or negative (e.g., depressurizing). For example, a negative actuation pressure input is depressurizing. Subsequent changes in actuation pressures may result in changes to pressure inputs to the internal components of the indexer. Pressure input changes may cause a shift of the indexer from a first position to a next position in response to a second actuation pressure input.

Likewise, pressure input changes may cause a shifting from the second index setting to a third index setting in response to a second actuation pressure input. In like manner, subsequent cycling of the actuation pressures may result in cycling of pressure inputs to the indexer thereby causing a shifting from a choke position n to a choke position n+1 until a maximum number of positions is met (n_max), after which the indexer may return to the first index setting thereby moving the choke to the choke position one. For example, the indexer may shift from the third index setting to a fourth index setting in response to a third actuation pressure input, and the indexer may shift from the fourth index setting to the first index setting in response to a fourth actuation pressure input.

In accordance with one or more embodiments various downhole sensor devices may be included in the well. The downhole sensor devices may be stand-alone devices or they may be integrated in other downhole components such as flow control devices. As shown in FIG. 2A, a sensor system (e.g., a sensor system 250) may include downhole sensors such as a pressure sensor (e.g., a pressure sensor 251), a temperature sensor (e.g., a temperature sensor 252), a water cut sensor (e.g., a water cut sensor 253), and/or a flowrate sensor (e.g., a flowrate sensor 254). Sensor data from the sensor system may be transmitted to the well performance manager, reservoir simulator, the well control system, or other software platform.

Although a multi-zone well is shown in FIG. 2A, one with ordinary skill in the art will recognize that the concepts and methods detailed hereafter are not limited to a multi-zone well. For example, the disclosed may be applied to multilateral wells with two, three, or more laterals. The disclosed may be applied to vertical wells, horizontal wells, and/or extended reach wells.

Turning to FIG. 3, FIG. 3 shows a schematic diagram in accordance with one or more embodiments. As shown in FIG. 3, a well management network (e.g., a Well Management Network A 300) may include a well performance manager (e.g., well performance manager X 360), various oil and gas wells (e.g., well A 310, well B 320), various servers (e.g., inspection Server N 370, maintenance server C 350), and various user devices (e.g., user device M 330), and/or various network elements (not shown). A well (e.g., well A 310, well B 320) may include a well system (e.g., well system A 312, well system B 322) that is similar to well system 106 described above in FIG. 1 and the accompanying description. The well system A may include an electrical submersible pump A (e.g., an ESP A) that provides ESP A data (e.g., ESP A Data A 311) and a choke A that provides choke A data (e.g., Choke A Data A 316). The well system B may include an electrical submersible pump B (e.g., an ESP B) that provides ESP B data (e.g., ESP B Data B 321) and a choke B that provides choke B data (e.g., Choke B Data B 326). ESP data may include static data regarding the ESP such as horsepower, stages, and diameter. Choke data may include choke index setting parameters such as the quantity of choke index settings. Choke data may include choke positions within the well and choke size, diameter, and tubing connection.

In some embodiments, various types of well data (e.g., well data A 391) are collected over the well management network, such as safety alert data (e.g., safety alert data A 313), well progress data (e.g., Well Progress Data A 314), and/or well activity data (e.g., well activity data A 315). Likewise, the well management network may also collect well data from other wells, such as safety alert data B 323, well progress data B 324, and/or well activity data B 325. Likewise, the well management network may also collect data regarding other well activities data (e.g., user data 333, maintenance data 392, inspection well data 394) from one or more user device and/or data servers (e.g., user device M 330, ESP server E 340, maintenance server C 350, inspection Server N 370). For example, safety data may be associated with safety alerts. ESP server data (e.g., ESP operational data 393) may include ESP input frequency (e.g., ESP frequency data F 341), ESP input data, e.g., ESP inlet data such as ESP inlet pressure (e.g., ESP inlet pressure data P 342), and ESP flowrate (e.g., ESP flowrate data Q 343). For example, a completed ESP operation such as an ESP input frequency change may be uploaded to the ESP server and transmitted to the well performance manager. A control system on the well performance network may upload information regarding the completed ESP operation to the well performance manager. Maintenance data may include information describing well performances (e.g., well intervention data A 351), well repairs (e.g., well repair data B 352), and maintenance activities (e.g., maintenance activities data C 353). Inspection data may include information regarding regulatory compliance (e.g., regulatory compliance data X 371), mechanical inspection (e.g., mechanical inspection data Y 372), electrical inspection (e.g., electrical inspection data Z 373), etc. For example, zone control is often used by regulators to affirm allocations.

In some embodiments, the various servers may be remote servers that include hardware and/or software with functionality for managing and/or tracking the user data, the well data, the maintenance data, and the inspection data. For example, a maintenance server may maintain well maintenance data such as a tubing replacement, well repair data such as valve repairs, and maintenance data such as lubrication data. The maintenance server may maintain the maintenance data based on the location of a respective maintenance activity for a particular time period. Likewise, a remote server may be a server that communicates to various well sites over the Internet or through a cloud computing environment. When maintenance is performed for various well operations, the current or future maintenance data may be logged automatically with the maintenance server (e.g., by detecting a scan of a unique identifier for the well, geolocation, equipment, asset, etc.) Accordingly, a maintenance server may transmit maintenance data to the well performance manager.

In some embodiments, an inspection server is a remote server that includes hardware and/or software for managing and tracking inspection data. For example, the inspection server may obtain inspection data regarding various inspection entities and results of their inspections regarding current and/or future well inspections. Accordingly, an inspection server may transmit to a well performance manager inspection data (e.g., regulatory compliance data, mechanical inspection data, and/or electrical inspection data for a given well, well equipment, and/or well operation.)

In some embodiments, the well performance manager (e.g., well performance manager X 360) may include hardware and/or software that obtain a ESP inlet condition criterion (e.g., ESP inlet condition Criteria X 361) regarding well performance activities, well performance plans (e.g., well performance Plans X 362), well data (e.g., well data X 363), maintenance well data (e.g., maintenance well data X 366), and/or inspection well data (e.g., inspection well data X 367) from data inputs (e.g., user data 333, well data A 391, maintenance data 392, inspection well data 394). For example, the well performance manager (e.g., well performance manager X 360) acquires the ESP inlet condition criterion (e.g., ESP inlet condition Criteria X 361) from user data (a user data 333) of a user input collected by a user device (e.g., user device M 330).

The user device (e.g., user device M 330) may include hardware and/or software to receive real-time user selections (e.g., User Selections N 331) by interacting with a user via a user interface (e.g., User Interface O 332) through which a user may provide the user input. Specifically, the well performance manager (e.g., well performance manager X 360) allows the user to interact with the user device (e.g., user device M 330) to verify the actual well performance plan setup is as desired and monitor the performance as the self-learning process of the ML algorithm is set up for feedback upon the actual events. When the well performance plan setup is not as desired, the user can modify the user selections (e.g., the User Selections N 331) to adjust the ESP inlet condition criterion via the graphical display (e.g., User Interface O 332).

Keeping with FIG. 3, in some embodiments, the well performance manager (e.g., well performance manager X 360) may include hardware and/or software to generate one or more well performance plans within the well management network (e.g., the Well Management Network A 300) using one or more ML algorithms (e.g., ML Algorithms X 364) based on the obtained ESP inlet condition criterion and well performance activities. For example, a well performance manager may implement machine learning by gathering data from actual well performance data (e.g., status updates at a well site regarding one or more well operations) and real events to tune a particular ESP inlet condition criterion and/or logical margins regarding flexibility for yearly, monthly, or weekly well performance plans for a well.

Thus, different inputs (e.g., types of data or different data sources) may provide the initial setup of a particular ESP inlet condition criterion, where the data inputs may be customized according to different well scenarios to better arrange a forward schedule as a well performance plan. Since the well performance manager is self-maintained on data storage and usage for feedback, the well performance manager may require minimal supervision of human interaction. In some embodiments, the well performance manager advises a user about a regular structure of a plan of setting a well performance plan when the learning process detects possible related concerns that a human might miss due to the number of variables and possible related issues. For example, an advisement may be a message prompt in a graphical user interface managed by the well performance manager.

In some embodiments, for example, the well performance manager (e.g., well performance manager X 360) applies one or more ML algorithms (e.g., an unsupervised ML algorithm, a reinforcement ML algorithm, a deep reinforcement learning algorithm, a self-supervised ML algorithm, etc.) to train a model (e.g., ML Models X 365). Specifically, the well performance manager (e.g., well performance manager X 360) applies the model to generate a well performance plan at a well site using data inputs regarding one or more well performance providers and one or more well conditions. In accordance with one or more embodiments the well operations may be determined using a deep reinforcement learning algorithm. For example, the well operations may include an ESP maintenance operation, an ESP frequency input change, or a predetermined choke index setting change (choke index operation.)

With respect to machine-learning (ML) models, different types of ML models may be used, such as random forest models and artificial neural networks, such as convolutional neural networks, deep neural networks, recurrent neural networks, support vector machines (SVMs), naive Bayes models, gradient boosting models, decision trees, inductive learning models (supervised learning), deductive learning models (deductive reasoning), supervised learning models, self-supervised learning models, unsupervised learning models, reinforcement learning models, etc. In some embodiments, a well performance manager may generate augmented or synthetic data to produce a large amount of interpreted data for training a particular model.

An ML model may be trained using one or more ML algorithms. For example, a backpropagation algorithm may be used to train a neural network. The training data may include the predetermined ESP inlet condition criterion and data inputs from historical events regarding one or more well performance providers and one or more well conditions. A well performance manager may continue to train the ML model by using a self-feeding database (e.g., a database X 368) for a historical learning process. Thus, the ML model predicts the well performance plan for performance as the self-learning process of the ML algorithm is set up for feedback upon the actual events as per the desire (e.g., the user input.)

In a deep neural network, for example, a layer of neurons may be trained on a predetermined list of features based on the output of the previous network layer. Thus, as data progresses through the deep neural network, more complex features may be identified within the data by neurons in later layers. Likewise, a U-net model or other type of convolutional neural network model may include various convolutional layers, pooling layers, fully connected layers, and/or normalization layers to produce a particular type of output. Thus, convolution and pooling functions may be the activation functions within a convolutional neural network.

In some embodiments, two or more different types of machine-learning models are integrated into a single machine-learning architecture, e.g., a machine-learning model may include a random forest model and various neural networks. In some embodiments, a reservoir simulator (e.g., the reservoir simulator 160) may generate augmented data or synthetic data to produce a large amount of interpreted data for training a particular model.

In some embodiments, a machine-learning model is trained using multiple epochs. For example, an epoch may be an iteration of a model through a portion or all of a training dataset. As such, a single machine-learning epoch may correspond to a specific batch of training data, where the training data is divided into multiple batches for multiple epochs. Thus, a machine-learning model may be trained iteratively using epochs until the model achieves a predetermined criterion, such as predetermined level of prediction accuracy or training over a specific number of machine-learning epochs or iterations. Thus, better training of a model may lead to better predictions by a trained model. In this manner an initial model (an initial machine-learning model) may be sent to a training operation to produce a second machine-learning model.

Turning to recurrent neural networks, a recurrent neural network (RNN) may perform a particular task repeatedly for multiple data elements in an input sequence (e.g., a sequence of temperature values or flowrate values), with the output of the recurrent neural network being dependent on past computations.

As such, a recurrent neural network may operate with a memory or hidden cell state, which provides information for use by the current cell computation with respect to the current data input. For example, a recurrent neural network may resemble a chain-like structure of RNN cells, where different types of recurrent neural networks may have different types of repeating RNN cells.

Likewise, the input sequence may be time-series data, where hidden cell states may have different values at different time steps during a prediction or training operation. For example, where a deep neural network may use different parameters at each hidden layer, a recurrent neural network may have common parameters in an RNN cell, which may be performed across multiple time steps.

To train a recurrent neural network, a supervised learning algorithm such as a backpropagation algorithm may also be used. In some embodiments, the backpropagation algorithm is a backpropagation through time (BPTT) algorithm. Likewise, a BPTT algorithm may determine gradients to update various hidden layers and neurons within a recurrent neural network in a similar manner as used to train various deep neural networks.

Embodiments are contemplated with different types of RNNs. For example, classic RNNs, long short-term memory networks (LSTM networks), a gated recurrent unit (GRU), a stacked LSTM that includes multiple hidden LSTM layers (i.e., each LSTM layer includes multiple RNN cells), recurrent neural networks with attention (i.e., the machine-learning model may focus attention on specific elements in an input sequence, e.g., sequence learning), bidirectional recurrent neural networks (e.g., a machine-learning model that may be trained in both time directions simultaneously, with separate hidden layers, such as forward layers and backward layers), as well as multidimensional LSTM networks, graph recurrent neural networks, grid recurrent neural networks, etc. With regard to LSTM networks, a long short-term memory cell (LSTM cell), i.e., an LSTM cell may include various output lines that carry vectors of information, e.g., from the output of one LSTM cell to the input of another LSTM cell. Thus, an LSTM cell may include multiple hidden layers as well as various pointwise operation units that perform computations such as vector addition.

In some embodiments, the reservoir simulator uses one or more ensemble learning methods to produce a hybrid-model architecture. For example, an ensemble learning method may use multiple types of machine-learning models to obtain better predictive performance than available with a single machine-learning model. In some embodiments, for example, an ensemble architecture may combine multiple base models to produce a single machine-learning model. The ensemble model, comprising multiple base models, is trained using a prepared dataset, i.e., the relevant data to which data preprocessing techniques have been applied and feature engineering techniques have been utilized.

One example of an ensemble learning method is a BAGGing model (i.e., BAGGing refers to a model that performs bootstrapping and aggregation operations) that combines predictions from multiple neural networks to add a bias that reduces variance of a single trained neural network model. Another ensemble learning method includes a stacking method, which may involve fitting many different model types on the same data and using another machine-learning model to combine various predictions. In this manner an initial model (an initial machine-learning model) may be sent to a training operation to produce a second machine-learning model using a bootstrap and aggregation operation. Gradient boosting for regression and classification tasks provides a prediction model in the form of an ensemble of weak prediction models, i.e., models that make very few assumptions about the data, which are typically simple decision trees.

Model hyperparameters may be tuned using techniques like cross-validation to optimize the performance of the model. The implementation may utilize programming languages like Python™, along with relevant libraries (e.g., scikit-learn, TensorFlow) for model development, training, and evaluation. The performance of the model may be assessed through rigorous validation using cross-validation, and hyperparameter tuning can be performed using techniques such as grid search or Bayesian optimization, where Bayesian refers to naïve (strong independence assumptions between features) Bayes model. Commercially available items available as of the priority date of this patent application include, for example, Python™, scikit-learn, and TensorFlow. This list is not intended to be limiting, nor are the determinations intended to be limited to the commercially available program. Any suitable software (e.g., custom-coded applications) providing similar functionality to that described may also be implemented without departing from the scope of the present disclosure.

The well performance manager X 360 may be located at a well site (e.g., well site 100, FIG. 1). In some embodiments, the well performance manager or other components in FIG. 3 may be remote from a well site. In some embodiments, the well performance manager X 360 is implemented as part of a software platform for the well control system 126 in FIG. 1. The software platform may obtain data acquired by the well system 106 and the well control system 126 as inputs, which may include multiple data types from multiple sources. The software platform may aggregate the data from these systems (well system 106 and well control system 126) in real time for rapid analysis. In some embodiments, the well system 106 and the well control system 126, the well performance manager X 360, and/or a user device (e.g., user device M 330) coupled to one of these systems may include a computer system that is similar to the computer system (e.g., the computer 902) described below with regard to FIG. 9 and the accompanying description.

In some embodiments, the well performance manager may perform one or more ML algorithms (e.g., an unsupervised ML algorithm, a reinforcement ML algorithm, a deep reinforcement learning algorithm, a self-supervised ML algorithm, a composite machine-learned learning algorithm, etc.) based on an obtained data inputs. In particular, a reinforcement ML (machine-learning) algorithm, i.e., a reinforcement learning algorithm may be a type of method that autonomously learns agent policies through multiple iterations of trials and evaluations based on data inputs. The objective of a reinforcement learning algorithm may be to learn an agent policy π that maps the state of a well performance activity to a well performance plan so as to maximize an expected reward J(π). A value reward may describe one or more qualities of data inputs for a particular well within an operation.

For another example, a reinforcement learning algorithm may include an action selector engine to determine commands and/or actions based on policy data and one or more reward functions. More specifically, a reinforcement learning algorithm may train a policy to make a sequence of decisions based on the observed states of the environment to maximize the cumulative reward determined by a reward function. For example, a reinforcement learning algorithm may employ a trial-and-error procedure to determine one or more agent policies based on various interactions of the agents with a complex environment. As such, a reinforcement learning algorithm may include a reward function that teaches a particular action selection engine to follow certain rules, while still allowing the reinforcement learning model to retain information learned from data inputs regarding one or more well performance providers and one or more well conditions.

In some embodiments, the well performance manager may perform a self-supervised ML algorithm to train a model based on an obtained ESP inlet condition criterion and data inputs. In particular, a self-supervised learning is a subclass of unsupervised machine learning which requires only unlabeled data to provide the supervision and formulate a pretext learning task such as predicting context or image rotation for some part of the data. The objective of a self-supervised learning algorithm may force the neural network (e.g., the convolutional neural network) to learn a high-level semantic representation to solve the task of interest. For example, a self-supervised learning algorithm may calculate the similarity with semantic information of well performance activity preference that is implicitly present within the well management network based on the obtained criterion. The self-supervised learning algorithm may then calculate the similarity between the list of well performance activities based on one or more qualities of data inputs.

In some embodiments, a well performance manager is used to generate a well performance plan within the well management network for planning, synchronizing, and optimizing the activities of a well performance plan using one or more ML algorithms (e.g., an unsupervised ML algorithm, a reinforcement ML algorithm, a deep reinforcement learning algorithm, a self-supervised ML algorithm, etc.) to maximize operational efficiency, availing hydrocarbon, and minimizing budget expenditure. In some embodiments, a first well performance plan may be generated by the well performance manager based on a predetermined ESP inlet condition criterion determined by a user based on real-time observed matters (e.g., production rate, water cut, liquid flowrate, gas cut, gas flowrate, ESP frequency, ESP inlet pressure, safety concerns, contract terms, contract conditions, well conditions, well site conditions, scope, cost, resources, weather, government, legal, etc.) Production rate may be predetermined to limit drawdown, to maintain flow above bubble point, or to not exceed maximum liquid rates, e.g., of surface processing equipment handling constraints. The well performance manager may apply one or more ML algorithms to adjust the predetermined ESP inlet condition criterion based on new data. The well performance manager may apply one or more ML algorithms to accommodate the adjusted ESP inlet condition criterion within seconds and re-arrange different operations. The well performance manager automatically re-schedules the well performance plan for emerging issues based on an adjusted ESP inlet condition criterion.

Furthermore, the well performance manager may apply one or more ML algorithms to generate multiple well performance plans for different well scenarios for a well site of interest based on an adjusted ESP inlet condition criterion by using real-time well data. Accordingly, a well performance manager may have the capability to adapt to different activity conditions and schemes. In some embodiments, the adjusted well performance plan is outputted for display for a user via a graphical user interface for a user to observe appearances, conflicts, and awareness of possible issues with the plan. For example, the well performance manager may automatically self-feed and build a database for a historical learning process that clearly enumerates changes to a well performance plan based on newly acquired data and statistical trends.

In some embodiments, the well performance manager may perform an unsupervised ML algorithm to train a model based on an obtained ESP inlet condition criterion and data inputs. In particular, unsupervised learning requires only unlabeled data to build a compact internal representation to formulate a pattern learning task for the data inputs. The objective of an unsupervised learning algorithm may force the neural network to learn the compact internal representation (e.g., natural clusters) of data inputs based on multiple attributes to solve the task of interest.

The unsupervised learning algorithm may classify the list of well performance activities by using multiple natural clusters for the compact internal representation based on one or more qualities of data inputs (e.g., ESP inlet condition Criteria X 361, well performance Plans X 362, well data X 363, inspection well data X 367, and/or maintenance well data X 366) for a particular well (e.g., well B 320) and convergence items for recommendation based on the analysis of the pattern of natural clusters that characterize the list of well performance activities. The top N natural clusters having the highest priorities are recommended as the new convergence items for the particular well. Accordingly, the well performance manager X 360 may obtain data from various entities regarding current and/or future well operations, then transmit commands (e.g., a command Y 395) to perform the well operation. The commands may be transmitted to one or more control systems. The well operation commands may include, for example, ESP maintenance operations, ESP frequency input changes, or choke index operations as described earlier. ESP performance parameters may include the ESP frequency, ESP inlet pressure, ESP inlet temperature, etc.

FIG. 4 (propose FIG. four) depicts a high-level workflow 400 outlining the use of the well performance manager described herein. In Block 402, a plurality of receiver measurements is obtained using the well performance manager. The plurality of receiver measurements is a collection of original receiver values. The plurality of receiver measurements contains the original combination receiver values for ESP operational parameters, choke position, choke pressure, choke temperature, choke flowrate, and/or other operational parameters.

The receiver measurements may include, for example, dynamic well data, choke index setting data, and ESP data acquired substantially simultaneously from a well such as a first well. For example, a choke in a well may be set to a choking position n (e.g., choke position 3) corresponding to choke index setting n data (e.g., choke index setting 3 data.)

Continuing with the example, producing through a choke set to position 3 results in choke index setting data recorded and transmitted from certain entities such as sensors at the choke and sensors at the ESP. Thus, the choke index setting data (e.g., pressure, temperature, and choke setting n) corresponds with the choke index setting n (e.g., pressure and temperature at choke setting 3).

Likewise, producing through a choke set to other positions n, e.g., a choke set to position 4, results in choke index setting data recorded and transmitted from those entities. Thus, the choke index setting data (e.g., pressure, temperature, and choke setting n) corresponds with the choke index setting n (pressure and temperature at choke setting 4). With the choke set to index setting n, choke index setting data may include flowrate data and pressure data corresponding to choke setting n measured at the choke and at the ESP flow inlet. The choke index setting data may be recorded and/or transmitted from those respective entities.

In Block 404, the plurality of receiver measurements is pre-processed. Pre-processing steps may include, but are not limited to, normalization and imputation of input data.

In Block 406, a machine-learned model (e.g., LSTM) accepts and processes the pre-processed plurality of receiver measurements.

In Block 408, the result of the ML model forms a prediction. The prediction may be an ESP inlet condition. The ESP inlet condition is an operational condition recorded at an ESP inlet such as an ESP inlet pressure, ESP inlet temperature, or ESP inlet flowrate. As the operational data is recorded over time during well production, the processes of collecting a plurality of receiver measurements and predicting an ESP inlet condition can be applied. In some embodiments a plurality of receiver measurements may be padded using the plurality of reference receiver measurements.

In Block 410 the ESP inlet conditions are stitched together, accounting for each choke position and choke location, to construct a first predicted well performance of the well. The well performance manager may compare well performance with a predetermined criterion and then transmit a choke setting command to adjust the well performance to achieve the predetermined criterion. In this manner the method generates a well performance model using the predicted well performance. The method thereby determines an index setting of one or more chokes in the well using the well performance model. The well performance manager may use the well performance model, static well data, dynamic well data, choke index setting data, and ESP data to generate predicted ESP maintenance data.

With the well performance manager and an overview of its use described, then in accordance with one or more embodiments, the one or more composite machine-learned models can be described in greater detail. Machine learning (ML), broadly defined, is the extraction of patterns and insights from data. The phrases “artificial intelligence,” “machine learning,” “deep learning,” and “pattern recognition” are often convoluted, interchanged, and used synonymously throughout the literature. This ambiguity arises because the field of “extracting patterns and insights from data” was developed simultaneously and disjointedly among a number of classical arts like mathematics, statistics, and computer science.

Machine-learned model types may include, but are not limited to, generalized linear models, Bayesian regression, random forests, and deep models such as neural networks, convolutional neural networks, and recurrent neural networks. Machine-learned model types, whether they are considered deep or not, are usually associated with additional “hyperparameters” which further describe the model. For example, hyperparameters providing further detail about a neural network may include, but are not limited to, the number of layers in the neural network, choice of activation functions, inclusion of batch normalization layers, and regularization strength. Commonly, in the literature, the selection of hyperparameters surrounding a model is referred to as selecting the model “architecture.”

In accordance with one or more embodiments, an ESP inlet condition is predicted using a machine-learned model. In one or more embodiments, the machine-learned model is a LSTM. For greater context, the basic operations of a NN and LSTM are described below. However, one with ordinary skill in the art will recognize that many variations of each of these machine-learned models exist. As such, the introductory discussions of a NN and LSTM provided herein should not be construed as limiting on the instant disclosure.

A diagram of a neural network (NN) (e.g., an NN 500) is shown in FIG. 5. At a high level, the NN 500 may be graphically depicted as being composed of nodes (e.g., a node 502), where here any circle represents a node, and edges (e.g., an edge 504), shown here as directed lines. The nodes may be grouped to form layers (e.g., a layer 505). FIG. 5 displays four layers. The four layers include a first layer known as an input layer (e.g., an input layer 508), two intermediate hidden layers (e.g., a first hidden layer 510, a second hidden layer 512) and a last layer known as an output layer (e.g., an output layer 514) of nodes where the nodes are grouped into columns, however, the grouping need not be as shown in FIG. 5. The edges connect the nodes. Edges may connect, or not connect, to any node or nodes regardless of which layer the node is in. That is, the nodes may be sparsely and residually connected. A neural network will have at least two layers, where the first layer (e.g., the input layer 508) is considered the input layer and the last layer is the output layer. Any intermediate layer is usually described as a hidden layer. A neural network may have zero or more hidden layers and a neural network with at least one hidden layer may be described as a deep neural network or a deep learning method. In general, a neural network may have more than one node in the output layer. In this case the neural network may be referred to as a multi-target or multi-output network.

Nodes (e.g., the node 502) and edges (e.g., the edge 504) carry additional associations. Namely, every edge is associated with a numerical value. The edge numerical values, or even the edges themselves, are often referred to as weights or parameters. While training a neural network, numerical values are assigned to each edge. Additionally, every node is associated with a numerical variable and an activation function. Activation functions are not limited to any functional class, but traditionally follow the form

A = f ⁢ ( ∑ i ∈ ( incoming ) [ ( node ⁢ value ) i ⁢ ( edge ⁢ value ) i ] ) ,

where i is an index that spans the set of incoming nodes and edges and ƒ is a user-defined function. Incoming nodes are those that, when viewed as a graph (as in FIG. 5), have directed arrows that point to the node where the numerical value is being computed. Some functions for ƒ may include the linear function ƒ(x)=x, sigmoid function

f ⁢ ( x ) = 1 1 + e - x ,

and rectified linear unit (ReLU) function ƒ(x)=max(0, x), however, many additional functions are commonly employed. Every node in a neural network may have a different associated activation function. Often, as a shorthand, activation functions are described by the function ƒ by which it is composed. That is, an activation function composed of a linear function ƒ may simply be referred to as a linear activation function without undue ambiguity.

When the neural network receives a network input, the network input is propagated through the network according to the activation functions and incoming node (e.g., the node 502) values and edge (e.g., the edge 504) values to compute a value for each node according to the preceding equation. That is, the numerical value for each node may change for each received input. Occasionally, nodes are assigned fixed numerical values, such as the value of 1, that are not affected by the input or altered according to edge values and activation functions. Fixed nodes are often referred to as biases or bias nodes (e.g., a biased node 506), displayed in FIG. 5 with a dashed circle.

In some implementations, the neural network may contain specialized layers, such as a normalization layer, a regularization layer (e.g. dropout layer), and a concatenation layer. One skilled in the art will appreciate that these alterations do not exceed the scope of this disclosure.

As noted, the training procedure for the neural network comprises assigning values to the edges. To begin training, the edges are assigned initial values. These values may be assigned randomly, assigned according to a prescribed distribution, assigned manually, or by some other assignment mechanism. Once edge values have been initialized, the neural network may act as a function, such that it may receive inputs and produce an output. As such, at least one input is propagated through the neural network to produce an output. Generally, a dataset, known as a training dataset, is provided to the neural network in order for the network to learn edge values (i.e., learn the network parameters). The training dataset is composed of inputs and associated target(s), where the target(s) represent the “ground truth,” or the otherwise desired output. The neural network output is compared to the associated input data target(s). The comparison of the neural network output to the target(s) is typically performed by a so-called “loss function;” although other names for this comparison function such as “error function,” “misfit function,” and “cost function” are commonly employed. Many types of loss functions are available, such as the mean-squared-error function, however, the general characteristic of a loss function is that the loss function provides a numerical evaluation of the similarity between the neural network output and the associated target(s). The loss function may also be constructed to impose additional constraints on the values assumed by the edges, for example, by adding a penalty term, which may be physics-based, or a regularization term. Generally, the goal of a training procedure is to alter the edge values to promote similarity between the neural network output and associated target(s) over the training dataset. Thus, the loss function is used to guide changes made to the edge values, typically through a process called “backpropagation.”

While a full review of the backpropagation process exceeds the scope of this disclosure, a brief summary is provided. Backpropagation consists of computing the gradient of the loss function over the edge values. The gradient indicates the direction of change in the edge values that results in the greatest change to the loss function. Because the gradient is local to the current edge values, the edge values are typically updated by a “step” in the direction indicated by the gradient. The step size is often referred to as the “learning rate” and need not remain fixed during the training process. Additionally, the step size and direction may be informed by previously seen edge values or previously computed gradients. Such methods for determining the step direction are usually referred to as “momentum” based methods.

Once the edge values have been updated, or altered from their initial values, through a backpropagation step, the neural network will likely produce different outputs. Thus, the procedure of propagating at least one input through the neural network, comparing the neural network output with the associated target(s) with a loss function, computing the gradient of the loss function with respect to the edge values, and updating the edge values with a step guided by the gradient, is repeated until a termination criterion is reached. Common termination criteria are: reaching a fixed number of edge updates, otherwise known as an iteration counter; a diminishing learning rate; noting no appreciable change in the loss function between iterations; reaching a specified performance metric as evaluated on the data or a separate hold-out data set. Once the termination criterion is satisfied, and the edge values are no longer intended to be altered, the neural network is said to be “trained.”

To best understand an LSTM network, it is helpful to describe the more general recurrent neural network (RNN), for which an LSTM may be considered a specific implementation.

FIG. 6A depicts the general structure of a recurrent neural network (RNN). An RNN graphically comprises an RNN Block (e.g., an RNN Block 610) and a recurrent connection (e.g., a recurrent connection 650). The RNN Block may be thought of as a function which accepts an Input (e.g., an Input 620) and a State (e.g., a State 630) and produces an Output (e.g., an Output 640). Without loss of generality, such a function may be written as

Output = R ⁢ N ⁢ N ⁢ Block ⁢ ( Input , State ) .

The RNN Block 610 generally comprises one or more matrices and one or more bias vectors. The elements of the matrices and bias vectors are commonly referred to as weights or parameters in the literature such that the matrices may be referenced as weight matrices or parameter matrices without ambiguity.

The weights of the RNN are analogous in function to those of the NN 500. It is noted that for situations with higher dimensional inputs (e.g. inputs with a tensor rank greater than or equal to 2), the weights of an RNN Block (e.g., the RNN Block 610) may be contained in higher order tensors, rather than in matrices or vectors. For clarity, the present example will consider Inputs (e.g., one or more of the Input 620) as vectors or as scalars such that the RNN Block comprises one or more weight matrices and bias vectors, however, one with ordinary skill in the art will appreciate that this choice does not impose a limitation on the present disclosure. Typically, an RNN Block has two weight matrices and a single bias vector which are distinguished with an arbitrary naming nomenclature. A commonly employed naming convention is to call one weight matrix W and the other U and to reference the bias vector as {right arrow over (b)}.

An important aspect of an RNN is that it is intended to process sequential, or ordered, data; for example, a time-series. Pressure, temperature, flowrate, valve position, choke position, ESP input frequency, etc., measurements over time can be considered a sequence. That is, these data structures effectively encode, for example, ESP inlet pressure information into the receiver measurements acquired by the downhole sensor devices of the sensor system (e.g., the sensor system 250, FIG. 2A). In the RNN, the Input 620 may be considered a single part of a sequence. As an illustration, consider a sequence composed of Y parts. Each part may be considered an input, indexed by t, such that the sequence may be written as:

sequence = [ input 1 , input 2 , input t , … , input Y - 1 , input Y ] .

Each one of the Input 620 (e.g., input₁ of a sequence) may be a scalar, vector, matrix, or higher-order tensor.

For the present example, as previously discussed, each one of the Inputs (e.g., the Input 620) is considered a vector with j elements. In the case where j=1, each one of the Inputs is a scalar. To process a sequence, an RNN receives the first ordered Input of the sequence, input₁, along with one of the States (e.g., the State 630), and processes them with the RNN Block 610, as described above, to produce an Output (e.g., an Output 640). The Output 640 may be a scalar, vector, matrix, or tensor of any rank.

For the present example, the Output 640 is considered a vector with k elements. The State 630 is of the same type and size as the Output 640 (e.g., a vector with k elements). For the first ordered input, the State 630 is usually initialized with all of its elements set to the value zero. For the second ordered Input (the Input 620), input₂, of the sequence, the Input 620 is processed similarly, however, the State 630 received by the RNN Block 610 is set to the value of the Output 640 determined when processing the first ordered Input (e.g., the Input 620).

This process of assigning the State 630 the value of the last produced Output (e.g., the Output 640) is depicted with the recurrent connection 650 in FIG. 6A. All the Inputs (e.g., the Input 620) in a sequence are processed by the RNN Block 610 in this manner; that is, the State 630 associated with an Input 620 is the Output 640 of the RNN Block 610 produced by the previous Input (with the exception of the first Input in the sequence). In some implementations, each Output 640, one for each one of the Inputs within a sequence, is stored for later processing and use. In other implementations, the only Output that is retained is either the final Output (e.g., the final one of the Output 640), or the Output 640 which is produced when the Input 620 input_y is processed by the RNN Block 610.

In greater detail, the process of the RNN Block 610 may be generally written as

Output = R ⁢ N ⁢ N ⁢ Block ⁢ ( input , state ) = f ⁢ ( U · state + W · input +   b → ) ,

where W, U, and {right arrow over (b)} are the weight matrices and bias vector of the RNN Block 610, respectively, and ƒ is an “activation function.” Some functions for ƒ may include the sigmoid function

f ⁢ ( x ) = 1 1 + e - x ,

and rectified linear unit (ReLU) function ƒ(x)=max(0, x), however, many additional functions are commonly employed.

To further illustrate a RNN, a pseudo-code implementation of a RNN is as follows.

RNN Algorithm

	Note:
	j = input length
	k = output length
	W ∈   kxk
	U ∈   kxj
	{right arrow over (b)} ∈   k
	1: state = [01, 02, ... , 0k−1, 0k]T
	2: for input in sequence:
	3: {right arrow over (z)}1 = matmul(U, state)
	4: {right arrow over (z)}2 = matmul(W, input)
	5: output = f({right arrow over (z)}1 + {right arrow over (z)}2 + {right arrow over (b)})
	6: state = output

In keeping with the previous examples, both the inputs and the outputs are considered vectors of lengths j and k, respectively, however, in general, this need not be the case. With the lengths of these vectors defined, the shapes of the weight matrices, bias vector, and State 630 vector may be specified.

To begin processing a sequence, the State 630 vector is initialized with values of zero as shown in line 1 of the pseudo-code. Note that in some implementations, the number of inputs contained within a sequence may not be known or may vary between sequences. One with ordinary skill in the art will recognize that an RNN may be implemented without knowing, beforehand, the length of the sequence to be processed. This is demonstrated in line 2 of the pseudo-code by indicating that each input in the sequence will be processed sequentially without specifying the number of inputs in the sequence.

Once an Input 620 is received, a matrix multiplication operator is applied between the weight matrix U and the State 630 vector. The resulting product is assigned to the temporary variable {right arrow over (z)}₁. Likewise, a matrix multiplication operator is applied between the weight matrix W and the Input 620 with the result assigned to the variable {right arrow over (z)}₂.

For the present example, due to the Input 620 and Output 640 each being defined as vectors, the products in lines 3 and 4 of the pseudo-code may be expressed as matrix multiplications, however, in general, the dot product between the weight matrix and corresponding State (e.g., the State 630) or Input 620 may be applied. The Output 640 is determined by summing {right arrow over (z)}₁, {right arrow over (z)}₂, and the bias vector {right arrow over (b)} and applying the activation function ƒ elementwise. The State 630 is set to the Output 640 and the whole process is repeated until each one of the Input 620 in a sequence has been processed.

FIG. 6B depicts an “unrolled” version of the RNN of FIG. 6A. Unrolling the RNN allows one to see how the sequential inputs, indexed by t, produce sequential outputs and how the state is passed through various inputs of the sequence. It is noted that while the “unrolled” depiction shows multiple RNN Blocks (e.g., multiple instances of the RNN Block 610), these blocks are the same such that they comprise the same weight matrices and bias vector.

As previously stated, generally, training a machine-learned model requires that pairs of inputs and one or more targets (i.e., a training dataset) are passed to the machine-learned model. During this process, the machine-learned model “learns” a representative model which maps the received inputs to the associated outputs. In the context of an RNN, the RNN receives a sequence, wherein the sequence can be partitioned into one or more sequential parts (e.g., the Input 620 above), and maps the sequence to an overall output, which may also be a sequence. To remove ambiguity and distinguish the overall output of an RNN from any intermediate Outputs (e.g., the Output 640) produced by the RNN Block 610, the overall output will be referred to herein as a RNN result. In other words, an RNN receives a sequence and returns a RNN result.

The training procedure for a RNN comprises assigning values to the weight matrices and bias vector of the RNN Block 610. For brevity, the elements of the weight matrices and bias vector will be collectively referred to as the RNN weights. To begin training the RNN weights are assigned initial values. These values may be assigned randomly, assigned according to a prescribed distribution, assigned manually, or by some other assignment mechanism. Once the RNN weights have been initialized, the RNN may act as a function, such that it may receive a sequence and produce a RNN result. As such, at least one sequence may be propagated through the RNN to produce a RNN result.

For training, a training dataset is composed of one or more sequences and desired RNN results, where the desired RNN results represent the “ground truth,” or the true RNN results that should be returned for the given sequences. For clarity, and consistency with previous discussions of machine-learned model training, the desired or true RNN results will be referred to as targets. When processing sequences, the RNN result produced by the RNN is compared to the associated target. The comparison of a RNN result to the target(s) is typically performed by a loss function. As before, other names for this comparison function such as “error function” and “cost function” are commonly employed.

Many types of loss functions are available, such as the mean squared error function, however, the general characteristic of a loss function is that the loss function provides a numerical evaluation of the similarity between the RNN result and the associated target(s). The loss function may also be constructed to impose additional constraints on the values assumed by RNN weights, for example, by adding a penalty term, which may be physics-based, or a regularization term.

Generally, the goal of a training procedure is to alter the RNN weights to promote similarity between the RNN results and associated targets over the training dataset. Thus, the loss function is used to guide changes made to the RNN weights, typically through a process called “backpropagation through time,” which is similar to the backpropagation process previously described.

A long short-term memory (LSTM) network may be considered a specific, and more complex, instance of a recurrent neural network (RNN). FIG. 6C is an unrolled depiction of an LSTM where the internal components of the LSTM are displayed as labelled abstractions. An LSTM, like a RNN, has a recurrent connection, such that the output produced by a single input in a sequence is forwarded as the state to be used with the subsequent input. However, an LSTM also possesses another “state-like” data structure commonly referred to as the “carry.” The carry, like the state and input may be a scalar, vector, matrix, or tensor of any rank depending on the context of the application. Like unto the description of the RNN, for simplicity, the carry will be considered a vector in the following discussion of the LSTM. The LSTM receives an input, state, and carry and produces an output and a new carry. The output and the new carry are passed to the LSTM as the state and carry for the subsequent input. This sequential process, indexed by t, may be described functionally as

( output t , carry t ) = L ⁢ S ⁢ T ⁢ M ⁢ Block ⁢ ( input t , carry t - 1 , state t ) = 
 L ⁢ S ⁢ T ⁢ M ⁢ Block ⁢ ( input t , carry t - 1 , output t - 1 ) ,

• • where the LSTM Block, like the RNN Block, comprises one or more weight matrices and bias vectors and the processing steps necessary to transform an input, state, and carry to an output and new carry.

LSTMs may be configured in a variety of ways, however, the processes depicted in FIG. 6C are the most common. As shown in FIG. 6C, an LSTM Block receives an input (input_t), a state (state_t), and a carry (carry_t−1). Again, assuming that the inputs, carry, and outputs are all vectors, the weights of the LSTM Block may be considered to reside in eight matrices and four bias vectors. These matrices and vectors are conventionally named W_i, U_i, W_ƒ, U_ƒ, W_c, U_c, W_o, U_o and {right arrow over (b)}_i, {right arrow over (b)}_f, {right arrow over (b)}_c, {right arrow over (b)}_o, respectively. The processes of the LSTM Block are as follows. Block 660 represents the following first operation

f → = a 1 ⁢ ( U f · state t + W f · input t + b → f ) ,

where a₁ is an activation function applied elementwise to the result of the parenthetical expression and the resulting vector is {right arrow over (ƒ)}. Block 665 implements the following second operation

ι → = a 2 ⁢ ( U i · state t + W i · input t + b → i ) ,

where a₂ is an activation function which may be the same or different to a₁ and is applied elementwise to the result of the parenthetical expression. The resulting vector is {right arrow over (l)}. Block 670 implements the following third operation

c → = a 3 ⁢ ( U c · state t + W c · input t + b → c ) ,

where a₃ is an activation function which may be the same or different to either a₁ or a₂ and is applied elementwise to the result of the parenthetical expression. The resulting vector is {right arrow over (c)}. In block 675, vectors {right arrow over (l)} and {right arrow over (c)} are multiplied according to a fourth operation

z → 3 = ι → ⊙ c → ,

where ⊙ indicates the Hadamard product (i.e., elementwise multiplication). Likewise, in block 685 the carry vector from the previous sequential input (carry_t−1) vector and the vector {right arrow over (ƒ)} are multiplied according to a fifth operation

z → 4 = carry t - 1 ⊙ f → .

The results of the operations of blocks 675 and 685 ({right arrow over (z)}₃ and {right arrow over (z)}₄, respectively) are added together in block 680, a sixth operation, to form the new carry (carry_t);

carry t ⁢ = z → 3 + z → 4 .

In block 690, the current input and state vectors are processed according to a seventh operation

o → = a 4 ⁢ ( U o · state t + W o · input t + b → o ) ,

where a₄ is an activation function which may be unique or identical to any other used activation function and is applied elementwise to the result of the parenthetical expression. The result is the vector {right arrow over (o)}. In block 695, an eighth operation, the new carry (carry_t) is passed through an activation function a₅. The activation a₅ is usually the hyperbolic tangent function but may be any known activation function. The eighth operations (block 695) may be represented as

z → 5 = a 5 ⁢ ( carry t ) .

Finally, the output of the LSTM Block (output_t) is determined in block 698 by taking the Hadamard product of {right arrow over (z)}₅ and {right arrow over (o)}, a ninth operation shown mathematically as

output t = z → 5 ⊙ o → .

The output of the LSTM Block is used as the state vector for the subsequent input. Again, as in the case of the RNN, the outputs of the LSTM Block applied to a sequence of inputs may be stored and further processed or, in some implementations, only the final output is retained. While the processes of the LSTM Block described above used vector inputs and outputs, it is emphasized that an LSTM network may be applied to sequences of any dimensionality. In these circumstances the rank and size of the weight tensors will change accordingly. One with ordinary skill in the art will recognize that there are many alterations and variations that can be made to the general LSTM structure described herein, such that the description provided does not impose a limitation on the present disclosure.

In accordance with one or more embodiments the inputs and outputs may vary in accordance with the specific application and the structure of the LSTM network. In the context of downhole valve (inflow control valve, ICV, downhole choke) optimization, the LSTM model may be designed to accommodate output of predicted ESP input data such as ESP intake pressure (ESP inlet pressure), temperature, and flowrate given an ICV setting (a choke index setting). In other embodiments the output is an optimal choke index setting. LSTM models may be applied in different configurations for predictive and prescriptive analytics within the same domain.

In accordance with one or more embodiments the LSTM model acts as a predictive tool/predictive model. A Predictive Model may include Inputs of choke index settings and operational parameters such as historical pressure, temperature, and flowrate data. The Predictive Model may include Outputs of predicted intake pressure (ESP inlet pressure), temperature, and flowrate. The Predictive Model thereby may include forecasting the outcomes (pressure, temperature, and flowrate) based on various choke index settings and other inputs. The Predictive Model may improve understanding of how changes in choke index settings impact well performance without actually making those adjustments in the field.

In accordance with one or more embodiments the LSTM model acts as a prescriptive tool/prescriptive model. A Prescriptive Model may include Inputs of target intake pressure (e.g., a target ESP inlet pressure), temperature, and flowrate, along with current well conditions and operational parameters such as historical data. The Prescriptive Model may include Outputs of optimal choke index setting. The Prescriptive Model thereby may include determining choke index settings to achieve desired operational outcomes (e.g., optimal pressure, temperature, and flowrate). The Prescriptive Model may solve an optimization problem and may include a feedback loop where the predictions of the model influence the inputs in subsequent iterations.

The Predictive Model and the Prescriptive Model demonstrate the capability of the LSTM to model complex, nonlinear relationships over time, making the LSTM particularly suited for dynamic systems such as hydrocarbon wells where conditions change over time. The choice between a predictive or prescriptive approach depends on the operational needs, the availability and quality of data, and the specific objectives of the optimization system.

In accordance with one or more embodiments an LSTM-driven downhole choke optimization system may include the following example inputs and outputs. In a Predictive Model scenario, inputs may include current data such as a choke index setting of 8 for 70% open (70% unchoked.) flowpath area (See Flowpath Areas 258 in FIG. 2B). Inputs, e.g., ESP input data, may include historical data from a preceding hour such as Pressure at pump intake (ESP intake pressure): 2500 psi at the ESP inlet; Temperature at pump intake: 80° C.; and Flowrate: 1500 barrels per day.

Continuing with the Predictive Model scenario, outputs may include predictions that include ESP input data such as Pressure: 2550 psi at the ESP inlet indicating how the pressure is expected to change with the current ICV setting; Temperature: 82° C. forecasting the temperature change at the pump intake; Flowrate: 1550 barrels per day estimating the flowrate based on the choke index setting.

In a Prescriptive Model scenario, inputs may include target (predetermined) data such desired outcomes. A set of desired outcomes may include intake pressure: 2600 psi at the ESP inlet; flowrate: 1600 barrels per day; and a non-predetermined temperature. Inputs may also include current conditions such as pressure at pump intake: 2500 PSI; temperature at pump intake: 80° C.; flowrate: 1500 barrels per day.

Continuing with the prescriptive model scenario, outputs may include an optimal choke index setting such as choke index setting 8 for 70% open (70% unchoked.) (See Flowpath Areas 258 in FIG. 2B.) In this scenario the model considers the dynamic conditions of the well to calculate the optimal setting needed to achieve the desired pressure and flowrate.

These examples illustrate how LSTM models can be utilized in downhole valve optimization for pump intake pressure to either predict the outcomes of various ICV settings or to prescribe the optimal ICV setting to achieve specific operational goals. The actual implementation of such models may depend on detailed well data, the complexity of the dynamics of the well, and the precision of the training of the LSTM model.

In accordance with one or more embodiments the output may be pressure, temperature, and flow rate and the optimal choke index setting may be found using an optimization routine using the output of the LSTM. The Optimization Process includes the following steps.

Optimization Process Model Prediction: The LSTM model predicts the pressure, temperature, and flow rate based on various inputs such as ICV settings by having been trained on historical data to understand how changes in the ICV setting affect these outputs.

Optimization Process Objective Function: The LSTM model uses an objective function defined by the desired outcomes. For example, the objective could be to maximize the flow rate while keeping the pressure within a specified range and maintaining the temperature below a certain threshold to ensure the safety and efficiency of the operation.

Optimization Process Optimization Routine: An optimization algorithm is applied to find the ICV setting that optimizes the objective function. This routine iteratively adjusts the ICV settings, uses the LSTM model to predict the outcomes of these adjustments, and evaluates the results based on the objective function. E.g., the LSTM model determines predictions of ESP input data such as ESP intake pressure based on the ICV settings.

Optimization Process Optimal ICV Setting: The optimization routine identifies the ICV setting (or settings) that best meet the objective function criteria. This setting is considered optimal for achieving the desired balance of pressure, temperature, and flow rate, e.g., a desired well performance index.

Optimization Process Example: Inputs may include Desired flow rate=1600 barrels per day; Pressure range=2400-2600 psi; Maximum allowable temperature=85° C. LSTM Outputs may include predictions of pressure, temperature, and flow rate for various ICV settings. The Objective Function may be to maximize flow rate within the constraints of the pressure range and temperature limit. The Optimization Algorithm may be a gradient-based method, genetic algorithm, or any suitable optimization technique that can handle the non-linear relationships and constraints defined by the LSTM outputs. The example Result may be that the algorithm finds an ICV setting that is predicted by the LSTM to meet the flow rate target while keeping pressure and temperature within acceptable limits.

This approach allows for dynamic optimization of downhole conditions in real-time, leveraging the predictive power of LSTM networks to simulate the outcomes of different operational strategies before implementing them in the field.

In accordance with one or more embodiments obtaining training data for the LSTM may include, for example, two primary methods: historical observations and experimental apparatus simulations. Each method has its advantages and can be used to capture different aspects of the operational dynamics of the well.

Training Data from Historical Observations (historical training data) may include a source of data collected from the operational history of the well, including past choke index settings and the corresponding observed outcomes in terms of pressure, temperature, and flow rate. Historical training data provides an advantage for being based on real-world operations, capturing the complex interactions and variations that occur in actual well conditions, including the effects of unforeseen operational challenges and real reservoir behavior. Historical training data is used for training the LSTM model to predict the outcomes of ICV settings under a wide range of conditions that have been previously encountered.

Training Data from Experimental Apparatus Simulations (simulation training data) may include a source of data generated using a controlled experimental setup designed to simulate well conditions. For example, simulation training data may include laboratory experiments or computer simulations that systematically vary choke index settings and measure the resulting pressure, temperature, and flow rate. Simulation training data provides an advantage allowing for the systematic exploration of choke index settings and outcomes across a controlled range of conditions, including extreme or rare scenarios that may not be well-represented in historical data. Simulation training data may also be used to fill gaps in the historical data to provide a more comprehensive dataset for training the LSTM model. Simulation training data may be used for generating data on the effects of specific variables in isolation or in combination under controlled conditions. Simulation training data can help in understanding the causal relationships between choke index settings and well performance indicators.

In accordance with one or more embodiments a combination of historical training data and simulation training data provide a robust dataset for training an LSTM model. The dataset leverages the realism and complexity of historical data along with the controlled variability and completeness of experimental data. By integrating both sources, the LSTM model can be trained to accurately predict the outcomes of choke index settings under a wide variety of conditions, enhancing its utility for real-time optimization of downhole operations.

While FIGS. 1-6 show various configurations of components, other configurations may be used without departing from the scope of the disclosure. For example, various components in FIGS. 1-6 may be combined to create a single component. As another example, the functionality performed by a single component may be performed by two or more components.

Turning to FIG. 7, FIG. 7 provides an example of a ML model in accordance with one or more embodiments. The following example is for explanatory purposes only and not intended to limit the scope of the disclosed technology. In FIG. 7, FIG. 7 illustrates a machine-learning model X 751 that obtains various inputs. The inputs include wellhead pressure data (e.g., wellhead pressure data X 711), ESP performance parameters such as ESP pressure data (e.g., ESP Pressure Data A 712), well parameters data B (e.g., the well parameters data B 713), fluid parameters data C (e.g., fluid parameters data C 714), reservoir parameters data X (e.g., reservoir parameters data X 715), production parameters data X (e.g., production parameters data X 716), operational data X (e.g., operational data X 717), maintenance data X (e.g., maintenance well data X 718), inspection data X (e.g., inspection data X 719), well time-series data X (e.g., Well Time-Series Data X 720).

Using a machine-learning algorithm, the machine-learning model X 751 adjusts the underlying data for the various inputs to generate a predicted well performance (e.g., a predicted well performance data 791) of the selected well. Accordingly, the inputs are revised to generate a well operation using the various inputs. Likewise, the predicted well performance data 791 is used to modify well operations at the selected well. In accordance with one or more embodiments the well operations may be determined using a deep reinforcement learning algorithm. The well operations may include an ESP maintenance operation, an ESP frequency input change, or a predetermined choke index setting change, e.g., a change to a choke index setting parameter.

In general, static data, e.g., static well data, describes one or more well design parameters of a well and dynamic data, e.g., dynamic well data, describes one or more well properties that change over a predetermined time period. The wellhead pressure data X 711 may include dynamic data such as the measured pressures at the wellhead. ESP performance parameters may include ESP Pressure Data A 712, which may include pressures at the ESP inlet.

The well characteristics (e.g., well parameters data B 713) may include, for example, static data features such as well depth, well diameter, completion type, casing size, tubing size, and well location, etc. The fluid properties (e.g., fluid parameters data C 714) may include static data and dynamic data such as fluid parameters regarding information about the produced fluids, including flowrates, composition, and properties like viscosity and density.

The reservoir parameters data X 715 may include geological data and reservoir data including relevant geological and reservoir characteristics, such as formation properties, porosity, permeability, and reservoir pressure. The production parameters data X 716 may include dynamic data features such as parameters related to production processes, such as production rates, choke index parameters, choke settings, ESP frequency settings, draw down limits, bubble point constraints, maximum liquid rate constraints, and fluid injection rates.

The operational conditions (e.g., operational data X 717 may include operational parameters such as temperature, pressure differentials, well shut-in periods, and other operational events or performances. Maintenance well data (e.g., the maintenance well data X 718) and inspection well data (e.g., the inspection data X 719) may include historical maintenance and inspection data obtained from records of various maintenance activities, well performances, and repairs. For example, historical data may include ESP replacement data and zone allocation regulation data.

The time-series information (e.g., Well Time-Series Data X 720) may include performance parameters regarding historical trends of pressure, temperature, flowrate, ESP frequency, choke indexer settings, and other relevant variables. The relevant data may include choke position data and choke location data. The well data is collected and prepared for training the model. Data preprocessing techniques may be applied to handle missing values, outliers, and normalization. This comprehensive approach ensures that relevant factors influencing well performance issues are considered during the prediction process.

The output variable of the machine-learning model X may be a classification output representing an optimized pump intake pressure such as a predicted intake pressure (e.g., an ESP inlet pressure); i.e., some embodiments may predict well performance issues. The output variable may be a binary label indicating whether a well is classified as problematic (1) or non-problematic (0) regarding the well performance issues. This prediction serves as a proactive assessment of the performance of the well and aids in making informed decisions about operational planning and maintenance. The model obtains the relevant input variables as inputs and then the model outputs the binary classification label, indicating whether the well is likely to have a well performance problem or not, predicts an ESP inlet pressure, and a subsequent well performance. Another example of a classification output may be that representing a predicted ESP service date vs. an actual ESP replacement date. Problems may be predicted for production, zones, wells, or equipment.

This prediction supports the decision-making and ESP inlet condition criteria related to well performance management, maintenance prioritization, and operational planning. The model may incorporate features to enable an output indicating the degree to which the well satisfies predetermined criteria such as ESP inlet pressure and well performance index. A well performance index (WPI) may be defined as a rate at which petroleum is produced multiplied by the pressure, summed over a predetermined period of time of production. In accordance with one or more embodiments WPI is not necessarily related strictly to flowrate. A well with a lower flowrate but a lower water cut may have a higher WPI than a well with a higher flowrate producing more water. Index may be related to the amount of gas injected or water injected to enhance recovery. An output may be, for example, data regarding predicted well performance of a selected well (e.g., the predicted well performance data 791 of the selected well). Another output may be a well operation such as a choke position change, e.g., a choke index setting parameter change. Various machine-learning models may be used such as an initial machine-learning model, a first machine-learning model, and a second, third, and fourth, etc., machine-learning model.

Turning to FIG. 8, FIG. 8 shows a flowchart in accordance with one or more embodiments. The flowchart may describe a composite machine-learned, machine learning method (e.g., a method 800) for predicting well performance problems based on ESP input pressures and downhole flow control valve choking positions. Specifically, FIG. 8 describes a general method for determining and/or validating a well performance plan in accordance with one or more embodiments. One or more blocks in FIG. 8 may be performed by one or more components (e.g., well performance manager X 360) as described in FIG. 1, FIG. 2A, FIG. 2B, FIG. 2C, FIG. 2D, FIG. 3, FIG. 4, FIG. 5, FIG. 6A, FIG. 6B, FIG. 6C, FIG. 7, and FIG. 9. While the various blocks in FIG. 8 are presented and described sequentially, one of ordinary skill in the art will appreciate that some or all of the blocks may be executed in different orders, may be combined or omitted, and some or all of the blocks may be executed in parallel. Furthermore, the blocks may be performed actively or passively.

Initially, at step 810, the method includes obtaining static well data for a well, wherein the static well data describes one or more well design parameters of the well. The well design parameters may include, for example, various types of well data that are typically constant at a well, such as well geometry (TVD, MD, inclination, direction), well coordinates, borehole size, casing size, tubing size, and other well site data such as geological and reservoir data. Examples of reservoir data may include porosity, permeability, and reservoir pressure.

At step 820, the method includes obtaining dynamic well data for the well, wherein the dynamic well data describes one or more well properties that change over time. The changes may be over a predetermined time period. Some examples of dynamic well data include well properties, one or more well parameters, and/or well operating conditions including wellhead pressure data, casing-casing annulus pressure, tubing-casing annulus pressure data, fluid property data (e.g., flow rate measurements), well production parameter data, well operation condition data, flow regimes, flow patterns, and various time-series data.

At step 830, the method includes obtaining first choke index setting data regarding a first choke disposed in a producing zone of interest of the well. Choke index setting data may include data obtained at a choke setting, such as a choke setting n. Choke setting data may include pressure, temperature, and the choke setting n (number) as formed at the choke setting n. Choke data may include choke index setting parameters such as the quantity of choke index settings. Choke data may include choke positions within the well and choke size, diameter, and tubing connection. For example, the method may include obtaining a choke position 3 of a middle-location choke in the well.

At step 840, the method includes generating, by a computer processor, first predicted electrical submersible pump (ESP) input data for a first ESP in hydraulic connection with the first choke based on the static well data, the dynamic well data, and the first choke index setting data using a recurrent neural network. ESP input data may include ESP inlet pressure and ESP flowrate.

At step 850, the method includes determining, by the computer processor, well performance data for the well based on the first predicted ESP input data. For example, for inputs of a predicted ESP inlet pressure and a predicted ESP flowrate, then the method may determine a predicted well performance such as hydrocarbon production.

At step 860, the method includes determining, by the computer processor, well operations for the well based on the well performance data. Well operations may include ESP maintenance operations, ESP frequency input changes, or choke index operations, i.e., a predetermined choke index setting change.

At step 870, the method includes transmitting, by the computer processor and to a control system coupled to the well, a command that causes the well operations to be performed at the well. The well operation commands may include, for example, ESP maintenance operations, ESP frequency input changes, or choke index operations.

Embodiments may be implemented on a computer system. FIG. 9 is a block diagram of a computer system such as the computer 902 used to provide computational functionalities associated with described algorithms, methods, functions, processes, flows, and procedures as described in the instant disclosure, according to an implementation. The illustrated computer (e.g., computer 902) is intended to encompass any computing device such as a high-performance computing (HPC) device, a server, desktop computer, laptop/notebook computer, wireless data port, smart phone, personal data assistant (PDA), tablet computing device, one or more processors within these devices, or any other suitable processing device, including both physical or virtual instances (or both) of the computing device. Additionally, the computer 902 may include a computer that includes an input device, such as a keypad, keyboard, touch screen, or other device that can accept user information, and an output device that conveys information associated with the operation of the computer 902, including digital data, visual, or audio information (or a combination of information), or a graphical user interface.

The computer 902 can serve in a role as a client, network component, a server, a database or other persistency, or any other component (or a combination of roles) of a computer system for performing the subject matter described in the instant disclosure. The illustrated computer (computer 902) is communicably coupled with a network 916. In some implementations, one or more components of the computer 902 may be configured to operate within environments, including cloud-computing-based, local, global, or other environment (or a combination of environments).

At a high level, the computer 902 is an electronic computing device operable to receive, transmit, process, store, or manage data and information associated with the described subject matter. According to some implementations, the computer 902 may also include or be communicably coupled with an application server, e-mail server, web server, caching server, streaming data server, business intelligence server, or other server (or a combination of servers).

The computer 902 can receive requests over network 916 from a client application (for example, executing on another computer 902) and responding to the received requests by processing the said requests in an appropriate software application. In addition, requests may also be sent to the computer 902 from internal users (for example, from a command console or by other appropriate access method), external or third-parties, other automated applications, as well as any other appropriate entities, individuals, systems, or computers.

Each of the components of the computer 902 can communicate using a system bus 904. In some implementations, any or all of the components of the computer 902, both hardware or software (or a combination of hardware and software), may interface with each other or the interface 906 (or a combination of both) over the system bus 904 using an application programming interface (an API 912) or a service layer 914 (or a combination of the API 912 and service layer 914. The API 912 may include specifications for routines, data structures, and object classes. The API 912 may be either computer-language independent or dependent and refer to a complete interface, a single function, or even a set of APIs. The service layer 914 provides software services to the computer 902 or other components (whether or not illustrated) that are communicably coupled to the computer 902. The functionality of the computer 902 may be accessible for all service consumers using this service layer. Software services, such as those provided by the service layer 914, provide reusable, defined business functionalities through a defined interface. For example, the interface may be software written in JAVA, C++, or other suitable language providing data in extensible markup language (XML) format or other suitable format. While illustrated as an integrated component of the computer 902, alternative implementations may illustrate the API 912 or the service layer 914 as stand-alone components in relation to other components of the computer 902 or other components (whether or not illustrated) that are communicably coupled to the computer 902. Moreover, any or all parts of the API 912 or the service layer 914 may be implemented as child or sub-modules of another software module, enterprise application, or hardware module without departing from the scope of this disclosure.

The computer 902 includes an interface 906. Although illustrated as a single interface in FIG. 9, two or more of the interfaces may be used according to particular needs, desires, or particular implementations of the computer 902. The interface 906 is used by the computer 902 for communicating with other systems in a distributed environment that are connected to the network 916. Generally, the interface 906 includes logic encoded in software or hardware (or a combination of software and hardware) and operable to communicate with the network 916. More specifically, the interface 906 may include software supporting one or more communication protocols associated with communications such that the network 916 or hardware of the interface is operable to communicate physical signals within and outside of the illustrated computer (computer 902).

The computer 902 includes at least one of a computer processor 918. Although illustrated as a single computer processor in FIG. 9, two or more processors may be used according to particular needs, desires, or particular implementations of the computer 902. Generally, the computer processor 918 executes instructions and manipulates data to perform the operations of the computer 902 and any algorithms, methods, functions, processes, flows, and procedures as described in the instant disclosure.

The computer 902 also includes a memory 908 that holds data for the computer 902 or other components (or a combination of both) that can be connected to the network 916. For example, memory 908 can be a database storing data consistent with this disclosure. Although illustrated as a single memory in FIG. 9, two or more memories may be used according to particular needs, desires, or particular implementations of the computer 902 and the described functionality. While memory 908 is illustrated as an integral component of the computer 902, in alternative implementations, memory 908 can be external to the computer 902.

The application 910 is an algorithmic software engine providing functionality according to particular needs, desires, or particular implementations of the computer 902, particularly with respect to functionality described in this disclosure. For example, application 910 can serve as one or more components, modules, applications, etc. Further, although illustrated as a single one of application 910, the application 910 may be implemented as a multiple quantity of application 910 on the computer 902. In addition, although illustrated as integral to the computer 902, in alternative implementations, the application 910 can be external to the computer 902.

There may be any number of computers such as the computer 902 associated with, or external to, a computer system containing computer 902, each computer 902 communicating over network 916. Further, the term “client,” “user,” and other appropriate terminology may be used interchangeably as appropriate without departing from the scope of this disclosure. Moreover, this disclosure contemplates that many users may use one of computer 902, or that one user may use multiple computers such as computer 902.

In some embodiments, the computer 902 is implemented as part of a cloud computing system. For example, a cloud computing system may include one or more remote servers along with various other cloud components, such as cloud storage units and edge servers. In particular, a cloud computing system may perform one or more computing operations without direct active management by a user device or local computer system. As such, a cloud computing system may have different functions distributed over multiple locations from a central server, which may be performed using one or more Internet connections. More specifically, a cloud computing system may operate according to one or more service models, such as infrastructure as a service (IaaS), platform as a service (PaaS), software as a service (SaaS), mobile “backend” as a service (MBaaS), serverless computing, artificial intelligence (AI) as a service (AIaaS), and/or function as a service (FaaS).

Advantageously, an LSTM-Driven Downhole Valve Optimization system as disclosed represents a holistic, advanced, and integrated approach to well management. Its combination of real-time adaptability, advanced predictive capabilities, and focus on efficiency, safety, and environmental impact distinctly sets it apart from the combinations of methods typically found in prior art. Embodiments disclosed herein can accurately forecast downhole conditions, leading to more precise control of inflow control valves (ICVs) and pump intake pressure. This system can integrate and analyze vast amounts of historical and real-time operational data, surpassing the data utilization capabilities of many existing solutions. This leads to continuously improving operational strategies. The system optimizes operations not only for production efficiency but also for energy usage, potentially reducing operational costs and environmental impact, an aspect not always prioritized in commercial alternatives. The system extends its predictive capabilities to equipment maintenance, foreseeing potential issues and allowing for proactive maintenance schedules, thereby reducing downtime and maintenance costs.

Although only a few example embodiments have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the example embodiments without materially departing from this invention. Accordingly, all such modifications are intended to be included within the scope of this disclosure as defined in the following claims.