Patent Description:
One implementation of the present disclosure is a method for generating and using a digital twin of a hydrocarbon system, according to some embodiments. In some embodiments, the method includes performing a plurality of simulations using design of experiments (DOE) techniques to create a hyperdimensional space mapping simulation inputs, outputs and attributes. In some embodiments, the method includes using the hyperdimensional space from the plurality of simulations to generate one or more reduced order models (ROMs) using a regression technique or a machine learning technique. In some embodiments, the method includes generating a digital twin of the hydrocarbon system by instantiating the one or more ROMs at an operational point of the hydrocarbon system, and configuring the digital twin to use real-time data obtained from the hydrocarbon system. In some embodiments, the method includes estimating values of one or more variables of the hydrocarbon system in real-time using the digital twin. In some embodiments, the method includes controlling the hydrocarbon system based on the estimated values of the one or more variables.

In some embodiments, the one or more ROMs include a forward ROM, an inverse ROM, or a calibration ROM. In some embodiments, the forward ROM is configured to predict values of one or more variables of the system for a hypothetical scenario based on values of one or more controllable variables, values of one or more configuration parameters, and values of one or more calibration variables.

In some embodiments, the inverse ROM is configured to solve an inversion problem to estimate values of one or more system variables of the hydrocarbon system based on values of one or more controllable variables, values of one or more configuration parameters, values of one or more calibration variables, and values of one or more measured variables of the hydrocarbon system.

In some embodiments, the calibration ROM is configured to estimate one or more calibration variables for the forward ROM and the inverse ROM based on values of one or more controllable variables, values of one or more configuration parameters, values of one or more unmeasurable variables, and values of one or more measured variables. In some embodiments, the digital twin includes an instantiation of a plurality of ROMs, wherein one or more of the plurality of ROMs are configured to provide an output to a different ROM of the plurality of ROMs as an input.

In some embodiments, the method further includes performing an on-site test at the hydrocarbon system to obtain calibration data. In some embodiments, the method includes, at least one of (<NUM>) re-generating the one or more ROMs and re-generating the digital twin using the calibration data to generate a calibrated digital twin, or (<NUM>) providing the calibration data to a calibration ROM for use in updating one or more other ROMs of the digital twin.

In some embodiments, the re-generation includes an automated selection of an optimal combination of both a DOE sampling scheme, and ROM model and parameters, simultaneously in the presence of calibration measurements and a calibration match criteria. In some embodiments, the re-generation includes an iterative process and a Bayesian regularization technique.

Another implementation of the present disclosure is a system for generating and using a digital twin of a hydrocarbon system, according to some embodiments. In some embodiments, the system includes a processor. In some embodiments, the processor is configured to perform a plurality of simulations in a hyperdimensional space to generate outputs. In some embodiments, the processor is configured to use the outputs of the plurality of simulations to generate one or more reduced order models (ROMs) using a regression technique or a machine learning technique. In some embodiments, the processor is configured to generate a digital twin of the hydrocarbon system by instantiating the one or more ROMs at an operational point of the hydrocarbon system, and configuring the digital twin to use real-time data obtained from the hydrocarbon system. In some embodiments, the processor is configured to operate the hydrocarbon system based on outputs of the digital twin.

In some embodiments, the processor is further configured to estimate values of one or more variables of the hydrocarbon system in real-time using the digital twin and real-time data. In some embodiments, the real-time data includes at least one of a wellhead pressure, a flow line pressure, an injection pressure, an injection rate, a pump discharge pressure, a pump intake pressure, a voltage, a current, or a motor temperature of the hydrocarbon system.

In some embodiments, the processor is configured to perform an automatic calibration check of the digital twin. In some embodiments, performing the automatic calibration check includes obtaining measurements of one or more predictor variables of the hydrocarbon system, determining one or more quasi-static parameters using the measurements of the one or more predictor variables, and determining if the one or more quasi-static parameters have converged. In some embodiments, in response to determining that the one or more quasi-static parameters have not converged, the processor is configured to adjust one or more of the predictor variables and re-determine the one or more quasi-static parameters and re-determine if the one or more quasi-static parameters have converged.

In some embodiments, the processor is configured to perform an automatic calibration check of the digital twin. In some embodiments, performing the automatic calibration check includes obtaining measurements of one or more predictor variables of the hydrocarbon system, determining one or more quasi-static parameters using the measurements of the one or more predictor variables, determining a predicted response using the one or more quasi-static parameters, comparing the predicted response to an actual response of the hydrocarbon system to determine a prediction error of the response, and minimizing the prediction error by adjusting the quasi-static parameters and re-determining the predicted response, and re-comparing the predicted response to the actual response to determine the prediction error of the response.

In some embodiments, at least one of the ROMs of the digital twin is a transient ROM. In some embodiments, the transient ROM includes a filter function, the parameters of the filter function being one or more quasi-static parameters output by a calibration ROM. In some embodiments, the filter function is configured to use deconvolution and the filter function to determine a predicted response given an input of one or more measurements of the hydrocarbon system.

In some embodiments, the processor is configured to use a plurality of measurements from a first data source, and data of the operational point from a second data source to instantiate the one or more ROMs of the digital twin. In some embodiments, the plurality of measurements from the first data source and the data of the operational point are temporally synchronized with each other.

In some embodiments, the processor is configured to automatically temporally synchronize the plurality of measurements from the first data source, and the data of the operational point from the second data source. In some embodiments, the processor is configured to instantiate the one or more ROMs using a plurality of data of the operational point of the hydrocarbon system, each of the plurality of data of the operational point having a weighting indicating a confidence factor of each of the plurality of data of the operational point.

In some embodiments, the processor is configured to re-calculate parameters of the one or more ROMs over time and monitor changes of the parameters of the one or more ROMs. In some embodiments, the processor is configured to alert a technician in response to the parameters of the one or more ROMs changing by more than a threshold amount.

Another implementation of the present disclosure is a twinning tool for generating and using a digital twin of a hydrocarbon system, according to some embodiments. In some embodiments, the twinning tool includes processing circuitry configured to perform a plurality of simulations using design of experiments (DOE) techniques to create a hyperdimensional space mapping simulation inputs, outputs and attributes. In some embodiments, the processing circuitry is configured to use the hyperdimensional space from the plurality of simulations to generate a plurality of reduced order models (ROMs) using a curve-fitting technique. In some embodiments, the processing circuitry is configured to determine a plurality of quasi-static parameters by providing calibration data obtained from performing a test at the hydrocarbon system as inputs to the plurality of ROMs. In some embodiments, the processing circuitry is configured to generate a digital twin of the hydrocarbon system based on the plurality of quasi-static parameters and the plurality of ROMs. In some embodiments, the processing circuitry is configured to predict a response of the hydrocarbon system over a future time horizon using the digital twin, and display the predicted response of the hydrocarbon system over the future time period to a technician.

Before turning to the FIGURES, which illustrate the exemplary embodiments in detail, it should be understood that the present application is not limited to the details or methodology set forth in the description or illustrated in the FIGURES.

Referring particularly to <FIG>, a diagram of a system <NUM> is shown for generating a digital twin <NUM> of a hydrocarbon, oil, or petroleum system, or a device of the system. System <NUM> can implement one or more offline techniques <NUM> and one or more online or live techniques <NUM> to generate the digital twin <NUM>. The digital twin <NUM> may be an instantiation of one or more ROMs that digitally encapsulates necessary model attributes across an expected operating space as a system, and my include design, installation, and model variables. The digital twin <NUM> can be an instantiation of the ROMs at a particular point in time and may operate in real-time based on measurements and/or real-time information, shown as real-time inputs <NUM>. The digital twin <NUM> can output real-time outputs <NUM> of any of the ROMs that are included in the digital twin <NUM>. The digital twin <NUM> may be implemented as one of the live techniques <NUM> of the system <NUM>, using real-time inputs <NUM> (e.g., sensor data, measurements, etc.) and outputting real-time outputs <NUM> (e.g., predicted values of one or more variables of a system, calculated values of one or more variables of the system, values of calibration variables of the system, etc.). The digital twin <NUM> may be configured to estimate or predict values of variables that are unmeasurable such as gas oil ratio (GOR), water cut (WC), liquid flow rate, etc. It should be understood that these particular unmeasurable variables are presented as an example and should not be understood as limiting.

The offline techniques <NUM> can include using one or more simulators <NUM> to perform a design and execution of experiments (DOE) <NUM>. The simulators <NUM> and the DOE <NUM> can be multiple what-if scenarios in a hyperdimensional space (e.g., different values of speed of the pump or other parameters). For example, the simulators <NUM> may be different models, equations, operational curves, etc., of various components, sub-systems, or devices of the system that the digital twin <NUM> represents, and may also include various interrelationships (e.g., which models feed into each other, etc.) of the various components, sub-systems, devices, etc., of the system that the digital twin <NUM> represents. The simulators <NUM> and DOE <NUM> can use advanced techniques based on known information of the system that the digital twin <NUM> represents so that excessive numbers of simulations do not need to be simulated. For example, the simulations may be performed in a hyperdimensional space of various variables that the system which the digital twin <NUM> is to represent are expected to operate within. For example, if the system is a pump for a hydrocarbon system that is expected to operate at a pressure between <NUM> and <NUM> psi, the simulations may be performed for pressure in this range. In another example, if the system that the digital twin <NUM> represents is a hydrocarbon pump, the DOE <NUM> can simulate or estimate choke percentage, water output, etc., for different values of manipulated variables (e.g., speed or rpm of the system that the digital twin <NUM> represents), or different ranges of manipulated variables. The results of the DOE <NUM> may be operational or hypothetical (e.g., simulated operational) curves of different output variables of the system that the digital twin <NUM> represents, given different ranges or values of input variables. The DOE <NUM> may use Naive DOE techniques, or randomized DOE sampling techniques (e.g., latin hypercube DOE techniques, Sobol DOE techniques, Halton DOE techniques, etc.). In some embodiments, the randomized DOE sampling techniques overlap with operational range of all quantities of the digital twin to avoid extrapolation.

The results of the DOE <NUM> can be used to create ROMs, shown as ROM creation technique <NUM>. The ROMs can be any of a transient ROM (e.g., a reduced order model that outputs multiple values of variables for a transient or dynamic phase of the system that the digital twin <NUM> represents), a static ROM, (e.g., a reduced order model that outputs static variables for a steady state phase of the system that the digital twin <NUM> represents), a forward ROM (e.g., a reduced order model that predicts future values or what-if scenarios of various variables for one or more control decisions), an inverse ROM (e.g., a reduced order model that can be used to solve an inversion problem and estimate different system parameters based on actual measurements and/or calibration variables), or a calibration ROM (e.g., a reduced order model that can be used to estimate or predict different calibration variables of the system that the digital twin <NUM> represents). Transient ROMs may be more complex than static or steady-state ROMs and may require additional elaboration or further techniques for generation, such as deconvolution, gradient search techniques, etc. In some embodiments, inputs to tROMs are quasi-static parameters or outputs of calibration ROMs. In some embodiments, the tROMs output predictions that are used to solve a deconvolution problem in order to estimate unmeasured or unmeasurable dynamic system variables. In some embodiments, tROMs also include convolutional neural networks. The ROMs can be generated using an advanced regression technique, a neural network, and/or or machine learning technique. For example, the ROMs can be generated based on the outputs of the DOE <NUM> using a linear regression technique, a Gaussian process regression technique, neural networks, XGBoost for regression, LGBoost, an autoselect (e.g., a Bayesian-based) regression technique, etc..

The digital twin <NUM> may be generated based on the one or more ROMs that are created when performing the ROM creation technique <NUM>. For example, the digital twin <NUM> may include several of the ROMs and interrelationships between the ROMs (e.g., which ROM feeds an output to an input of a different ROM). In one example, the digital twin <NUM> includes a calibration ROM, an inverse ROM, and a forward ROM. Outputs of the calibration ROM can be provided to both the inverse ROM and the forward ROM. Outputs of the inverse ROM may be provided to the forward ROM.

The digital twin <NUM> includes one or more of the ROMs and can be instantiated at a particular point in time based on the real-time inputs <NUM>, according to some embodiments. The outputs of the ROMs that define the digital twin <NUM> for the instantiation at the particular point in time can the real-time outputs <NUM> of the digital twin <NUM>. In this way, the digital twin <NUM> operates based on real-time inputs <NUM> to provide real-time outputs <NUM>, according to some embodiments.

Referring still to <FIG>, a test <NUM> can be performed on measurable outputs of the system that the digital twin <NUM> represents. For example, the test <NUM> may be a well test if the system that the digital twin <NUM> represents is a hydrocarbon well pump. The test <NUM> can be performed by a technician or automatically at periodic intervals (e.g., every month, every six months, etc.). The test <NUM> can be performed to obtain different values of calibration variables or adjustments to the calibration variables of the system that the digital twin <NUM> represents. For example, if the digital twin <NUM> represents a hydrocarbon well pump, the calibration variables that are obtained by performing the test <NUM> can be Gas-oil-rate (GOR), Water Cut (WC), or a productivity index (PI) or reservoir pressure of the hydrocarbon system. The results of the test <NUM> (e.g., the calibration variables) can be used for a calibration <NUM> of the simulators <NUM> (e.g., to adjust, redefine, or update the simulators <NUM> based on real-world test results at the system that the digital twin <NUM> represents). The digital twin <NUM> can then be re-generated using the offline techniques <NUM> as described herein. In this way, the digital twin <NUM> can be intermittently or periodically re-calibrated in a non-real-time manner when the test <NUM> is performed and results of the test <NUM> are used to calibrate the simulators <NUM>. Alternatively, the results of the test <NUM> can also be provided to the digital twin <NUM> for determining new settings for the calibration variables (e.g., a tested calibration of the system that the digital twin <NUM> represents), if those variables were exercised as part of the original DOE. The real-time outputs <NUM> of the digital twin <NUM> may be used in a variety of applications, including, but not limited to, simulations, model predictive control (MPC) or optimization, feedback control of the system that the digital twin <NUM> represents, or dashboards. In some embodiments, test or calibration measurements are needed to avoid under-determination of the regression problem of generating the ROMs or to compensate for inaccuracies of underlying measurements or estimations. In some embodiments, calibration can be achieved by reperforming the simulations with adjusted simulation input parameters, correcting inaccurate measurements or estimates, and/or determining an output parameter for an inverse or forward ROM from a calibration ROM or procedure.

Referring now to <FIG>, a forward ROM <NUM> that can be generated using the techniques described in greater detail above with reference to <FIG> (and in greater detail below with reference to <FIG> and <FIG>) is shown, according to some embodiments. In some embodiments, the forward ROM <NUM> is configured to receive inputs of controllable variables <NUM>, configuration parameters <NUM>, and calibration variables <NUM>. In some embodiments, the forward ROM <NUM> is configured to output one or more predicted variables <NUM> (e.g., given values of the controllable variables <NUM>). The predicted variables <NUM> can be simulated values of the system that the digital twin <NUM> represents. The controllable variables <NUM> can be variables that represent an operational setting (e.g., an adjustable setting) of one or more actuators, motors, etc., or other controllable devices of the system that the digital twin <NUM> represents. The configuration parameters can be known parameters of the system that the digital twin <NUM> represents (e.g., well design, pump configuration, etc., if the system that the digital twin <NUM> represents is a hydrocarbon well pump). The calibration variables <NUM> may be outputs of a calibration ROM (e.g., calibration ROM <NUM> as described in greater detail below with reference to <FIG>) or results from the test <NUM> (e.g., manual measurements).

The forward ROM <NUM> can generally have the form: <MAT> where varpredict is multiple sets of time-series data of different variables that are predicted by the forward ROM <NUM>, varcontrol is multiple sets time-series data of different controllable variables (e.g., the controllable variables <NUM>), varconfig is multiple sets of time-series data of different configuration parameters (e.g., the configuration parameters <NUM>), varcal is multiple sets of time-series data of different calibration variables (e.g., the calibration variables <NUM>), and ffwd is the forward ROM <NUM> (e.g., a function). If the system that the digital twin <NUM> represents is a hydrocarbon well pump, the controllable variables <NUM> may include pump speed, choke position/percent, valve position, etc., the configuration parameters <NUM> may be well design or pump configuration parameters, the calibration variables <NUM> may be GOR, WC, PI, friction factor, etc., variables, and the predicted variables <NUM> may be pressure, temperature, torque, liquid flow rate, pump leakage, etc. The forward ROM <NUM> can output values of the predicted variables <NUM> (e.g., a response of the system) given different inputs of the controllable variables <NUM> (e.g., an impact on pressure, temperature, torque, liquid flowrate, pump leakage, boundary conditions, etc., that will occur if the speed of the pump or the choke is adjusted).

Referring now to <FIG>, an inverse ROM <NUM> that can be generated using the techniques described in greater detail above with reference to <FIG> (and in greater detail below with reference to <FIG> and <FIG>) is shown, according to some embodiments. In some embodiments, the inverse ROM <NUM> is configured to receive inputs of controllable variables <NUM>, configuration parameters <NUM>, calibration variables <NUM>, and measured variables <NUM>. The controllable variables <NUM> may be the same as the controllable variables <NUM> as described in greater detail above with reference to <FIG>. The configuration parameters <NUM> can be the same as the configuration parameters <NUM> as described in greater detail above with reference to <FIG>. The calibration variables <NUM> can include some of the calibration variables <NUM> as described in greater detail above with reference to <FIG>. The measured variables <NUM> can be any variables of the system that the digital twin <NUM> represents that can be obtained (e.g., in real-time) from one or more sensors of the system (e.g., pressure, temperature, torque, etc.).

The inverse ROM <NUM> is configured to solve an inversion problem to estimate or calculate system variables <NUM> for the system that the digital twin <NUM> represents based on the controllable variables <NUM>, the configuration parameters <NUM>, the calibration variables <NUM>, and the measured variables <NUM>. For example, given different control inputs, configuration of the system, calibration of the system, and sensor data of the system, the inverse ROM <NUM> can estimate values of the system variables <NUM> that the system had to result in the measured variables <NUM>. For example, the system variables <NUM> can include GOR, WC, liquid flowrate, pump leakage, etc., or any other variable that is difficult to measure. Advantageously, the inverse ROM <NUM> allows the inference of various parameters that are difficult to measure or that cannot be measured in real-time. Such unmeasurable parameters can be valuable and usable in a control scheme for the system that the digital twin <NUM> represents.

The inverse ROM <NUM> can generally have the form: <MAT> where varsys is multiple sets of time-series data of system variables that are estimated by the inverse ROM <NUM> (e.g., the system variables <NUM>), varcontrol is multiple sets of time-series data of different controllable variables (e.g., the controllable variables <NUM> or the controllable variables <NUM>), varconfig is multiple sets of time-series data of different configuration parameters (e.g., the configuration parameters <NUM> or the configuration parameters <NUM>), varcal is multiple sets of time-series data of different calibration variables (e.g., the calibration variables <NUM>), varmeas is multiple sets of time-series data of different measured variables (e.g., the measured variables <NUM>), and finv is the inverse ROM <NUM> (e.g., a function). The calibration variables <NUM> can include PI, friction factor, etc., and may be outputs of a calibration ROM (e.g., the calibration ROM <NUM> as described in greater detail below with reference to <FIG>) or may be values obtained from performing a test (e.g., the test <NUM>). In some embodiments, the calibration variables <NUM> are subject to constraints, similarly to as shown in <FIG> and described in greater detail below.

Referring now to <FIG>, a calibration ROM <NUM> that can be generated using the techniques described in greater detail above with reference to <FIG> (and in greater detail below with reference to <FIG> and <FIG>) is shown, according to some embodiments. In some embodiments, the calibration ROM <NUM> is configured to receive inputs of controllable variables <NUM>, configuration parameters <NUM>, and measured variables <NUM>. In some embodiments, the calibration ROM <NUM> is configured to output, predict, estimate, etc., calibration variables <NUM> and unmeasured variables <NUM>. The controllable variables <NUM> may be the same as the controllable variables <NUM> or the controllable variables <NUM> as described in greater detail above with reference to <FIG>, according to some embodiments. The configuration parameters <NUM> may be the same as the configuration parameters <NUM> or the configuration parameters <NUM> as described in greater detail above with reference to <FIG>. The unmeasurable variables <NUM> can be variables that are difficult to measure, For example, the unmeasurable variables <NUM> may be or include an of the system variables <NUM> as described in greater detail above with reference to <FIG>. The measured variables <NUM> can be or include measurement values obtained by performing the test <NUM> (e.g., GOR, WC, liquid flowrate, etc.) and can also include values that are measured by various sensors of the system that the digital twin <NUM> represents (e.g., pressure, temperature, torque, etc.). The calibration variables <NUM> can be estimated calibration factors or variables that are difficult to measure in real-time (e.g., PI, friction factor, etc.).

The calibration ROM <NUM> is configured to generate calibration values that can be used to update other calibration inputs of different ROMs of the digital twin <NUM> (e.g., the inverse ROM <NUM>, the forward ROM <NUM>, etc.). The calibration ROM <NUM> can generally have the form: <MAT> where varcal is multiple sets of time-series data of calibration variables that are estimated by the calibration ROM <NUM> (e.g., the calibration variables <NUM> or a portion of the calibration variables <NUM>), varunmeas is multiple sets of time-series data of different unmeasurable or system variables (e.g., the unmeasurable variables <NUM>, the system variables <NUM>) estimated by the calibration ROM <NUM>, varcontrol is multiple sets time-series data of different controllable variables (e.g., the controllable variables <NUM>, the controllable variables <NUM> or the controllable variables <NUM>), varconfig is multiple sets of time-series data of different configuration parameters (e.g., the configuration parameters <NUM>, the configuration parameters <NUM> or the configuration parameters <NUM>), and fcal is the calibration ROM <NUM> (e.g., a function). The outputs of the calibration ROM <NUM> can be provided as inputs to other ROMs of the digital twin <NUM> (e.g., the inverse ROM <NUM> and/or the forward ROM <NUM>).

Referring now to <FIG>, a diagram <NUM> shows interaction between a digital twin <NUM> and one or more applications <NUM>, according to some embodiments. The digital twin <NUM> can be the same as or similar to the digital twin <NUM> and may be generated using similar techniques. The digital twin <NUM> includes the calibration ROM <NUM>, the inverse ROM <NUM>, and the forward ROM <NUM>, according to some embodiments. Outputs of the calibration ROM <NUM> (e.g., the calibration variables <NUM>) are provided to the inverse ROM <NUM> and the forward ROM <NUM> as inputs (e.g., as the calibration variables <NUM> and the calibration variables <NUM>). The calibration ROM <NUM> can receive its inputs (e.g., the controllable variables <NUM>, the configuration parameters <NUM>, the unmeasurable variables <NUM>, and the measured variables <NUM>) from one or more external sources (e.g., from a controller of the system that the digital twin <NUM> represents such as the feedback controller <NUM>, from sensors of the system that the digital twin <NUM> represents, results of a test performed at the system of the digital twin, known configuration or system settings, etc.). The inverse ROM <NUM> and the forward ROM <NUM> can also receive similar inputs from the one or more external sources.

The calibration ROM <NUM> also provides its outputs (e.g., the calibration variables <NUM>) to a calibration report application <NUM>. The calibration report application <NUM> can be an external application that is configured to generate a report for a technician to view (e.g., graphs, charts, values of the calibration variables <NUM>, use of the calibration variables <NUM>, etc.).

The inverse ROM <NUM> is configured to provide its outputs to the forward ROM <NUM>, according to some embodiments. The inverse ROM <NUM> may also provide its outputs (e.g., the system variables <NUM>) to the calibration ROM <NUM> for use in determining the calibration variables <NUM>. For example, the inverse ROM <NUM> can provide the system variables <NUM> to the forward ROM <NUM>. The inverse ROM <NUM> and the forward ROM <NUM> both provide their outputs (e.g., the system variables <NUM> and the predicted variables <NUM>) to a simulation application <NUM>, an MPC/optimization application <NUM>, a feedback controller <NUM>, or a dashboard <NUM>. In this way, outputs of the digital twin <NUM> can be used to perform simulations, to perform MPC or optimization of the system that the digital twin <NUM> represents, to perform feedback or closed loop control (e.g., PID control) of the system that the digital twin <NUM> represents, and for data presentation on dashboards. In some embodiments, outputs of the MPC or optimization are provided to the inverse ROM <NUM>, the forward ROM <NUM>, or the calibration ROM <NUM> as inputs.

Referring now to <FIG>, the techniques described herein for the generation and use of a digital twin may be implemented in a twinning system <NUM> that includes a twinning tool <NUM> and various external applications. The twinning tool <NUM> is configured to generate a digital twin <NUM> and provide outputs of the digital twin <NUM> and/or the digital twin <NUM> itself to various external applications. As shown in <FIG>, the twinning tool <NUM> includes processing circuitry <NUM> including a processor <NUM> and a memory <NUM>. The processor <NUM> can be a general purpose or specific purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable processing components. The processor <NUM> may be configured to execute computer code and/or instructions stored in the memory <NUM> or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

The memory <NUM> can include one or more devices (e.g., memory units, memory devices, storage devices, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described in the present disclosure. The memory <NUM> can include random access memory (RAM), read-only memory (ROM), hard drive storage, temporary storage, non-volatile memory, flash memory, optical memory, or any other suitable memory for storing software objects and/or computer instructions. The memory <NUM> can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present disclosure. The memory <NUM> can be communicably connected to the processor <NUM> via the processing circuitry <NUM> and can include computer code for executing (e.g., by the processor <NUM>) one or more processes described herein.

The memory <NUM> includes one or more simulators <NUM>, a DOE manager <NUM>, a ROM generator <NUM>, a digital twin generator <NUM>, and a digital twin <NUM>, according to some embodiments. As shown in <FIG>, the twinning tool <NUM> is configured to receive real-time inputs from a system <NUM> (e.g., the system that the digital twin <NUM> represents). The real-time inputs may be obtained from sensors, measurement devices, meters, flow meters, etc., of the system <NUM>, according to some embodiments. The system <NUM> can be a hydrocarbon well pump, according to some embodiments. The twinning tool <NUM> is also configured to receive system information (e.g., from a technician, from a remote device, from a database, etc.), according to some embodiments. In some embodiments, the system information is meta-data regarding the system <NUM>. In some embodiments, the system information is stored in the memory <NUM> of the twinning tool <NUM>.

In some embodiments, the twinning tool <NUM> is also configured to receive independent test results (e.g., results of a test performed at the system <NUM> by a technician). A technician can perform a test at the system <NUM> (e.g., a well test) to obtain one or more measurements and provide the one or more measurements to the twinning tool <NUM> (e.g., via a user interface, a smartphone, a touchscreen device, etc.). It should be understood that the functionality of the twinning tool <NUM> can be implemented locally at the system <NUM> (e.g., on a single processing circuit) or may be implemented remotely and/or in a distributed manner (e.g., in a cloud computing system). For example, the twinning tool <NUM> can be cloud based such that the twinning tool <NUM> receives the real-time inputs, the system information, and the independent test results at a remote location, performs its functionality, and then provides outputs (e.g., the digital twin, the digital twin outputs, etc.) to one or more applications (e.g., a closed loop controller <NUM>, an MPC/optimization system <NUM>, one or more simulators <NUM>, dashboards <NUM>, edge devices <NUM>, etc.) that are positioned locally at the system <NUM> or are positioned remotely from the system <NUM> in the cloud computing system.

The simulators <NUM> can be or include one or more functions, models, operational curves, etc., that represent different portions of the system <NUM>, and/or one or more interrelationships of the one or more functions, models, operational curves, etc., of the different portions of the system <NUM> so that outputs of the system <NUM> can be simulated, according to some embodiments. The simulators <NUM> can be configured to implement a multi-variable or hyper-dimensional simulation of the system <NUM> to generate different outputs of the system <NUM> given different inputs of the system <NUM> (e.g., control inputs, temperature settings, flow rates, pump speed, etc., depending on a type of the system <NUM>), according to some embodiments. For example, the simulators <NUM> may be configured to perform a high-fidelity simulation of the system <NUM>. For example, the simulators <NUM> can include an electric submersible pump (ESP) simulator, a rod pump dynamic simulator, a pipe simulator, etc. The simulation outputs of the simulators <NUM> may be in the form of multi-dimensional graphs, curves, surface plots, etc., that express relationships between different variables (e.g., input and output variables of the system <NUM>), according to some embodiments.

In some embodiments, the DOE manager <NUM> is configured to use the simulators <NUM> to implement the one or more simulations by performing one or more DOE techniques. The DOE techniques can include Naive DOE techniques, randomized DOE techniques, latin hypercube DOE techniques, Sobol DOE techniques, Halton DOE techniques, etc. The DOE manager <NUM> uses the simulators <NUM> to generate the simulation outputs and provides the simulation outputs to the ROM generator <NUM>. For example, the DOE manager <NUM> can provide one or more multi-dimensional graphs to the ROM generator <NUM>. The DOE manager <NUM> may implement any of the techniques of the DOE <NUM> as described in greater detail above with reference to <FIG>.

The ROM generator <NUM> is configured to use the simulation outputs provided by the DOE manager <NUM> that are generated using the simulators <NUM> to generate one or more ROMs based on the simulation outputs, according to some embodiments. The ROMs can be generated by the ROM generator <NUM> using an advanced regression technique and the simulation outputs of the simulators <NUM>, according to some embodiments. For example, the ROM generator <NUM> can be configured to use a linear regression technique, a Gaussian process regression technique, neural networks, machine learning techniques, a Bayesian-based regression technique, etc. The ROMs can include the calibration ROM <NUM>, the inverse ROM <NUM>, the forward ROM <NUM>, or a transient ROM <NUM>.

Referring still to <FIG>, the digital twin generator <NUM> is configured to receive the ROMs from the ROM generator <NUM> and generate the digital twin <NUM> using the ROMs, according to some embodiments. The digital twin generator <NUM> is configured to instantiate the ROMs obtained from the ROM generator <NUM> using the real-time inputs, and define one or more interrelationships between the ROMs to generate the digital twin <NUM>. In some embodiments, the digital twin <NUM> is or is similar to the digital twin <NUM> or the digital twin <NUM> as described in greater detail above. The digital twin <NUM> can be configured to estimate values of various calibration variables, system variables, and predicted variables. For example, if the system <NUM> is a hydrocarbon well pump, the digital twin <NUM> can be configured to output predicted variables such as: pressure of the hydrocarbon well pump, temperature of the hydrocarbon well pump, torque of the hydrocarbon well pump, liquid flowrate, pump leakage, etc., system variables such as: GOR, WC, liquid flowrate, pump leakage, etc., and/or calibration variables such as: PI, friction factor, etc..

The digital twin <NUM> is configured to provide any of the outputs discussed above (e.g., the predicted variables, the system variables, and/or the calibration variables, etc.) to one or more external applications such as the closed loop controller <NUM>, the MPC/optimization system <NUM>, the simulators <NUM>, the dashboards <NUM>, and/or the edge devices <NUM>. It should be understood that this list is not exhaustive and that the digital twin <NUM> may provide its outputs to additional external applications. In some embodiments, the twinning tool <NUM> is configured to provide the digital twin <NUM> to any of the closed loop controller <NUM>, the MPC/optimization system <NUM>, the simulators <NUM>, the dashboards <NUM>, and/or the edge devices <NUM> for implementation and use of the digital twin <NUM> locally.

In some embodiments, the digital twin generator <NUM> is configured to calibrate the digital twin <NUM> based on the independent test results or calibration variables obtained by performing the independent test at the system <NUM>. For example, the digital twin generator <NUM> may re-instantiate the digital twin <NUM> using the calibration variables obtained by performing the independent test at the system <NUM>. In some embodiments, the simulators <NUM>, the DOE manager <NUM>, and the ROM generator <NUM> are configured to re-perform their functionality using the calibration variables of the independent test results to re-generate the ROMs. If the system <NUM> is a hydrocarbon well pump, the calibration variables obtained by performance of the independent test can be GOR, WC, and liquid flowrate.

The closed loop controller <NUM> is configured to use the digital twin outputs and/or the digital twin <NUM> to perform closed-loop control of the system <NUM>, according to some embodiments. For example, the closed loop controller <NUM> can implement a PID control scheme to operate the system <NUM>. The MPC/optimization system <NUM> can be configured to minimize, maximize, or otherwise optimize a cost function (e.g., a reward function) relative to one or more constraints by adjusting one or more control variables over a future time horizon, according to some embodiments. In some embodiments, the MPC/optimization system <NUM> may use the digital twin <NUM> for the system <NUM> as a model of the system <NUM>, to estimate a value of the objective function, or to impose constraints on the objective function. In some embodiments, the MPC/optimization system <NUM> is configured to determine high-level control decisions for the system <NUM>, and may provide the high-level control decisions to the closed loop controller <NUM>. In some embodiments, the dashboards <NUM> are configured to use to digital twin and/or the digital twin outputs to generate dashboards for a technician and provide the dashboards to the technician.

Referring to <FIG>, a flow diagram of a process <NUM> for generating a digital twin based on one or more ROMs is shown, according to some embodiments. Process <NUM> includes steps <NUM>-<NUM>, and can be performed by system <NUM> or by the twinning tool <NUM>. Process <NUM> advantageously can be implemented to generate a digital twin of a system (e.g., a hydrocarbon well pump) that has a reduced complexity when compared to various other simulations. The digital twin may be implemented or used in various applications such as a closed loop or feedback controller of a system that the digital twin represents, an MPC or optimization system, one or more simulators, a dashboard, and/or an edge device.

Process <NUM> includes performing multiple simulations in a hyperdimensional space to generate outputs (step <NUM>), according to some embodiments. In some embodiments, step <NUM> is configured to perform simulations using the simulators <NUM>. In some embodiments, step <NUM> is performed by DOE manager <NUM> and simulators <NUM>. Results of the simulations may include multi-dimensional graphs, surface plots, etc., showing relationships between different variables of the system that the digital twin represents.

Process <NUM> includes using the outputs of the multiple simulations to generate one or more reduced order models (ROMs) using a regression or machine learning technique (step <NUM>), according to some embodiments. In some embodiments, step <NUM> is performed by the ROM generator <NUM> using any of the techniques described in greater detail above with reference to <FIG>. In some embodiments, the ROMs include a calibration ROM, an inverse ROM, a forward ROM, and/or a transient ROM. The calibration ROM can be configured to estimate one or more configuration parameters (e.g., PI, friction factor, etc.), according to some embodiments. In some embodiments, the inverse ROM is configured to estimate one or more system variables (e.g., GOR, WC, liquid flowrate, pump leakage, etc.). For example, the inverse ROM can be configured solve an inversion problem and may receive various controllable variables, configuration parameters, calibration variables, and measured variables for a specific condition of the system and estimate system variables that must have been the case to achieve the measured variables, and the controllable variables, according to some embodiments. In some embodiments, the forward ROM is configured to predict or estimate predicted variables (e.g., measureable variables, system variables, etc.) given specific conditions (e.g., given different values of controllable variables, configuration parameters, or calibration variables).

Process <NUM> includes generating a digital twin of the system using the one or more ROMs, the digital twin including at least one of the one or more ROMs (step <NUM>), according to some embodiments. In some embodiments, the digital twin is the digital twin <NUM>, the digital twin <NUM>, etc., or any other digital twin described herein. Step <NUM> can be performed by the digital twin generator <NUM> of the twinning tool <NUM>, according to some embodiments. The digital twin can include the forward ROM, the inverse ROM, and/or the calibration ROM, and may include an interrelationship between the ROMs so that outputs of certain ROMs are fed into other ROMs as inputs, according to some embodiments. In some embodiments, the digital twin is an instantiation of the one or more ROMs and uses real-time data (e.g., sensor data) from the system that it represents. In this way, steps <NUM>-<NUM> may be performed off-line, while the ROM is used online with real-time data.

Process <NUM> includes using the digital twin to predict or output values of one or more variables of the system in a real-time application (step <NUM>), according to some embodiments. In some embodiments, the digital twin is implemented in an on-line mode and is configured to receive real-time data from the system that it represents. The real-time data that the digital twin receives may depend on a particular application of the digital twin, according to some embodiments. The digital twin can use the ROMs to output different sets of variables including predicted variables, system variables, and calibration variables, according to some embodiments. In some embodiments, the predicted variables include pressure, temperature, torque, liquid flowrate, and pump leakage of the system that the digital twin represents. In some embodiments, the system variables include GOR, WC, liquid flow rate, and pump leakage of the system that the digital twin represents. In some embodiments, the calibration variables include PI and friction factor.

Process <NUM> includes performing an independent test on measurable outputs of the system that the digital twin represents (step <NUM>), according to some embodiments. In some embodiments, for example, if the system is a hydrocarbon well pump, the test may be a well test to measure GOR, WC, and liquid flowrate of the hydrocarbon well pump. In some embodiments, step <NUM> is performed by a technician at the system that the digital twin represents. A well test can include updating one or more calibration knobs or quasi-static parameters of the digital twin.

Process <NUM> includes performing a calibration based on results of the independent test (step <NUM>), according to some embodiments. In some embodiments, step <NUM> is performed by digital twin generator <NUM> by providing new calibration values as inputs to the various ROMs of the digital twin. In some embodiments, step <NUM> is performed by the simulators <NUM>, the DOE manager <NUM>, and the ROM generator <NUM> to re-generate the ROMs based on new calibration values that are obtained.

Process <NUM> includes updating one or more parameters of the digital twin or of the ROMs of the digital twin based on the calibration (step <NUM>), according to some embodiments. Step <NUM> can be performed by the simulators <NUM>, the DOE manager <NUM>, and the ROM generator <NUM>, according to some embodiments. In response to performing step <NUM>, process <NUM> can return to step <NUM>, or alternatively to step <NUM>. It should be understood that steps <NUM>-<NUM> (or alternatively steps <NUM>-<NUM>) may be performed in a non-real time basis (e.g., every month, every six months, etc.). In some embodiments, steps <NUM>-<NUM> (or steps <NUM>-<NUM>) are only performed in response to step <NUM> if the independent test that is performed indicates that the digital twin needs to be re-calibrated.

Referring now to <FIG>, the systems and methods described herein can be implemented to generate a digital twin or an inverse ROM for an ESP well <NUM>, according to some embodiments. Diagram <NUM> shows an example configuration of different simulation models or simulators that can be used to generate the inverse ROM for the ESP well <NUM>, according to some embodiments. In some embodiments, the inverse ROM for the ESP well <NUM> includes one or more analytical models <NUM> and one or more numerical models <NUM>, a drive model <NUM>, a formation model <NUM>, and a flowline model <NUM>. The analytical models <NUM> include a transformer model <NUM>, a cable model <NUM>, and a motor model <NUM>, according to some embodiments. The numerical models <NUM> include a pipe model <NUM>, a pump model <NUM>, a well model <NUM>, and a choke model <NUM>, according to some embodiments. In some embodiments, the different models described herein use variables or parameters such as voltage, current, frequency, speed, torque, density, viscosity, formation pressure, productivity index (PI), derating, intake temperature, intake pressure, in flow, output wellhead pressure, flow, WC, and GOR.

In some embodiments, one or more of the variables or parameters are measured values (e.g., measured and provided to a digital twin as real-time data). In some embodiments, one or more of the variables or parameters are obtained by performing a hyperdimensional simulation (e.g., performed when generating the inverse ROM). In some embodiments, one or more of the variables or parameters can be obtained by performing an on-site test, or can be determined by a calibration ROM. In some embodiments, one or more of the variables or parameters are measured values or set values (e.g., known or fixed values).

Referring now to <FIG>, a diagram <NUM> shows a calibration ROM <NUM> and an inverse ROM <NUM> that function together to model an ESP well (e.g., the ESP well <NUM>), according to some embodiments. The calibration ROM <NUM> receives inputs of speed, torque, Pi and Pd (e.g., values of a PID control scheme), measured values of flowrate Q, WC, and GOR, and predicted pump leakage (PL), according to some embodiments. Using these inputs the calibration ROM <NUM> outputs calibration variables including an updated choke opening and an updated torque derating, according to some embodiments. The calibration variables are provided as inputs to the inverse ROM <NUM>, which uses the updated choke opening and the updated torque derating to predict flowrate Q, WC, GOR, and PL, according to some embodiments. In some embodiments, the calibration ROM <NUM> and the inverse ROM <NUM> can be instantiated at a particular operating point of the ESP well, and brought online to function as a digital twin of the ESP well using real-time data. The calibration ROM <NUM> and the inverse ROM <NUM> can be created or generated using the techniques described in greater detail above (e.g., by the twinning tool <NUM> as described in greater detail with reference to <FIG>), according to some embodiments.

Referring now to <FIG>, a graph <NUM> shows a difference between an estimated flow and a measured flow of the ROMs shown in diagram <NUM>, according to some embodiments. Graph <NUM> shows the difference between measured flow and estimated flow over time, according to some embodiments. If an error between the measured flow and the estimated flow exceeds a corresponding threshold value, the calibration ROM <NUM> and the inverse ROM <NUM> can be re-trained or calibrated to minimize overall error, according to some embodiments.

Referring now to <FIG>, a graph <NUM> shows a difference between an estimated WC and a measured WC of the ROMs shown in diagram <NUM>, according to some embodiments. Graph <NUM> shows the difference between the estimated WC and the measured WC over time, according to some embodiments. If an error between the measured WC and the estimated WC exceeds a corresponding threshold value, the calibration ROM <NUM> and the inverse ROM <NUM> can be re-trained or calibrated to minimize overall error, according to some embodiments.

Referring now to <FIG>, a graph <NUM> shows a difference between an estimated GOR and a measured GOR of the ROMs shown in diagram <NUM>, according to some embodiments. Graph <NUM> shows the difference between the estimated GOR and the measured GOR over time, according to some embodiments. If an error between the measured GOR and the estimated GOR exceeds a corresponding threshold value, the calibration ROM <NUM> and the inverse ROM <NUM> can be re-trained or calibrated to minimize overall error, according to some embodiments.

Referring now to <FIG>, a graph <NUM> shows estimated PL over time, according to some embodiments. In some embodiments, PL may be difficult to measure so a comparison between estimated and measured PL cannot be obtained. However, if error between the estimated flow and the measured flow, the estimated WC and the measured WC, and the estimated GOR and the measured GOR is minimal, the estimated PL can be confidently assumed to be accurate.

Referring now to <FIG>, a diagram <NUM> for a gas lift well <NUM> shows different simulation models or simulators that can be used to generate a forward ROM for the gas lift well <NUM>, according to some embodiments. The models can include a dry hole (DH) well model <NUM>, a formation model <NUM>, an injection well model <NUM>, a production well model <NUM>, a gauge model <NUM>, a sulfur (SF) valve model <NUM>, a flow line model <NUM>, and a stock tank model <NUM>, according to some embodiments. In some embodiments, the different models described herein are configured to use variables or parameters such as formation pressure, GOR, WC, PI, fluid flow rate, gas flow rate, downhole pressure, injection pressure, injection rate, wellhead pressure, flow line pressure, etc. In some embodiments, one or more of the variables or parameters described herein are variables that are always measureable. In some embodiments, one or more of the variables or parameters described herein are unmeasurable values. In some embodiments, one or more of the variables or parameters described herein are values that can be obtained from a well test or outputs of a calibration ROM, or otherwise obtained by calibration. A forward ROM for the diagram <NUM> can be generated using the systems and methods described herein (e.g., by the twinning tool <NUM> as described in greater detail above with reference to <FIG>), according to some embodiments.

Referring now to <FIG>, a dashboard <NUM> is shown that can be presented on a webpage, according to some embodiments. The dashboard <NUM> may be one of the dashboards <NUM> that are based on outputs of a digital twin (e.g., the digital twin <NUM>) or a digital twin itself, according to some embodiments. In some embodiments, the dashboard <NUM> includes one or more graphs or tables of time-series data such as different outputs, predicted values, estimated values, system values, etc., of a system that a digital twin represents. For example, the graphs may include gas lift performance graphs, nodal analysis graphs, pressure to temperature ratio graphs, temperature graphs, liquid rate graphs, etc. The dashboard <NUM> may be generated and provided to a technician for further analysis and control, according to some embodiments. The dashboard <NUM> can also include different menus or sub-menus for navigation, according to some embodiments.

Advantageously, the systems and methods described herein can be used to provide a reliable digital twin of a real-world system. Using a digital twin that is an instantiation of one or more ROMs can improve a calculation speed, as opposed to using simulations, which may be computationally heavy. The digital twin can be implemented in an online mode to use real-time measurements from the real-world system (e.g., a hydrocarbon well pump) for real-time control, analysis, optimization, etc. The digital twin can be calibrated periodically to ensure that the digital twin accurately represents the real-world system.

Referring to <FIG>, various implementations of a calibration ROM are shown illustrated as block diagrams, according to some embodiments. Specifically, <FIG> shows a general workflow of a calibration ROM (e.g., calibration ROM <NUM>, the calibration ROM <NUM>, etc.), <FIG> shows a first optimization implementation with calibration ROMs, and <FIG> shows a second optimization implementation with calibration ROMs. Any of the block diagrams, techniques, systems, etc., described herein with reference to FIGS. _-_ may be implemented by the twinning tool <NUM> (e.g., the processing circuitry <NUM> thereof), remote processing circuitry, distributed processing circuitry, one or more servers, a local controller, a cloud computing system, etc., or any combination thereof.

Referring to <FIG>, a diagram <NUM> illustrates the implementation of a calibration ROM <NUM>, according to some embodiments. In some embodiments, the calibration ROM <NUM> is generated by a ROM builder <NUM> that uses a curve-fitting technique to determine parameters of the calibration ROM <NUM> (e.g., to instantiate the calibration ROM <NUM> based on simulation data, shown as DOE simulation data). In some embodiments, the calibration ROM <NUM> is generated using any of the techniques described in greater detail above with reference to <FIG> (e.g., by the twinning tool <NUM>). For example, the DOE simulation data may be outputs of the simulators <NUM> and/or the DOE manager <NUM>, and the ROM builder <NUM> may be the ROM generator <NUM>.

Once built, generated, instantiated, etc., by the ROM builder <NUM>, the calibration ROM <NUM> can be configured to predict, output, estimate, calculate, etc., one or more quasi-static parameters given inputs of predictor variables. The predictor variables can include any calibration measurements or normal measurements provided by a system (e.g., by the system <NUM>, by sensors of the ESP well <NUM>, etc.). For example, the predictor variables may be measurements of various parameters of the system that is being twinned (e.g., the system <NUM>). In some embodiments, if the system is an ESP, the predictor variables may include GOR.

The quasi-static parameters can be parameters that are used by an inverse ROM to predict one or more of the predictor variables (e.g., a predicted version of the predictor variables, where the predictor variables are measurements). The quasi-static parameters, for example, may be a separator efficiency in the case of an ESP so that one or more inverse ROMs may use the quasi-static parameters to predict values of the GOR (e.g., one of the predictor variables).

Referring to <FIG>, a diagram <NUM> of a first optimization implementation is shown, according to some embodiments. The diagram <NUM> includes a ROM builder <NUM> that is configured to generate one or more calibration ROMs, shown as calibration ROM <NUM>, and calibration ROM <NUM>, an optimizer <NUM>, and an adjuster <NUM>. The system of the first optimization shown in diagram <NUM> can be implemented on any processing circuitry of the digital twin (e.g., the twinning tool <NUM>, remote processing circuitry, etc.). The first optimization implementation shown in diagram <NUM> can be implemented in order to determine a factor or a derating factor that achieves convergence or stability with other factors (e.g., derating factors) for quasi-static parameters of the digital twin. For example, the calibration ROM <NUM> may be a calibration ROM for a first quasi-static parameter that outputs a factor of the first quasi-static parameter to an inverse ROM and to the calibration ROM <NUM>. Similarly, the calibration ROM <NUM> may be for a second quasi-static parameter, and output the calculated second quasi-static parameter or factor of the second quasi-static parameter to the optimizer <NUM> and/or to the inverse ROM. In some embodiments, more than two calibration ROMs <NUM>-<NUM> are used in series, with each calibration ROM associated with a corresponding quasi-static parameter, and outputting the corresponding quasi-static parameter to another of the calibration ROMs. Each of the multiple calibration ROMs can also be provided a specific unknown quasi-static parameter as an input.

As shown in <FIG>, the optimizer <NUM> can monitor the received quasi-static parameters from the calibration ROMs <NUM> and <NUM> to determine if the quasi-static parameters are varying or if the quasi-static parameters have converged (e.g., are stable). If the quasi-static parameters have not converged, the optimizer <NUM> may notify the adjuster <NUM>, and the adjuster may adjust or change one of the quasi-static parameters (e.g., the unknown quasi-static parameter) and provide the adjusted or changed quasi-static parameter to the calibration ROMs <NUM> and <NUM>. The optimizer <NUM> and the adjuster <NUM> can continue checking the quasi-static parameters and adjusting at least one of the quasi-static parameters until the optimizer <NUM> identifies that the quasi-static parameters have converged or are no longer varying. This may indicate that a value of the unknown quasi-static parameter has been found that results in an internally stable or converged ROM or digital twin. The quasi-static parameters, including the value or factor of the unknown quasi-static parameter may be provided to an inverse ROM as inputs.

Advantageously, the first optimization implementation shown in diagram <NUM> of <FIG> can be used for under-defined or underdetermined problems (e.g., problems where one or more of the quasi-static parameters are unknown). The quasi-static parameters can be adjusted, tuned, changed, etc., and monitored to observe their convergence until convergence or stability is met.

Referring to <FIG>, a diagram <NUM> of a second optimization implementation is shown, according to some embodiments. The diagram <NUM> includes a ROM builder <NUM> for calibration ROMs, calibration ROMs <NUM>, a ROM builder <NUM> for inverse ROMs, inverse ROMs <NUM>, a cost function <NUM>, and an optimizer <NUM>. The ROM builder <NUM> is configured to calculate, determine, instantiate, etc., the calibration ROMs <NUM>, and the ROM builder <NUM> is configured to calculate, determine, instantiate, etc., the inverse ROMs <NUM>, according to some embodiments. In some embodiments, the ROM builder <NUM> and the ROM builder <NUM> are configured to implement any of the functionality or techniques of the ROM generator <NUM> to generate the inverse ROMs <NUM> and the calibration ROMs <NUM>. The ROM builder <NUM> and the ROM builder <NUM> can be configured to perform a curve-fitting technique to generate the calibration ROMs <NUM> and the inverse ROMs <NUM>. In some embodiments, the techniques described herein with reference to <FIG> are part of an automatic calibration check. The second optimization implementation can be performed to check consistency between the calibration ROMs (e.g., inputs of the calibration ROMs) and outputs of the inverse ROMs.

The calibration ROMs <NUM> receive various values of calibration measurements, shown as predictor variables, and output predicted quasi-static parameters, according to some embodiments. The predicted quasi-static parameters are provided, in combination with normal measurements as inputs to the inverse ROMs <NUM>, according to some embodiments.

The calibration ROMs <NUM> are configured to output predicted quasi-static parameters to the inverse ROMs <NUM> based on the predictor variables (e.g., measurements of the predictor variables and other normal measurements), according to some embodiments. The inverse ROMs <NUM> receive the predicted quasi-static parameters from the calibration ROMs <NUM>, and one or more normal measurements of calibration points of the system, according to some embodiments. In some embodiments, the inverse ROMs <NUM> are configured to use the predicted quasi-static parameters and the normal measurements to output a predicted response (e.g., a predicted flow rate). The cost function <NUM> obtains both the response predicted by the inverse ROMs <NUM> for the predicted quasi-static parameters and the normal measurements, and the actual response as measured, according to some embodiments. In some embodiments, the predicted response is a response that is predicted to occur in the system given the current measured conditions (the normal measurements) and the predicted quasi-static parameters that define the behavior of the system. Since the current conditions are measured conditions, and the predicted response can be compared to the actual response, any differences or discrepancies between the predicted response of the system and the real response of the system may indicate that adjustments should be made to the quasi-static parameters in order to more accurately define the behavior of the system.

The cost function <NUM> compares the predicted response and the real response of the system and quantifies an error (e.g., a prediction error) between the predicted response and the real response, according to some embodiments. The optimizer <NUM> uses the error provided by the cost function <NUM> and adjusts the calibration ROMs <NUM>, the predicted quasi-static parameters, or both, to drive the error towards zero (e.g., minimizing the cost function <NUM>).

The cost function <NUM> may determine error between a predicted response and an actual response for a single variable or parameter, or for multiple variables or parameters. If the cost function <NUM> models multiple variables or parameters (e.g., flow rate, GOR, etc.), then each of the prediction errors associated with the multiple variables or parameters can be assigned a weighting value so that the cost function <NUM> outputs an overall or weighted prediction error which the optimizer <NUM> may minimize (by adjusting the predicted quasi-static parameters or by tuning the calibration ROMs <NUM>). In some embodiments, the optimization problem solved by the optimizer <NUM> includes constraints on variability of the quasi-static parameters so that the optimizer <NUM> minimizes the prediction error (e.g., the output of the cost function <NUM>) by adjusting the calibration ROMs <NUM> and/or the predicted quasi-static parameters. The functionality and techniques described herein with reference to <FIG> or <FIG> can be performed at a specific operating point (e.g., a calibration point) of the system, or at multiple operating points (e.g., multiple calibration points) of the system, according to some embodiments.

Referring to <FIG>, a diagram <NUM> of a workflow for a transient ROM ("tROM") is shown, according to some embodiments. The diagram <NUM> includes a ROM builder <NUM>, calibration ROMs <NUM>, a parameterized filter function <NUM>, and deconvolution <NUM>. In some embodiments, the ROM builder <NUM> is the same as or similar to any of the ROM builders <NUM>, <NUM>, <NUM>, <NUM>, the ROM generator <NUM>, etc. tROMs, as opposed to using curve-fitting techniques, use convolution and deconvolution since tROMs predict a time curve as a function of another time curve (e.g., a transient response given temporally changing inputs), according to some embodiments.

In some embodiments, the calibration ROMs are configured to receive measurements of the predictor variables and output quasi-static parameters. The quasi-static parameters are used as parameters in a filter, shown as parameterized filter function <NUM>, according to some embodiments. In some embodiments, the parameterized filter function <NUM> is an analytical parameterized model, and the quasi-static parameters are parameters of the model. In some embodiments, the model or the parameterized filter function <NUM> is configured to predict or calculate dependencies between dynamic behaviors. In some embodiments, outputs of the parameterized filter function <NUM> are deconvoluted at deconvolution <NUM> to determine a predicted response of the system. In some embodiments, the parameterized filter function <NUM> and the deconvolution <NUM> define a tROM <NUM>.

Referring to <FIG>, a graph <NUM> illustrating collected data over time of a system (e.g., an ESP) includes a series of GOR points, a series of WC points, a series of liquid rate points, a series of discharge pressure, a series of intake pressure, a series of tubing head pressure, and a series of drive frequency. The graph <NUM> illustrates the performance of a well test and recordation of a data point of GOR, a data point of WC, and a data point of liquid rate, according to some embodiments. As shown in the graph <NUM>, a first well test <NUM> is performed between times t<NUM> and t<NUM> (represented by lines <NUM> and <NUM>) while the data for the first well test (i.e., values of the GOR, the WC, and the liquid rate) are recorded as being obtained at time t<NUM> (represented by line <NUM>). Similarly, a second well test <NUM> is performed between times t<NUM> and t<NUM> (represented by lines <NUM> and <NUM>) while the data for the second well test (i.e., values of the GOR, the WC, and the liquid rate) are recorded as being obtained at time t<NUM> (represented by line <NUM>). Accordingly, it can be seen in <FIG> that the timestamp of the data for the well tests (e.g., calibration data) is out of sync with the actual time at which the well test is performed. This may be due to obtaining the GOR, WC, and liquid rate data from different sources as the discharge pressure, the intake pressure, etc. However, using data in a digital twin that is out of sync with other data may result in discrepancies in outputs of the digital twin. In some embodiments, the calibration data of the well test (e.g., the GOR, the WC, and the liquid rate) are average values collected over the duration of the well test. Accordingly, to synchronize the calibration data of the well test from one source with other data of the well test from a second source may require synchronizing time periods (e.g., synchronizing both start and end times associated with the calibration data and the other data). In some embodiments, the GOR, the WC, and the liquid rate are the independent test results as shown in <FIG>.

In some embodiments, the synchronization is performed manually by a technician. For example, the data collected may be the real-time inputs (e.g., sensor data obtained from the system <NUM>) or reported data from a technician performing the well test. In some embodiments, the technician can synchronize the data to account for errors in the calibration or well-test data relative to when the well test was performed, different time zones between the different sources of data, etc. In some embodiments, the synchronization is performed automatically by the digital twin <NUM> or the digital twin generator <NUM>. For example, the digital twin generator <NUM> may obtain data from different sources (e.g., the real-time inputs, or historical data from the system <NUM>, and the independent test results provided by a technician) and identify a same data point between the two sources (e.g., an identical value of a specific set of data). The digital twin generator <NUM> may synchronize the timestamps of the data from either source so that the timestamp of the same data point match, and also adjust the rest of the data in the sources, thereby synchronizing the data from the two sources. In some embodiments, the graph <NUM> is displayed to a user (e.g., via a display screen, on the dashboard <NUM>) so that the user can observe the responses of the various obtained data and synchronize the calibration data with the other data sources.

Referring to <FIG>, a graph <NUM> illustrates obtained data from an ESP (e.g., discharge pressure, intake pressure, tubing head pressure, and drive frequency), predicted liquid rate (illustrated by series <NUM>), and well test or calibration data sets <NUM> and <NUM> (including GOR, WC, and liquid rate), according to some embodiments. The graph <NUM> illustrates a first well test <NUM> and a second well test <NUM>, according to some embodiments. In some embodiments, the predicted liquid rate is an output of a digital twin that is generated using the calibration data sets <NUM> and <NUM>. In some embodiments, a weighting of the calibration sets <NUM> or <NUM>, or a weighting of the output of the digital twin (e.g., the liquid rate) is assigned a weighting based on an expected accuracy of the well tests <NUM> or <NUM>. In some embodiments, the weightings are user assigned values. In some embodiments, the weightings range from <NUM>% to <NUM>%. For example, the well test <NUM> is shown having a shorter duration than the duration of the well test <NUM>, and accordingly may provide less trustworthy data. Accordingly, the user may provide a weighting of <NUM>% to the calibration data set <NUM> and a weighting of <NUM>% to the calibration data set <NUM> for generation of the digital twin. The weightings may be used to determine a weighted average of the values of the calibration data sets <NUM> and <NUM> (which can be used in any of the techniques described in greater detail above with reference to any of the calibration ROMs). In some embodiments, the time synchronization techniques describe in detail above with reference to <FIG> and the weighting techniques described with reference to <FIG> are performed in the context of the digital twin in a closed loop fashion. In some embodiments, the graph <NUM> and/or the graph <NUM> is/are presented to the user on the dashboard <NUM> so that the user can provide (e.g., to the digital twin generator <NUM>) different weightings to the calibration data sets <NUM> and <NUM>, adjust time synchronization, etc., and view the resulting effect of the adjustments to the weighting and the time synchronization on the digital twin output.

Referring to <FIG>, a graph <NUM> illustrates the tracking of values of various quasi-static parameters of a digital twin (e.g., the quasi-static parameters of the digital twin <NUM>) over time, according to some embodiments. In some embodiments, the graph <NUM> illustrates tracking values of a first quasi-static parameter, a second quasi-static parameter, and a third quasi-static parameter over time. In some embodiments, the twinning tool <NUM> or the digital twin <NUM> is configured to compare the values of the quasi-static parameters over time (e.g., series <NUM>, <NUM>, or <NUM>) to corresponding thresholds (e.g., thresholds <NUM>, <NUM>, and <NUM>). In some embodiments, the thresholds <NUM>, <NUM>, or <NUM> are based on averages of a last n number of values of the quasi-static parameters. If the values of the quasi-static parameters deviate outside of the thresholds <NUM>, <NUM>, or <NUM>, this may indicate that an improper calibration test (e.g., a well test) has been performed, and an alarm may be provided to a user (e.g., by the twining tool <NUM>, the dashboard <NUM>, etc.). In some embodiments, the thresholds <NUM>, <NUM>, or <NUM> allow the quasi-static parameters to deviate by a certain percentage of the previous value or an average of a previous number of values of the quasi-static parameter. For example, if the previous value of the second quasi-static parameter is <NUM>, then the thresholds may be <NUM> +/- <NUM>(<NUM>).

Referring to <FIG>, a diagram <NUM> illustrates an alternative to any of the calibration ROMs as described herein, according to some embodiments. It should be understood that the system illustrated in the diagram <NUM> and described herein with reference to <FIG> may be used in place of any of the calibration ROMs as described throughout this document.

The calibration ROM may be implemented as an optimization system as shown in <FIG>, according to some embodiments. Specifically, the inverse ROMs <NUM> may receive the controllable variables <NUM> and the configuration parameters <NUM>, and output one or more measurement predictions (e.g., predicted values of measurable variables). The measurement predictions can be predictions of pressure, temperature, torque, GOR, WC, flowrate, etc., or any other variables or parameters that can be measured, according to some embodiments. In some embodiments, the measurement predictions and the measured variables <NUM> are used (e.g., at junction <NUM>) to calculate a prediction error (e.g., a difference between the measurement predictions and the measured variables <NUM>). The prediction error can be used in a weighted cost function <NUM> which is provided to an optimization solver <NUM>. The optimization solver <NUM> can output, adjust, predict, etc., unmeasurable variables <NUM> for the inverse ROM <NUM>, according to some embodiments. In this way, the optimization solver <NUM> can vary or adjust the values of the unmeasurable variables <NUM> to drive the weighted cost function <NUM> or prediction error towards zero. The unmeasurable variables <NUM> provided to and used by the inverse ROMs <NUM> for the determination of the measurement predictions may be a type of tuning parameter or internal parameter that are used by the inverse ROMs <NUM>. Accordingly, determining optimal values of the unmeasurable variables <NUM> for the inverse ROMs <NUM> provides an aposteriori optimization that can be performed in place of a calibration ROM.

As utilized herein, the terms "approximately", "about", "substantially", and similar terms are intended to have a broad meaning in harmony with the common and accepted usage by those of ordinary skill in the art to which the subject matter of this disclosure pertains. It should be understood by those of skill in the art who review this disclosure that these terms are intended to allow a description of certain features described and claimed without restricting the scope of these features to the precise numerical ranges provided. Accordingly, these terms should be interpreted as indicating that insubstantial or inconsequential modifications or alterations of the subject matter described and claimed are considered to be within the scope of the invention as recited in the appended claims.

The terms "coupled," "connected," and the like, as used herein, mean the joining of two members directly or indirectly to one another. Such joining may be stationary (e.g., permanent) or moveable (e.g., removable, releasable, etc.). Such joining may be achieved with the two members or the two members and any additional intermediate members being integrally formed as a single unitary body with one another or with the two members or the two members and any additional intermediate members being attached to one another.

References herein to the positions of elements (e.g., "top," "bottom," "above," "below," etc.) are merely used to describe the orientation of various elements in the figures.

Conjunctive language such as the phrase "at least one of X, Y, and Z," unless specifically stated otherwise, is otherwise understood with the context as used in general to convey that an item, term, etc. may be either X, Y, Z, X and Y, X and Z, Y and Z, or X, Y, and Z (i.e., any combination of X, Y, and Z). Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y, and at least one of Z to each be present, unless otherwise indicated.

Claim 1:
A method for generating and using a digital twin of a hydrocarbon system, the method characterized by:
performing a plurality of simulations using design of experiments, DOE, techniques to create a hyperdimensional space mapping simulation inputs, outputs and attributes;
using the hyperdimensional space from the plurality of simulations to generate one or more reduced order models, ROMs, using a regression technique or a machine learning technique;
generating a digital twin of the hydrocarbon system based on data from an on-site test at the hydrocarbon system by instantiating the one or more ROMs at an operational point of the hydrocarbon system, and configuring the digital twin to use real-time data obtained from the hydrocarbon system;
estimating values of one or more variables of the hydrocarbon system in real-time using the digital twin; and
controlling the hydrocarbon system based on the estimated values of the one or more variables.