CARBON CAPTURE AND STORAGE WORKFLOWS AND OPERATIONS THROUGH

SUBSURFACE STRUCTURE SIMULATION

Cross Reference to Related applications

[0001] This application claims priority to, and the benefit of, U.S. Provisional Patent Application No. 63/376,173, entitled, “Carbon Capture and Storage Workflows and Operations through Subsurface Structure Simulation,” and filed September 19, 2022, which is incorporated herein by reference in its entirety. This application is related to Published PCT application WO2022/125, 852 entitled “Processing Subsurface Data with Uncertainty for Modelling and Field Planning,” and filed December 10, 2021.

Background

[0002] Oilfield exploration and production efforts generally include collecting data that represents a subsurface volume of interest, and then modeling the physical characteristics of the subsurface volume based on the data. There are many sources for such data, including seismic surveys and well logs. This data permits complex models to be built, which may depict the geology of the subsurface volume, fluid migration over time in the volumes, and other aspects. Because of the high complexity of the models, even with extensive computing resources, it can take hours or even days to build and simulate conditions in the models. Thus, when the physical characteristics of the subsurface volume change, or when simulating different operating conditions in the model, solving such models can present significant delays.

[0003] Accordingly, refining and rebuilding models is frequently done in the exploration and well planning setting, where time and resources are focused on making accurate and precise determinations of where and how to drill a well. The pace of advancement at this stage can be slow, and thus there is both time available and upfront benefit to updating and running the models, prior to drilling.

[0004] At the production stage, the models can be helpful in determining operating parameters (e.g., choke positions, injection rates, etc.), but the delay and expense incurred by running the models is frequently too high. Thus, operators tend to make rough estimations for the parameters, based largely on approximations and calculations that use a small sampling of the total available data. Further, these techniques may rely on input and output measurements, without analysis of the factors (e.g., geology) that lead to the output from the input, or the potential for these factors to change. Thus, for example, in a waterflooding context, operators may consider combinations of injection rates and production rates from injection and production wells, respectively, in a given field, and make determinations based on those measurements. Relatively little consideration may be given to the geology of the field, since accounting for the geology generally calls for an accurate model, and accurately modeling the geology and simulating the fluid flow is too costly and slow to be performed with sufficient frequency (e.g., daily) to keep up with the acquisition of new data. [0005] Accordingly, there would be a benefit to systems and methods that permit accurately modeling the subsurface, including the geology, and which are quick enough to be used and updated during operations.

[0006] Moreover, many techniques disclosed herein may be applied in the context of carbon capture and storage (CCS), or carbon capture, utilization, and storage (CCUS), where CO2 is stored in the subsurface of the earth. After reviewing systems and methods that permit accurately modeling the subsurface, including the geology and operations updates capabilities, we turn to reviewing disclosures related to automate modeling and rapid assessment of CCS subsurface operations, and how they may be improved through workflows to generate actionable insights and instructions for injectivity into, capacity of, and integrity of subsurface structures for CO2 and other greenhouse gasses.

[0007] Modelling processes are frequently used for business or project planning, e g., at various stages in oilfield exploration and production, to name one specific example. These modelling processes are based on data that may have an amount of uncertainty associated therewith. Moreover, the models may be used to model or “simulate” uncertain processes, e.g., within a probabilistic framework. Further, a project or business opportunity can have many connected elements, each individually complex and uncertain and where effective planning accounts for such uncertainty in the modelling at the individual stages.

[0008] Existing technology often involves the selection of one or a small number of “representative” realizations from the uncertain modelling processes. These realizations are intended to capture a range of uncertainty, e.g., P10, P50, P90. However, this sort of selection can introduce bias and other unintended side-effects. Moreover, the selection of these representative realizations can be a difficult, slow, and manual/non-repeatable process. Other solutions may use an inferred sampling of supposed realizations drawn by examining the statistical envelope of the model output; however, such approaches cannot easily maintain the self-consistency of the information in each such supposed realization, which reduces the value of the downstream assessments.

[0009] Accordingly, it may be desirable to propagate uncertainty through the various modelling and processing phases consistently, and without, for example, attempting to make “representative” determinations in one modelling domain to benefit an entirely separate modelling domain. Thus, there is a need for methods and computing systems that can employ more effective and accurate methods for identifying, isolating, transforming, and/or processing various aspects of seismic signals and other subsurface data, uncertainty, and other data that is collected from a subsurface region or other multi-dimensional space, and then using that data as processed to aid in project planning workflows.

Summary

[0010] A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. One general aspect includes a computing system for controlling parameters in subsurface operation for example, but not limited to, an oilfield or a gas field. The computing system also includes receiving volume data representing a volume of interest, where the volume of interest includes, but is not limited to including, a subterranean volume of interest or a reservoir, where the volume data includes, but is not limited to including, seismic surveys, well logs, core samples, lidar surveys, satellite imagery, interferometric synthetic aperture radar (InSAR)), and gravity surveys, and where the volume data are used to calculate or estimate physical characteristics of the volume of interest. The system also includes, but is not limited to including, constructing a numerical model based at least on the physical characteristics, where numerical model output from the numerical model is deterministic based on numerical model input to the numerical model, where the numerical model is, for example, but not limited to, a reservoir model, a geological model, a geochemical model, or a combination thereof, where the numerical model simulates fluid flow or other physical process in the volume of interest, where the numerical model is based on dynamics of the fluid flow, and/or geomechanics and/or geology of the volume of interest. The system also includes training a proxy model to predict the numerical model output for a volume of interest, for example, but not limited to, a subterranean volume, where the proxy model is based on the numerical model and is calibrated to historical performance and measurements, where multiple executions of the numerical model produce the numerical model output data that are used to train the proxy model, where the proxy model is, for example, but not limited to, an artificial neural network or a machine learning model. The system also includes validating the proxy model, where the validating includes: executing the proxy model to produce proxy model output data, analyzing confidence levels of the proxy model output data, and continually training the proxy model if, for example, the confidence levels in the proxy model output data do not meet a first pre-selected threshold and/or if correlations between the proxy model output data and the numerical model output data do not meet a second pre-selected threshold. The system also includes receiving subsurface operation data representing the subsurface operation, where the subsurface operation includes, but is not limited to including, a production operation, a recovery operation, a waterflooding operation, a well treatment, a fracturing operation, a gas storage operation, or other operation or combination of operations, where the subsurface operation is performed, at least partially, in the subterranean volume of interest, where the subsurface operation data are collected, for example, but not limited to, continuously, hourly, daily, monthly, or other interval, where the subsurface operation data include, but are not limited to including, injection rates/pressures, choke positions, production rates/pressures, and/or changes in geological conditions, and where receiving the subsurface operation data includes, but is not limited to including, performing waterflood pattern balancing daily by accessing daily injection and production rates. The system also includes, but is not limited to including, predicting the numerical model output data by providing subsurface operation data to the proxy model creating the predicted proxy model output data, where the predicted proxy model output data includes, but is not limited to including, one or more predicted performance indicator, where predicting the numerical model output data includes, but is not limited to including, predicting a production or injection rate from individual wells or a group of wells during a subsurface operation, based at least on the injection pressure, where predicting the numerical model output data includes, but is not limited to including, predicting injection schemes that enhance production or storage under pre-selected constraints, where the pre-selected constraints include, but are not limited to including, bottom hole pressure and reservoir pressure. The system also includes, but is not limited to including, evaluating performance based at least upon the one or more predicted performance indicator, and where the one or more predicted performance indicator includes, but is not limited to including, conformance, voidage replacement, maps, operation efficiency, curvefitting, or other indicator. The system also includes, but is not limited to including, selecting an operating parameter that, based on the one or more predicted performance indicator, needs modification, where the one or more predicted performance indicator is provided to a user, where the user modifies the operating parameter based on the one or more predicted performance indicator, where the operating parameter includes, but is not limited to including, choke position or injection rates, and where the proxy model is trained to evaluate the operating parameter with respect to the one or more predicted performance indicator and recommend modifications to the operating parameter, or automatically implement the modifications. The system also includes feeding the modifications to the proxy model. The system also includes updating the numerical model periodically, where the updating includes, but is not limited to including, feeding field data collected during an operation to the numerical model, updating a representation of the volume of interest in the numerical model, executing the numerical model to produce the numerical model output data, and training the proxy model with the numerical model output data. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0011] One general aspect includes a computing system for controlling parameters in a subsurface operation by understanding an impact of introducing new data to a numerical model of the subsurface operation without having to simulate the numerical model. The computing system also includes one or more processors. The system also includes a memory storing instructions that, when executed by at least one of the one or more processors, cause the computing system to perform operations for predicting one or more performance indicator and updating the numerical model, the operations may include, but are not limited to including, receiving volume data representing a volume of interest; constructing the numerical model based at least on physical characteristics of the volume of interest; training a proxy model to predict numerical model output data for the volume of interest; receiving subsurface operation data representing the subsurface operation; predicting the numerical model output data by providing subsurface operation data to the proxy model creating predicted proxy model output data; determining the one or more performance indicators based on the predicted proxy model output data; selecting an operating parameter that, based on the one or more predicted performance indicator, needs modification; and updating the numerical model periodically based on data associated with the subsurface operation and the predicted proxy model output data. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0012] One general aspect includes a computing system for controlling parameters in a subsurface operation by understanding an impact of introducing new data to a numerical model of the subsurface operation without having to simulate the numerical model. The computing system also includes one or more processors. The system also includes a memory storing instructions that, when executed by at least one of the one or more processors, cause the computing system to perform operations for predicting one or more performance indicators and updating the numerical model, the operations may include, but are not limited to including, receiving volume data representing a volume of interest, constructing the numerical model based at least on physical characteristics of the volume of interest, training a proxy model to predict numerical model output data for the volume of interest, receiving subsurface operation data representing the subsurface operation, predicting the numerical model output data by providing subsurface operation data to the proxy model creating predicted proxy model output data, and updating the numerical model periodically based on data associated with the subsurface operation and the predicted proxy model output data. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0013] Embodiments of the disclosure include a method including training a proxy model to predict output from a reservoir model of a subterranean volume, receiving data representing an oilfield operation performed at least partially in the subterranean volume, predicting one or more performance indicators for the oilfield operation using the proxy model, and updating the reservoir model based at least in part on the one or more performance indicators predicted in the proxy model.

[0014] Embodiments of the disclosure include a computing system including one or more processors, and a memory storing instructions that, when executed by at least one of the one or more processors, cause the computing system to perform operations including training a proxy model to predict output from a reservoir model of a subterranean volume, receiving data representing an oilfield operation performed at least partially in the subterranean volume, predicting one or more performance indicators for the oilfield operation using the proxy model, and updating the reservoir model based at least in part on the one or more performance indicators predicted in the proxy model.

[0015] Embodiments of the disclosure include a non-transitory computer-readable medium storing instructions that, when executed by at least one processor of a computing system, cause the computing system to perform operations, the operations including training a proxy model to predict output from a reservoir model of a subterranean volume, receiving data representing an oilfield operation performed at least partially in the subterranean volume, predicting one or more performance indicators for the oilfield operation using the proxy model, and updating the reservoir model based at least in part on the one or more performance indicators predicted in the proxy model.

[0016] Embodiments of the disclosure include a method including receiving input data representing a subterranean volume, generating a multi-domain model of the subterranean volume, statistically sampling one or more of the realizations of the multi-domain model based at least in part on an uncertainty associated therewith, simulating the sampled one or more of the realizations using a field development planning engine, and generating a field development plan based at least in part on the simulated one or more of the realizations.

[0017] In an embodiment, generating the multi-domain model includes generating an ensemble of a plurality of realizations of a first model based in least in part on the input data, an uncertainty of the input data, and an uncertainty of the first model, generating a plurality of second realizations of a second model based at least in part on the ensemble of the plurality of first realizations and an uncertainty of the second model, and including the plurality of second realizations in the ensemble in connection with the realizations of the first model.

[0018] In an embodiment, generating the ensemble of the plurality of first realizations includes simulating a process using the first model.

[0019] In an embodiment, generating the multi-domain model includes generating an uncertainty space in which the ensemble is represented. The realizations of the multi-domain model are distributed in the uncertainty space. Further, statistically sampling the one or more of the realizations includes statistically sampling the one or more realizations from the uncertainty space based on a distribution of the realizations in the uncertainty space.

[0020] In an embodiment, statistically sampling from the uncertainty space includes identifying one or more areas of the uncertainty space that are underrepresented in the sampling, overrepresented in the sampling, represent one or more outlier realizations, or a combination thereof.

[0021] In an embodiment, the first model includes the model of at least one physical characteristic of the subterranean volume, and the second model includes a commercial model, an economic model, or a combination thereof.

[0022] In an embodiment, statistically sampling includes using machine learning, k-means clustering, probability bands, or a combination thereof to select the one or more realizations from among other, non-selected realizations.

[0023] In an embodiment, the method includes visualizing the field development plan, at least a portion of the multi-domain model, or both, to support one or more field development processes. [0024] In an embodiment, the method includes, before generating the multi-domain model, storing one or more shared files in a central database including file relationship data and locations of bulk files, extracting one or more simulation models from the one or more shared files, and evaluating metadata associated with the one or more simulation models to identify one or more simulation models to use in the multi-domain model.

[0025] In specific embodiments, a computer program is provided that comprises instructions for implementing the method of any one of the described embodiments in the foregoing paragraphs.

[0026] Embodiments of the disclosure include a non-transitory, computer-readable medium storing instructions that, when executed by at least one processor of a computing system, cause the computing system to perform operations. The operations include receiving input data representing a subterranean volume, generating a multi-domain model of the subterranean volume, statistically sampling one or more of the realizations of the multi-domain model based at least in part on an uncertainty associated therewith, simulating the sampled one or more of the realizations using a field development planning engine, and generating a field development plan based at least in part on the simulated one or more of the realizations.

[0027] Embodiments of the disclosure include a computing system including one or more processors, and a memory system including one or more non-transitory computer-readable media storing instructions that, when executed by at least one of the one or more processors, cause the computing system to perform operations. The operations include receiving input data representing a subterranean volume, generating a multi-domain model of the subterranean volume. Generating the multi-domain model includes generating an ensemble of a plurality of realizations of a first model based in least in part on the input data, an uncertainty of the input data, and an uncertainty of the first model, generating a plurality of second realizations of a second model based at least in part on the ensemble of the plurality of first realizations and an uncertainty of the second model, and including the plurality of second realizations in the ensemble in connection with the realizations of the first model. The first model includes a model of at least one physical characteristic of the subterranean volume, and the second model includes a commercial model, an economic model, or a combination thereof. The operations also include statistically sampling one or more of the realizations of the multi-domain model based at least in part on an uncertainty associated therewith, simulating the sampled one or more of the realizations using a field development planning engine, and generating a field development plan based at least in part on the simulated one or more of the realizations.

[0028] Embodiments of the disclosure include a computing system configured to receive input data representing a subterranean volume, generate a multi-domain model of the subterranean volume, statistically sample one or more of the realizations of the multi-domain model based at least in part on an uncertainty associated therewith, simulate the sampled one or more of the realizations using a field development planning engine, and generate a field development plan based at least in part on the simulated one or more of the realizations.

[0029] Embodiments of the disclosure include a computing system including means for receiving input data representing a subterranean volume, means for generating a multi-domain model of the subterranean volume, means for statistically sampling one or more of the realizations of the multi-domain model based at least in part on an uncertainty associated therewith, means for simulating the sampled one or more of the realizations using a field development planning engine, and means for generating a field development plan based at least in part on the simulated one or more of the realizations.

[0030] Thus, the computing systems and methods disclosed herein are more effective methods for processing collected data that may, for example, correspond to a surface and a subsurface region. These computing systems and methods increase data processing effectiveness, efficiency, and accuracy. Such methods and computing systems may complement or replace conventional methods for processing collected data. 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.

Brief Description of the Drawings

[0031] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present teachings and together with the description, serve to explain the principles of the present teachings. In the figures:

[0032] Figure 1 illustrates an example of a system that includes various management components to manage various aspects of a geologic environment, according to an embodiment.

[0033] Figure 2 illustrates a flowchart of a method for controlling parameters in an oilfield operation, according to an embodiment.

[0034] Figure 3 illustrates another flowchart of a method, according to an embodiment.

[0035] Figure 4A illustrates a diagram of a system for implementing a proxy model using machine learning, to control a production process, according to an embodiment.

[0036] Figure 4B illustrates a diagram of a system for controlling a production environment, according to an embodiment.

[0037] Figure 5 illustrates a workflow that may be implemented by a system, according to an embodiment.

[0038] Figure 6 illustrates another diagrammatic view of the system, according to an embodiment. The production system referred to in the figure embodies both production and injection systems in the field operations.

[0039] Figure 7 illustrates a diagrammatic view of a workflow for controlling parameters in an subsurface injection or production operation, according to an embodiment.

[0040] Figure 8 illustrates a schematic view of a computing system, according to an embodiment.

[0041] Figures 9 - 12 illustrate various aspects of CCS planning and analysis considerations.

[0042] Figures 13 - 14 illustrate various aspects of computing systems for Agile Reservoir Modeling and CCS modeling, according to an embodiment. [0043] Figure 15 illustrates a conceptual workflow for implementation of CCS study types for injectivity, capacity, and integrity and containment risks implemented in accordance with an embodiment.

[0044] Figure 16 illustrates a flowchart of a method for field development, e.g., generating a field development plan, according to an embodiment.

[0045] Figure 17 illustrates a flowchart of a method for generating a multi-domain model, according to an embodiment.

[0046] Figure 18 illustrates an example of a system for field development planning, according to an embodiment.

[0047] Figure 19 illustrates a conceptual view of building an ensemble of realizations of a multidimensional model, according to an embodiment.

[0048] Figure 20 illustrates a flowchart of a method, showing operations for a reservoir analysis process, according to an embodiment.

[0049] Figure 21 illustrates an example conceptual topography for a system to implement such a reservoir analysis process, according to an embodiment.

[0050] Figures 22A, 22B, and 22C illustrate a flowchart of a method, according to an embodiment.

Detailed Description

[0051] Embodiments of the present disclosure may provide a system and method for controlling oilfield operations, e.g., production operations such as waterflooding. For example, the systems and methods may provide for evaluation of performance of the ongoing production operations, so as to identify and implement field-actions that increase efficiency. The system may connect engineering evaluations with the reservoir models in an on-time or real-time basis. Further, the system updates and accesses reservoir model(s) automatically. Embodiments also include an analyser system that includes data and engines for storage and management of static and dynamic data, models, and computational engines such as reservoir simulators. Further, systems and methods for agile reservoir modelling for creating, updating, calibrating, and executing reservoir simulation model related to the ongoing waterflooding are disclosed. Artificial intelligence (Al) driven enhancements for creating and updating machine learning (ML) driven proxy models, are also disclosed. Systems and methods for translating and communicating the reservoir model outcomes to the operation management are also provided. Further, surveillance, operation management and decision dashboards for visualization of decisions, performance indicators, results, etc., are provided.

[0052] Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings and figures. In the following detailed description, numerous specific details are set forth in order to provide a 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 methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0053] It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first object or step could be termed a second object or step, and, similarly, a second object or step could be termed a first object or step, without departing from the scope of the present disclosure. The first object or step, and the second object or step, are both, objects or steps, respectively, but they are not to be considered the same object or step.

[0054] The terminology used in the description herein is for the purpose of describing particular embodiments and is not intended to be limiting. As used in this description and the appended claims, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any possible combinations of one or more of the associated listed items. It will be further understood that the terms “includes,” “including,” “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Further, as used herein, the term “if’ may be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context.

[0055] Attention is now directed to processing procedures, methods, techniques, and workflows that are in accordance with some embodiments. Some operations in the processing procedures, methods, techniques, and workflows disclosed herein may be combined and/or the order of some operations may be changed.

[0056] Figure 1 illustrates an example of a system 100 that includes various management components 110 to manage various aspects of a geologic environment 150 (e.g., an environment that includes a sedimentary basin, a reservoir 151, one or more faults 153-1, one or more geobodies 153-2, etc.). The system 100 may also include a framework 170, as discussed below. For example, the management components 110 may allow for direct or indirect management of sensing, drilling, injecting, extracting, etc., with respect to the geologic environment 150. In turn, further information about the geologic environment 150 may become available as feedback 160 (e.g., optionally as input to one or more of the management components 110).

[0057] In the example of Figure 1, the management components 110 include a seismic data component 112, an additional information component 114 (e.g., well/logging data), a processing component 116, a simulation component 120, an attribute component 130, an analysis/visualization component 142 and a workflow component 144. In operation, seismic data and other information provided per the components 112 and 114 may be input to the simulation component 120.

[0058] In an example embodiment, the simulation component 120 may rely on entities 122. Entities 122 may include earth entities or geological objects such as wells, surfaces, bodies, reservoirs, etc. In the system 100, the entities 122 can include virtual representations of actual physical entities that are reconstructed for purposes of simulation. The entities 122 may include entities based on data acquired via sensing, observation, etc. (e.g., the seismic data 112 and other information 114). An entity may be characterized by one or more properties (e.g., a geometrical pillar grid entity of an earth model may be characterized by a porosity property). Such properties may represent one or more measurements (e.g., acquired data), calculations, etc.

[0059] In an example embodiment, the simulation component 120 may operate in conjunction with a software framework such as an object-based framework. In such a framework, entities may include entities based on pre-defined classes to facilitate modeling and simulation. A commercially available example of an object-based framework is the MICROSOFT® .NET® framework (Redmond, Washington), which provides a set of extensible object classes. In the .NET® framework, an object class encapsulates a module of reusable code and associated data structures. Object classes can be used to instantiate object instances for use in a program, script, etc. For example, borehole classes may define objects for representing boreholes based on well data.

[0060] In the example of Figure 1, the simulation component 120 may process information to conform to one or more attributes specified by the attribute component 130, which may include a library of attributes. Such processing may occur prior to input to the simulation component 120 (e.g., consider the processing component 116). As an example, the simulation component 120 may perform operations on input information based on one or more attributes specified by the attribute component 130. In an example embodiment, the simulation component 120 may construct one or more models of the geologic environment 150, which may be relied on to simulate behavior of the geologic environment 150 (e.g., responsive to one or more acts, whether natural or artificial). In the example of Figure 1, the analysis/visualization component 142 may allow for interaction with a model or model-based results (e.g., simulation results, etc.). As an example, output from the simulation component 120 may be input to one or more other workflows, as indicated by a workflow component 144.

[0061] As an example, the simulation component 120 may include one or more features of a simulator such as the ECLIPSE® reservoir simulator (Schlumberger Limited, Houston Texas), the INTERSECT® reservoir simulator (Schlumberger Limited, Houston Texas), etc. As an example, a simulation component, a simulator, etc. may include features to implement one or more meshless techniques (e.g., to solve one or more equations, etc.). As an example, a reservoir or reservoirs may be simulated with respect to one or more enhanced recovery techniques (e.g., consider a thermal process such as SAGD, etc.).

[0062] In an example embodiment, the management components 110 may include features of a commercially available framework such as the PETREL® seismic to simulation software framework (Schlumberger Limited, Houston, Texas). The PETREL® framework provides components that allow for optimization of exploration and development operations. The PETREL® framework includes seismic to simulation software components that can output information for use in increasing reservoir performance, for example, by improving asset team productivity. Through use of such a framework, various professionals (e.g., geophysicists, geologists, and reservoir engineers) can develop collaborative workflows and integrate operations to streamline processes. Such a framework may be considered an application and may be considered a data- driven application (e g., where data is input for purposes of modeling, simulating, etc ). [0063] In an example embodiment, various aspects of the management components 110 may include add-ons or plug-ins that operate according to specifications of a framework environment. For example, a commercially available framework environment marketed as the OCEAN® framework environment (Schlumberger Limited, Houston, Texas) allows for integration of addons (or plug-ins) into a PETREL® framework workflow. The OCEAN® framework environment leverages .NET® tools (Microsoft Corporation, Redmond, Washington) and offers stable, user- friendly interfaces for efficient development. In an example embodiment, various components may be implemented as add-ons (or plug-ins) that conform to and operate according to specifications of a framework environment (e.g., according to application programming interface (API) specifications, etc.).

[0064] Figure 1 also shows an example of the framework 170, which includes a model simulation layer 180 along with a framework services layer 190, a framework core layer 195, and a modules layer 175. The framework 170 may include the commercially available OCEAN® framework where the model simulation layer 180 is the commercially available PETREL® modelcentric software package that hosts OCEAN® framework applications. In an example embodiment, the PETREL® software may be considered a data-driven application. The PETREL® software can include a framework for model building and visualization.

[0065] As an example, a framework may include features for implementing one or more mesh generation techniques. For example, a framework may include an input component for receipt of information from interpretation of seismic data, one or more attributes based at least in part on seismic data, log data, image data, etc. Such a framework may include a mesh generation component that processes input information, optionally in conjunction with other information, to generate a mesh.

[0066] In the example of Figure 1, the model simulation layer 180 may provide domain objects 182, act as a data source 184, provide for rendering 186, and provide for various user interfaces 188. Rendering 186 may provide a graphical environment in which applications can display their data while the user interfaces 188 may provide a common look and feel for application user interface components.

[0067] As an example, the domain objects 182 can include entity objects, property objects and optionally other objects. Entity objects may be used to geometrically represent wells, surfaces, bodies, reservoirs, etc., while property objects may be used to provide property values as well as data versions and display parameters. For example, an entity object may represent a well where a property object provides log information as well as version information and display information (e.g., to display the well as part of a model).

[0068] In the example of Figure 1, data may be stored in one or more data sources (or data stores, generally physical data storage devices), which may be at the same or different physical sites and accessible via one or more networks. The model simulation layer 180 may be configured to model projects. As such, a particular project may be stored where stored project information may include inputs, models, results and cases. Thus, upon completion of a modeling session, a user may store a project. At a later time, the project can be accessed and restored using the model simulation layer 180, which can recreate instances of the relevant domain objects.

[0069] In the example of Figure 1, the geologic environment 150 may include layers (e.g., stratification) that include a reservoir 151 and one or more other features such as the fault 153-1, the geobody 153-2, etc. As an example, the geologic environment 150 may be outfitted with any of a variety of sensors, detectors, actuators, etc. For example, equipment 152 may include communication circuitry to receive and to transmit information with respect to one or more networks 155. Such information may include information associated with downhole equipment 154, which may be equipment to acquire information, to assist with resource recovery, etc. Other equipment 156A may be located remote from a well site and include sensing, detecting, emitting or other circuitry. Such equipment may include storage and communication circuitry to store and to communicate data, instructions, etc. As an example, one or more satellites 156B may be provided for purposes of communications, data acquisition, etc. For example, Figure 1 shows a satellite 156B in communication with the network 155 that may be configured for communications, noting that the satellite may additionally or instead include circuitry for imagery (e.g., spatial, spectral, temporal, radiometric, etc.).

[0070] Figure 1 also shows the geologic environment 150 as optionally including equipment 157 and 158 associated with a well that includes a substantially horizontal portion that may intersect with one or more fractures 159. For example, consider a well in a shale formation that may include natural fractures, artificial fractures (e.g., hydraulic fractures) or a combination of natural and artificial fractures. As an example, a well may be drilled for a reservoir that is laterally extensive. In such an example, lateral variations in properties, stresses, etc. may exist where an assessment of such variations may assist with planning, operations, etc. to develop a laterally extensive reservoir (e.g., via fracturing, injecting, extracting, etc ). As an example, the equipment 157 and/or 158 may include components, a system, systems, etc. for fracturing, seismic sensing, analysis of seismic data, assessment of one or more fractures, etc.

[0071] As mentioned, the system 100 may be used to perform one or more workflows. A workflow may be a process that includes a number of worksteps. A workstep may operate on data, for example, to create new data, to update existing data, etc. As an example, a workflow may operate on one or more inputs and create one or more results, for example, based on one or more algorithms. As an example, a system may include a workflow editor for creation, editing, executing, etc. of a workflow. In such an example, the workflow editor may provide for selection of one or more pre-defined worksteps, one or more customized worksteps, etc. As an example, a workflow may be a workflow implementable in the PETREL® software, for example, that operates on seismic data, seismic attribute(s), etc. As an example, a workflow may be a process implementable in the OCEAN® framework. As an example, a workflow may include one or more worksteps that access a module such as a plug-in (e.g., external executable code, etc ).

[0072] Figure 2 illustrates a flowchart of a method 200 for controlling parameters in an oilfield operation, according to an embodiment. In some embodiments, the oilfield operation may be a production (“recovery”) operation and, as one example among many possible production operations, a waterflooding operation. Other operations might include other well treatments, fracturing operations, etc. Waterflooding, by way of example, is a process by which water is injected through injection wells in a field, which applies pressure to the hydrocarbons so as to move the hydrocarbons from the reservoir rock and into production wells for extraction. Parameters in various types of production operations may be controlled by physically adjusting the equipment that is being used to conduct the operations.

[0073] The method 200 may include receiving data representing a subterranean volume of interest (e.g., a reservoir), as at 202. The data, as noted above, may be collected from a variety of sources, including seismic surveys, well logs, core samples, LiDAR surveys, satellite imagery, gravity surveys, etc. The data may represent the subterranean volume in that it provides information that can be used to calculate or estimate one or more physical characteristics of the volume.

[0074] Accordingly, based on the data, a numerical, physics-based model (e.g., a reservoir model) of the subterranean volume of interest may be constructed, as at 204. For example, the reservoir model incorporates a geological model obtained from a database. The reservoir model may be configured to simulate fluid flow (or any other physical process) in the volume of interest, based on the dynamics of the fluid flow, the geology of the volume, and any other relevant factors. The model is referred to as “physics-based” because it relies on physics to yield outputs, e.g., it organizes and permits modeling of a multiphase fluid flow through calculation of equations of state, fluid dynamics, etc. Thus, the output may be calculated (e.g., deterministically) from the input parameters.

[0075] The method 200 may also include training a proxy model to predict model outputs, as at 206. The proxy model is created based on the numerical reservoir model, which has been calibrated to historical performance, and may be a surrogate for the reservoir model. Multiple realizations of the reservoir model may be employed to build and train the proxy model, for example, tens or thousands of runs. The data obtained from the numerical model is used to train the proxy model. Various different algorithms may be used in the proxy model, for example, artificial numerical network (ANN), or another type of machine learning model.

[0076] In some embodiments, the proxy model may be validated, as at 207. This may be done, for example, by analyzing the confidence levels of the outputs of the proxy model (e.g., a numerical measure provided by the model, which measures how likely the prediction is to be accurate, based on the machine learning model’s training and composition), comparing the proxy model outputs to the reservoir model outputs (e.g., model realizations not used to train the proxy model), etc. If the proxy model is validated, e.g., based upon relatively high confidence levels and relatively high correlations between proxy model outputs and reservoir model outputs, the method 200 may continue. If it is not, the method 200 may, in some embodiments, return to training the proxy model, e.g., by providing additional training data thereto.

[0077] The method 200 may further include receiving new data representing an operation in the subterranean volume of interest, as at 208. The new data may be received on a continuous basis, e.g., roughly hourly, daily, monthly, etc. It may be desirable to understand the impact the new data has on the reservoir model outputs, without having to expend the time and resources to simulate the reservoir model. Continuing with the example of waterflooding, the data may be injection rates/pressures, choke positions, production rates/pressures, changes in geological conditions, etc. For example, in the example of waterflooding, waterflood pattern balancing can be performed, e.g., executed daily by accessing daily injection and production rates. [0078] The method 200 may then include predicting the reservoir model outputs, in view of (incorporating) the new data, using the trained proxy model, as at 210. Continuing with the waterflood operation example, given the injection pressures, the trained proxy model may predict the production rate from individual production wells (or as a whole). Additionally, the proxy model may predict injection schemes that enhance production under set of constraints, such as bottom hole pressures and reservoir pressures.

[0079] The proxy model may call for shorter runtimes, as compared to a complete numerical simulation of the reservoir model, to predict conditions in the subterranean domain. For example, the proxy model generally recognizes patterns, while running the reservoir model may call for many (e.g., millions) of mathematical calculations. Thus, the proxy model can be run more frequently (e.g., daily) than the reservoir model, which may be run monthly, for example. Accordingly, the expected outputs of the reservoir model, e.g., within a calculated value for confidence (or uncertainty), can be predicted using the proxy model and without running the reservoir model. The outputs may be employed to determine performance indicators related to the operation being conducted. Specific examples of such performance indicators include conformance, voidage replacement, maps (e.g., traffic light maps), operation efficiency, curvefitting, etc.

[0080] The method 200 may include selecting an operating parameter for the operations, e.g., based on the predictions from the proxy model, as at 212. For example, the performance indicators can be displayed to users, who can, potentially without having expertise in operating the underlying reservoir model, make determinations as to operating parameter values (e.g., choke positions, injection rates, etc.). In some embodiments, the proxy model can be trained to make the operating parameter determinations and either recommend them or implement them automatically. [0081] The method 200 may also include feeding the changed operating parameters back to the proxy model, as shown by the arrow extending from box 212 back to 208. For example, the implemented operating parameter adjustments may result in different conditions in the oilfield. The reservoir model, were it to be updated at this point, may take such changes into consideration. Thus, the proxy model, to accurately predict the outputs of the reservoir model, may also consider these changed conditions created by adjusted operating parameters. The sequence described above may then proceed again, with the proxy model again providing predictions/recommendations of operating parameters (and/or implementing the operating parameters by automatically adjusting equipment in the production system).

[0082] Periodically, the reservoir model may be updated, as at 214. That is, the data collected in the field may be fed to the reservoir model, which may then update its representation of the subterranean volume and the processes that occur therein. The reservoir model may be updated less frequently than the proxy model. The updated reservoir model may then be employed to train the proxy model, as indicated by the arrow extending from box 214 to box 206. The method 200 may also include performing a wellsite action, as at 202 and 208. The wellsite action may be performed based upon the volume of interest. The wellsite action may be or include generating and/or transmitting a signal (e.g., using a computing system) that causes a physical action to occur at a wellsite. The wellsite action may also or instead include performing the physical action at the wellsite. The physical action may be or include varying a weight and/or torque on a drill bit, varying a drilling trajectory, varying a concentration and/or flow rate of a fluid pumped into a wellbore, or the like.

[0083] Figure 3 illustrates another flowchart of a method 300, according to an embodiment. The method 300 may be specific to implementations of the present disclosure to waterflooding operations, although it is emphasized that this is merely an example. The method 300 may include receiving daily injection and production data, as at 302. The method 300 may also include receiving monthly reservoir modeling outputs, as at 304, and training the proxy model using machine learning and based on the monthly reservoir modeling outputs, as at 306. Based on the daily data and the training, the proxy model may be updated, as at 308. Next, the proxy model may be employed to determine injection rates and/or other production parameters, as at 310. Further, performance indicators may be calculated and displays based thereon updated, as at 312. Additionally, changes to production indicators may be calculated (e.g., based on relationships with process/operating parameters) and implemented, as at 314, e.g., automatically or by recommendation to a user. For example, the production parameters may be changed by changing choke positions or injection rates. The method 300 may also include performing a wellsite action, as at 314. The wellsite action may be performed based upon the calculated performance indicators and update displays. The wellsite action may be or include generating and/or transmitting a signal (e.g., using a computing system) that causes a physical action to occur at a wellsite. The wellsite action may also or instead include performing the physical action at the wellsite. The physical action may be or include varying a weight and/or torque on a drill bit, varying a drilling trajectory, varying a concentration and/or flow rate of a fluid pumped into a wellbore, or the like.

[0084] Figure 4A illustrates a diagram of a system 400 for implementing a proxy model using machine learning, to control a production process, according to an embodiment. The system 400, as shown, may generally include an “agile” reservoir modeling module 402. This module 402 may be configured to generate, update, and simulate the reservoir model, and may do so more frequently than some other, conventional systems, and thus may be referred to as providing “agile” modeling. As noted above, the building and simulating of this model may be relatively computationally expensive, however, as compared to a machine learning/proxy model. The reservoir modeling module 402 may also include a domain driven model confidence module. This module may perform quality checks of the reservoir model that is generated, in order to verify that the reservoir model accurately represents the reservoir being modeled.

[0085] An Artificial Intelligence (Al) Driven On-Time Flood Tuning module 404 (“tuning module 404”) may communicate with the reservoir modeling module 402. The tuning module 404 may be configured to implement the proxy model, as discussed above. The tuning module 404 may also implement field performance and analysis decision systems as well as provide continuous automated execution.

[0086] A variety of data sources are drawn upon to feed the reservoir modeling module 402 and the tuning module 404. These different data sources may be fed into the system 400 via a data and engine services module 406. The data and engine services module 406 may communicate directly with the modules 402, 404, as shown. The data sources may be received from production injection and surveillance feeds, as shown.

[0087] The system 400 may also implement an advisor module 408. The advisor module 408 may include a dashboard, which may display various “key” performance indicators (“KPIs”). These indicators, such as conformance, voidage, map-based indicators such as traffic lights, injection efficiency curves, and pressure-production plots, may be employed to inform decisions related to production operations, e.g., parameters, such as choke position and injection rates, among others.

[0088] More particularly, the dashboard may provide a comprehensive framework for display of decisions and supporting results. The in-depth analysis ensures confidence in the workflow. Examples of decision outcomes include recommended throughput, expected reservoir pressure, recommended injection rates for individual wells, recommended production rate for individual wells, and action items and status. The dashboard also hosts a list of plots associated with waterflood surveillance. Examples of surveillance plots include 2D/3D map of simulation computed saturation, pressures and streamlines, superposition of traffic lights on the above maps to represent anomalies, (e.g., injection efficiencies of injectors falling below a threshold or water cut of a producer exceeding a certain threshold), daily tracking of production indicators (data against simulation model output), production volume against target, injection volume against target, reservoir pressure against target, cumulative water injection volume, instantaneous VRR against target, water throughput rate against target, percentage of wells within operating envelope. Further, the dashboard can permit daily tracking of operational performance indicators such as injection plant uptime against target, oil in water and TSS against target, chemical injection rates against target, average oxygen content against target,

[0089] The tuning module 404 may be considered to include a “digital avatar” or replacement/ supplement for a human, subject-matter expert or team of experts with reservoir management project experience. The module 404 may thus be a “digital” extension or addition to an operations team. With this addition, waterflood operators may have less numerical modeling and reservoir simulation expertise. Further, performance of the project with on-time connection to the reservoir model(s) may be enhanced. The module 404 may decide how the reservoir model should be utilized, based on the use-case for the operation room. In addition, the module 404 may coordinate the update and creation of new reservoir models and decision models. Once the model runs have completed the module 404 may translate the simulator output to a proxy model, also known as a decision model, that the operation room interacts with. The properties and the capabilities of the proxy model(s) may be predetermined for interaction with the operation room (e.g., fit for purpose modeling).

[0090] Figure 4B illustrates a diagram of the operation of the system 400, according to an embodiment. The system 400 may include model services 452 (e.g., part of the reservoir modeling module 402 of Figure 4A), automation and Al 454 (e.g., part of the tuning module 404 of Figure 4A), outcome operations 456, and business processes 458. The business processes 458 may be generally related to the type of operation or “phase” that is being undertaken in the environment, e.g., exploration, development, or production. In the present example, production is highlighted, although any other phase could be. Tn this case, production is highlighted because agile modeling and fast, inexpensive parameter calculations may be beneficial.

[0091] Accordingly, the model services 452 may employ a variety of possible models, including both an artificial intelligence/neural network proxy model and a reservoir model, as shown and discussed above. These two models, operating in parallel, may provide information related to the subsurface system conditions, by way of simulation, to the automation and Al 454. The automation and Al 454, executing the “digital avatar” as discussed above, may serve dual purposes. First, it may accept the data from the model services 452 and use it to produce waterflood (or any other type of system, e.g., infill planning) parameters to the physical system, in order to enhance the efficiency of on-going oilfield operations within the business process 458. The digital avatar may also track various performance indicators and other data against the measured data, thereby determining when to rebuild/retrain one of the model services 452 (e.g., based on a lowering of confidence/accuracy eventually indicating that a model is out of date).

[0092] Figure 5 illustrates a workflow 500 that may be implemented by a system (e.g., an embodiment of the system 400 discussed above), according to an embodiment. The workflow 500 may begin by receiving inputs 502, e.g., from a surveillance system 504 that collects and/or stores data, e.g., from a field. Such data may include historical production rates, injection rates, average bottom flowing pressure for oil wells (pwf), well petrophysical data, and layer (geological or lithological) information. The inputs 502 may be fed to an Al training module 508, which may be part of the tuning module 404 discussed above with reference to Figure 4A. These inputs represent data collected from a subterranean volume.

[0093] The Al training module 508 may also receive reservoir simulation modeling of the subterranean system, as indicated at 512. Such modeling may be the output of physics-based models, which may be constructed and simulated based on the inputs 502. The Al training module 508 may thus update a proxy model 514 that represents the subterranean volume. As a result, when new inputs 502 are acquired, the proxy model can be updated by training and/or used to predict outputs 516 of the physics-based model, e.g., without simulating the physics-based model. As shown, by way of example, such outputs may include new inj ection rates and/or new production rates, based on the new inputs 502.

[0094] Figure 6 illustrates another diagrammatic view of the system 400, according to an embodiment. The decision model 600 may be contained in the tuning module 404, e g., functioning as the proxy model that is trained using a reservoir model 606 (contained in the module 402) to make determinations/recommendations for parameter values based on production data (input, as received from the tuning module 404). The agile reservoir modeling module 402 (also shown in Figure 4A), may communicate with the reservoir model 606, and includes functionality to automatically build the static model and the dynamic model, and to calibrate the model 606 with historical pressure-production data. The reservoir model 606 may also be analyzed to determine the confidence factor at various regions in the reservoir model 606. The reservoir model 606 may have multiple realizations.

[0095] In addition, the tuning module 404 includes an analyzer 602. The analyzer 602 may also be part of the tuning module 404, and may convert well allocation factors (WAFs) and pattern flood management (PFM) into recommended actions, which may be visualized in the surveillance dashboard module 408, potentially along with other metrics and/or performance indicators. These performance indicators may be monitored and/or acted upon by an operations team of human users and/or employed to tune operating parameters of automated systems, e.g., based on receipt of product! on/inj ection data 608 (e.g., the data and engine service module 406 of Figure 4A and/or the inputs 502 of Figure 5) from the field.

[0096] Figure 7 illustrates a diagrammatic view of a workflow 700 for controlling parameters in a subsurface injection or production operation, e.g., using a proxy or “decision” model along with a physics-based reservoir model, according to an embodiment. The workflow 700 includes an implementation of the tuning module 404, as discussed above with reference, e.g., to Figure 4A, which includes the proxy model.

[0097] The workflow 700 may include evaluating an integrity of the reservoir model 702. For example, the reservoir model may be employed to determine various outputs 704, such as property distribution integrity, aquifer representations, well perforation plots, modeling integrity, forecasting power, and any other metrics or parameters. The reservoir model may be reviewed for integrity, e.g., based on these factors. The evaluation of the reservoir may permit a determination of a confidence level for the model. For example, the model may be deemed fully reliable 706, partially representative 708 (e.g., in certain areas or for certain aspects, but not others), or unreliable 710, and thus rebuilt.

[0098] Once the reservoir model is validated for integrity, the workflow 700 may then include providing an Al-driven on-time injection/production “optimization” (e.g., enhancement, increase in accuracy/ efficiency, etc.) 712 based on the reservoir model. For example, the workflow 700 may include providing a field performance analysis and decision system 714, which may review field performance data and make or suggest reservoir investigation decisions. The optimization 712 may also provide for continuous automated execution 716, which may prepare simulation instructions for new reservoir models (e.g., adjust parameters thereof). The optimization 712 may also provide automated proxy from simulation models, as at 718, which may convert model outputs for use in the operation room, and, e.g., into instructions for parameter adjustment of equipment in the field.

[0099] Embodiments of the present disclosure may provide a system for reservoir management, e.g., under waterflood. Confidence that the correct field operational actions are being carried out to increase the efficiency of the operations (e.g., waterflooding), efficient use of resources and production objectives for the field development. Further, the system may provide for surveillance, diagnostics and operational control of ongoing waterflood operations. Work of field development planning (e.g., waterflood design, infill well planning) is not connected to operational data and out of date. The system may also address issues with model building and selecting the right model for decisions, which can be slow and manual by providing an automated, machine-learning process.

[0100] Embodiments of the present disclosure may provide representative models that preserve uncertainties in areas of lower confidence. Further, the reservoir models are “living” in that they are configured to be updated regularly. On-time adjustment may also be provided based on the decision or “proxy” model, which can complete evaluations in tens of seconds rather than hours or more.

[0101] In some embodiments, the methods of the present disclosure may be executed by a computing system. Figure 8 illustrates an example of such a computing system 800, in accordance with some embodiments. The computing system 800 may include a computer or computer system 801A, which may be an individual computer system 801A or an arrangement of distributed computer systems. The computer system 801A includes one or more analysis modules 802 that are configured to perform various tasks according to some embodiments, such as one or more methods disclosed herein. To perform these various tasks, the analysis module 802 executes independently, or in coordination with, one or more processors 804, which is (or are) connected to one or more storage media 806. The processor(s) 804 is (or are) also connected to a network interface 807 to allow the computer system 801 A to communicate over a data network 809 with

15 one or more additional computer systems and/or computing systems, such as 801B, 801C, and/or 80 ID (note that computer systems 80 IB, 801C and/or 80 ID may or may not share the same architecture as computer system 801A, and may be located in different physical locations, e.g., computer systems 801 A and 801B may be located in a processing facility, while in communication with one or more computer systems such as 801 C and/or 80 ID that are located in one or more data centers, and/or located in varying countries on different continents).

[0102] A processor may include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array, or another control or computing device.

[0103] The storage media 806 may be implemented as one or more computer-readable or machine-readable storage media. Note that while in the example embodiment of Figure 8 storage media 806 is depicted as within computer system 801A, in some embodiments, storage media 806 may be distributed within and/or across multiple internal and/or external enclosures of computing system 801 A and/or additional computing systems. Storage media 806 may include one or more different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories, magnetic disks such as fixed, floppy and removable disks, other magnetic media including tape, optical media such as compact disks (CDs) or digital video disks (DVDs), BLURAY® disks, or other types of optical storage, or other types of storage devices. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or may be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture may refer to any manufactured single component or multiple components. The storage medium or media may be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions may be downloaded over a network for execution.

[0104] In some embodiments, computing system 800 contains one or more data avatar module(s) 808. In the example of computing system 800, computer system 801 A includes the data avatar module 808. In some embodiments, a single data avatar estimation module may be used to perform some aspects of one or more embodiments of the methods disclosed herein. Tn other embodiments, a plurality of data avatar modules may be used to perform some aspects of methods herein.

[0105] It should be appreciated that computing system 800 is merely one example of a computing system, and that computing system 800 may have more or fewer components than shown, may combine additional components not depicted in the example embodiment of Figure 8, and/or computing system 800 may have a different configuration or arrangement of the components depicted in Figure 8. The various components shown in Figure 8 may be implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing and/or application specific integrated circuits.

[0106] Further, the steps in the processing methods described herein may be implemented by running one or more functional modules in information processing apparatus such as general purpose processors or application specific chips, such as ASICs, FPGAs, PLDs, or other appropriate devices. These modules, combinations of these modules, and/or their combination with general hardware are included within the scope of the present disclosure.

[0107] Computational interpretations, geological interpretations, models, and/or other interpretation aids may be refined in an iterative fashion; this concept is applicable to the methods discussed herein. This may include use of feedback loops executed on an algorithmic basis, such as at a computing device (e.g., computing system 800, Figure 8), and/or through manual control by a user who may make determinations regarding whether a given step, action, template, model, or set of curves has become sufficiently accurate for the evaluation of the subsurface three- dimensional geologic formation under consideration.

[0108] Assessment of a potential CO2 storage capacity of a subsurface storage site (or subsurface structure) is a key workflow in assessing a site’s suitability for CO2 storage. To do this the site must be assessed in terms of accessible pore volume (its capacity). The capacity is the amount of CO2 that can be safely stored. Further, the site must be assessed for injectivity, or the ease with which CO2 can be safely injected. Containment, or the ability to store CO2 safely and permanently, is also assessed. The potential for long term migration within the subsurface structure and trapping mechanisms are containment and integrity factors. Other assessment factors include, but are not limited to including, environment, infrastructure, regulation, public opinion, and finances. Figure 9 graphically depicts these considerations. [0109] Factors that may be reviewed for a given structure’s suitability and how to operate with it for CO2 storage purposes can include, but are not limited to including, temperature, hydraulic considerations, mechanical and geomechanical considerations, and chemical and geochemical interactions and issues. Specifically, pressure changes from dynamic reservoir simulations to anticipate stress changes and possible instabilities within the reservoir, the wells, and the surroundings, for example, top seal and faults, are considered. Deformation induced during injection and CO2 plume evolution are evaluated, and the possible impact on wells, host rock, cap rock, faults, and ground surface, for example, subsidence and uplift, is quantified. Injection in depleted reservoirs can ensure that operations are conducted within the elastic domain of the reservoir rock. Elastic domain can be trespassed for caprock and faults, and stability analysis can predict CO2 leakage risks. A somewhat analogous situation involves underground gas storage, except that for underground gas storage, there are typically no cycles of injection and production, and rock/fluid (CO2 ) interaction, for example, geochemistry, modeling is involved. Temperature, hydraulic, mechanical, and chemical coupling could be required. Figure 10 graphically depicts some of the key challenges in modeling CCS storage complexes.

[0110] Figure 11, CCS Studies and Coupling, depicts aspects of how dynamic processes and effective stress changes related to the temperature, hydraulics, mechanical, and chemical considerations underpin the importance of integrating reservoir flow and geomechanical solvers to understand CO2 injection multiphysics (also referred to as multidomain physics or multiple physics domains). Multiphysical processes are dynamic and strongly interdependent.

[0111] To do CCS effectively, subsurface engineers need to build models to evaluate the subsurface behaviour. And these models generally are very complicated and must take into account many types of information, as discussed above, and further elaborated on herein.

[0112] Accordingly, one aspect of the disclosure is the automated building of integrated model(s) that combine reservoir simulator capabilities, such as those found in Schlumberger’s INTERSECT® simulator, and leading geomechanical simulations, such as Schlumberger’s VISAGE® simulator system.

[0113] Using this integrated system, it is now possible to build multiphysics integrated models for CO2 CCS operations, such as injection, capacity, and containment and integrity analysis. Among the factors, data, and considerations that go into building multiphysics integrated models, are in the following non-comprehensive, non-limiting list: Thermal wellbore

• Integrated geomechanics

• Compositional reservoir simulation

• CO2 Phase Behaviour modeling of pressure, volume, temperature (PVT)

• Temperature dependent solubility of CO2 in aqueous phases (reservoir brines)

• Multi-contact miscibility of CChwith depleted hydrocarbon fluids

• Geochemical modeling of chemical reactions between CO2 in aqueous phase and reservoir fluids

[0114] Significantly, the integrated system enables the automated construction of multiple models or ensembles of models that honor the observed data, and in some embodiments, concurrently use cloud high performance computing (HPC) and data management enablers during the automated model construction, which can then be simulated using an integrated simulator of the INTERSECT® reservoir simulator calling the VISAGE® simulator dynamically in memory.

[0115] A further aspect of the disclosure is a set of three digitally accelerated CCS Subsurface workflows for injectivity, capacity, and integrity and containment risks. Significantly, these workflows are designed to address inherent uncertainty in data representing subsurface structures.

• System to automatically assess subsurface injectivity potential and risk for CO2 injection in subsurface formations under uncertainty in reservoir characterization.

• System to automatically assess subsurface reservoir storage capacity for CO2 storage (volumes over time) under uncertainty in reservoir characterization.

• System to automatically assess subsurface storage complex integrity and containment risks under uncertainty in reservoir characterization.

[0116] The three workflows are based on a common pattern where we use an integrated flow and geomechanical subsurface model “the model” on which experiments are performed (experimental design) to quantify the movement of fluids and mechanical effects within the subsurface, under the presence of uncertainty.

[0117] Another aspect of the disclosure is an automated quantification and recommendation system to perform studies that result in specific types of advice for CO2 services. Table 1 depicts the broad inputs and outputs for three CCS workflows related to CO2 services. These workflows apply Al techniques to sample the parameter space to create an assessment of the uncertainty in the outcome of the study being performed. This involves sampling both the subsurface uncertainties (column 2) alongside the design parameters (column 3) to create outputs (column 4) for the study type (column 1).

Table 1. CCS/CO2 study types [0118] Figure 12 is an example of one visual aspect of a study, namely, a fault integrity analysis workflow in accordance with one embodiment of the workflows disclosed herein. Following Figure 12’ s example for a study involving fault properties in the context of containment and integrity, a simulation experiment is designed with artificial intelligence, machine learning, intelligent sampling, and/or optimization (which in some embodiments means improving, rather than optimization to the fullest extent possible of all factors) based on the Containment and Integrity study type of Table 1. The simulation results would be used to determine an appropriate advisory regarding containment and integrity risks based on fault properties in col. 1 that bear on subsurface uncertainty, and the design parameters in col. 2, to come up with the specific advice to maintain integrity of, and contain the CO2 within, in a subsurface structure. Specifically, subsurface modeling for CO2 storage evaluation can include, but is not limited to including, capacity and injectivity management and containment risk management, as well as the uncertainties involved in the model. Capacity and injectivity management includes, but is not limited to including, a model to estimate storage capacity, the sizing of capture and transport facilities, and the identification of the injectivity potential. Containment risk management includes, but is not limited to including, ensuring storage integrity, preventing CO2 leakage, managing risk of induced seismicity, and gathering data to support risk assessment to comply with regulations. Uncertainties include, but are not limited to including, limited data availability in CCUS sites, the high level of uncertainties to be considered, and uncertainty associated with operational decisions.

[0119] Turning to practical matters for implementation, Agile Reservoir Modeling (ARM), which is described at length herein, helps support execution of the three example CCS workflows disclosed herein. While ARM systems are discussed elsewhere in this application, Figure 13 provides an overview of ARM, and Figure 14 shows one possible implementing application of ARM in the context of the CCS workflows discussed herein. ARM is a framework to rapidly evaluate multiple field development options under subsurface uncertainty such as, for example, but not limited to, automated concurrent generation of ensembles, automated analytics and insights, and close integration with the field development plan.

[0120] ARM is powered by automated ensemble generation, elastic cloud HPC, and a model data management system (DMS) for rapid model processing acceleration. All of this used to generate CCS insights, such as those study types for injectivity, capacity, and integrity and containment risks discussed in Table 1.

[0121] ARM may be used in coordination with the embodiments in accordance with the present disclosure, such as the study types for injectivity, capacity, and integrity and containment risks discussed in Table 1. Those with skill in the art will appreciate that the foregoing discussion of ARM and related systems in the text directed to Figures 2 - 7 may be used to implement aspects of the CCS workflows, including the methods below listed as 8000, 9000, 10000, and 11000. Those with skill in the art will also appreciate that the discussion of ARM and related systems, including the text directed to Figures 16 - 22A, 22B, and 22C may be used to implement aspects of the CCS workflows, including the methods below listed as 8000, 9000, 10000, and 11000.

[0122] Conceptually, the workflow implementation of CCS study types for injectivity, capacity, and integrity and containment risks discussed in Table 1 can be understood by those with skill in the art by reviewing Figure 15, which shows how coupled flow and geomechanical reservoir models may be used to evaluate injectivity, capacity and integrity for CCS injection under uncertainty.

[0123] As those with skill in the art will appreciate, users of the disclosures herein, such as the CCS workflows disclosed herein, may rapidly assess, quantify, and de-risk subsurface uncertainty to facilitate planning and CCS project approvals. Given automated CCS assessments via concurrent scenario evaluation facilitated using fast cloud HPC, and automated data analytics founded on cloud data management systems, users will accomplish these tasks faster and more accurately before.

[0124] The CCS workflows discussed herein may also facilitate CCS simulation over long timescales, e.g., 20 - 40 years injection and hundreds of years of post-injection modeling to understand migration potential and containment.

[0125] Those with skill in the art will also appreciate that injectivity optimization may be used for automated planning purposes, such as determining how much can a well safely inject CO2; how to automate capacity assessments of subsurface structures; how to automate risk assessment for caprock integrity seal breakage, fault reactivation and wellbore integrity issues, which would potentially postpone, stop or in some cases be catastrophic to the operation. Moreover, those with skill in the art will also appreciate that the workflows disclosed herein may be adapted to model CCS-related storage situations through the use of enhanced oil recovery or enhanced gas recovery techniques.

[0126] Methods 8000, 9000, 10000, and 11000, referred to herein, include numeric references for identification purposes only. There are no specific corresponding figures for methods 8000, 9000, 10000, and 11000.

[0127] In accordance with some embodiments, a method 8000, a computer program product configured to perform the method 8000, or a computing-assisted system including at least one computer system configured to perform the method 8000, includes automated building of one or more integrated subsurface models, wherein the building is based at least in part on multiphysics, including a plurality of data selected from one or more of the following observed data types: thermal wellbore data, CO2 phase behaviour modeling (PVT) data, temperature dependent solubility of CO2 in aqueous phases (e.g., reservoir brines) data, multi-contact miscibility data of CO2 with depleted hydrocarbon fluids, and geochemical modeling data representing chemical reactions between CO2 in aqueous phase and reservoir fluids; and wherein the automated building is based at least in part on: integrated geomechanics data, and compositional reservoir simulation results.

[0128] In some embodiments of method 8000, the automated building honors the plurality of data selected from the observed data types.

[0129] In some embodiments of method 8000, the automated building is performed on a cloudbased high-performance computing system.

[0130] In some embodiments of method 8000, the automated building includes geomechanics simulation.

[0131] In some embodiments of method 8000, the automated building includes subsurface reservoir simulation.

[0132] In some embodiments of method 8000, the one or more integrated subsurface models are configured for CO2 modeling in a subsurface structure.

[0133] In some embodiments of method 8000, the CO2 modeling is selected from the group consisting of CO2 injectivity modeling, CO2 capacity modeling, and CO2 containment modeling. [0134] In some embodiments of method 8000, the subsurface structure is a saline aquifer.

[0135] In some embodiments of method 8000, the subsurface structure is a depleted oil or gas reservoir. [0136] In some embodiments of method 8000, the one or more integrated subsurface models is an ensemble of integrated subsurface models.

[0137] In some embodiments of method 8000, the ensemble captures a range of uncertainties of one or more of the observed data types.

[0138] In some embodiments of method 8000, the method further comprises performing a simulation experiment for CO2 injectivity modeling based at least in part on the one or more integrated subsurface models. Those with skill in the art will appreciate that the embodiments of method 9000 may be used in this embodiment of method 8000 to perform the simulation experiment.

[0139] In some embodiments of method 8000, the method further comprises performing a simulation experiment for CO2 capacity modeling based at least in part on the one or more integrated subsurface models. Those with skill in the art will appreciate that the embodiments of method 10000 may be used in this embodiment of method 8000 to perform the simulation experiment.

[0140] In some embodiments of method 8000, the method further comprises performing a simulation experiment for CO2 containment modeling based at least in part on the one or more integrated subsurface models. Those with skill in the art will appreciate that the embodiments of method 11000 may be used in this embodiment of method 8000 to perform the simulation experiment.

[0141] In accordance with some embodiments, a method 9000, a computer program product configured to perform the method 9000, or a computing-assisted system including at least one computer system configured to perform the method 9000, includes performing a CO2 injection study by designing a simulation experiment for CO2 injection operations into a subsurface structure, wherein the simulation experiment is based at least in part on: one or more parameters selected from the group consisting of well injection rates, well injection pressures, well injection temperatures, and CO2 fluid stream composition; one or more subsurface uncertainty criteria selected from the group consisting of reservoir properties, reservoir structure, reservoir formation fluids, and stress field data; and one or more integrated subsurface models configured for CO2 modeling in the subsurface structure; and running the simulation experiment one or more times to determine an advisory action selected from the group consisting of a risk assessment for a plurality of injection scenarios, a safe injection rate for operation, using enhanced oil recovery schemes as applied to injectivity, using enhanced gas recovery schemes as applied to injectivity, and a well count to achieve a specified CO2 injection volume.

[0142] In some embodiments of method 9000, the method further comprises preparing a CO2 injection procedure for execution at a CO2 injection site, wherein the execution procedure is based at least in part on the advisory action.

[0143] In some embodiments of method 9000, the simulation experiment is based at least in part on intelligent sampling of the one or more parameters and one or more subsurface uncertainty criteria.

[0144] In some embodiments of method 9000, the simulation experiment is based at least in part on machine learning with the one or more parameters and one or more subsurface uncertainty criteria.

[0145] In some embodiments of method 9000, the method further comprises performing an action for CO2 storage at a CCS operations site based at least in part on the advisory action.

[0146] Those with skill in the art will recognize that some embodiments of method 9000 include where the one or more integrated subsurface models are prepared in accordance with various embodiments of method 8000.

[0147] In accordance with some embodiments, a method 10000, a computer program product configured to perform the method 10000, or a computing-assisted system including at least one computer system configured to perform the method 10000, includes performing a CO2 capacity study by designing a simulation experiment for CO2 capacity determination for a subsurface structure, wherein the simulation experiment is based at least in part on: one or more parameters selected from the group consisting of well injection rates, well injection pressures, well injection temperatures, CO2 fluid stream composition, well locations, and wellbore architectures; one or more subsurface uncertainty criteria selected from the group consisting of reservoir properties, reservoir structure, reservoir formation fluids, and stress field data; and one or more integrated subsurface models configured for CO2 modeling in the subsurface structure; and running the simulation experiment one or more times to determine an advisory action selected from the group consisting of capacity profile distributions, CO2 migration probability distributions, and well location recommendations. [0148] In some embodiments of method 10000, the method further comprises preparing a CO2 capacity report for use in determining a CO2 storage recommendation for the subsurface structure based at least in part on the advisory action.

[0149] In some embodiments of method 10000, the simulation experiment is based at least in part on intelligent sampling of the one or more parameters and one or more subsurface uncertainty criteria.

[0150] In some embodiments of method 10000, the simulation experiment is based at least in part on machine learning with the one or more parameters and one or more subsurface uncertainty criteria.

[0151] In some embodiments of method 10000, the method further comprises performing an action for CO2 storage at a CCS operations site based at least in part on the advisory action.

[0152] Those with skill in the art will recognize that some embodiments of method 10000 include where the one or more integrated subsurface models are prepared in accordance with various embodiments of method 8000.

[0153] In accordance with some embodiments, a method 11000, a computer program product configured to perform the method 11000, or a computing-assisted system including at least one computer system configured to perform the method 11000, for performing a CO2 containment and integrity study includes designing a simulation experiment for CO2 containment and integrity determination for a subsurface structure, wherein the simulation experiment is based at least in part on: one or more parameters selected from the group consisting of well injection rates, well injection pressures, well injection temperatures, CO2 fluid stream composition, and wellbore properties; one or more subsurface uncertainty criteria selected from the group consisting of reservoir properties, reservoir structure, reservoir formation fluids, stress field data, and fault properties; and one or more integrated subsurface models configured for CO2 modeling in the subsurface structure; and running the simulation experiment one or more times to determine an advisory action selected from the group consisting of subsurface structure integrity insights for CO2 containment, safe reservoir pressure, caprock integrity seal breakage, fault reactivation, wellbore integrity issues, and subsurface structure integrity risks.

[0154] In some embodiments of method 11000, the method further comprises preparing a CO2 containment and integrity report for use in determining a CO2 storage recommendation for the subsurface structure based at least in part on the advisory action. [0155] In some embodiments of method 1 1000, the simulation experiment is based at least in part on intelligent sampling of the one or more parameters and one or more subsurface uncertainty criteria.

[0156] In some embodiments of method 11000, the simulation experiment is based at least in part on machine learning with the one or more parameters and one or more subsurface uncertainty criteria.

[0157] In some embodiments of method 11000, the method further comprises performing an action for CO2 storage at a CCS operations site based at least in part on the advisory action.

[0158] Those with skill in the art will recognize that some embodiments of method 11000 include where the one or more integrated subsurface models are prepared in accordance with various embodiments of method 8000.

[0159] A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. One general aspect includes a computing system for controlling parameters in a subsurface operation, for example, but not limited to, an oilfield or gas field. The computing system also includes receiving volume data representing a volume of interest, where the volume of interest includes a subterranean volume of interest or a reservoir, where the volume data includes, but is not limited to including, seismic surveys, well logs, core samples, lidar surveys, satellite imagery, interferometric synthetic aperture radar (InSAR)), or gravity surveys, where the volume data are used to calculate or estimate physical characteristics of the volume of interest. The system also includes constructing a numerical model based at least on the physical characteristics, where the numerical model is based at least on physics, where numerical model output from the numerical model is, in some configurations, deterministic based on numerical model input to the numerical model, where the numerical model is, in some configurations, a reservoir model, where the numerical model is, in some configurations, a geological model, where the numerical model is, in some configurations, a geomechanical model, where the numerical model simulates fluid flow or other physical process, for example, but not limited to thermal, hydraulic, mechanical, and/or chemical processes in the volume of interest, where the numerical model is, in some configurations, based on dynamics of the fluid flow, where the numerical model is, in some configurations, based on geomechanics of the volume of interest, where the numerical model is, in some configurations, based on geology of the volume of interest. The system also includes training a proxy model to predict the numerical model output for a subterranean volume, where the proxy model is, in some configurations, based on the numerical model and is calibrated to historical performance, for example, but not limited to, production data, and measurements for example, but not limited to, laboratory data, stress tests, etc., where, in some configurations, multiple executions of the numerical model produce the numerical model output data that are used to train the proxy model, where the proxy model is, in some configurations, an artificial neural network, where the proxy model is, in some configurations, a machine learning model. The system also includes validating the proxy model, where the validating includes: executing the proxy model to produce proxy model output data, analyzing confidence levels of the proxy model output data, continually training the proxy model if the confidence levels in the proxy model output data do not meet a first pre-selected threshold or if correlations between the proxy model output data and the numerical model output data do not meet a second pre-selected threshold. The system also includes receiving subsurface operation data representing the subsurface operation, where the subsurface operation includes, for example, but not limited to, a production operation, a recovery operation, a waterflooding operation, a well treatment, a fracturing operation, a gas storage operation, where the subsurface operation is performed, at least partially, in the subterranean volume of interest, where the subsurface operation data are, in some configurations, collected continuously, where the subsurface operation data are, in some configurations, collected hourly, where the subsurface operation data are, in some configurations, collected daily, where the subsurface operation data are, in some configurations, collected monthly, where the subsurface operation data include, for example, but not limited to, injection rates/pressures, choke positions, production rates/pressures, or changes in geological conditions, where receiving the subsurface operation data includes, but is not limited to, performing waterflood pattern balancing daily by accessing daily injection and production rates. The system also includes predicting the numerical model output data by providing subsurface operation data to the proxy model creating the predicted proxy model output data, where the predicted proxy model output data includes one or more predicted performance indicator, where predicting the numerical model output data includes, in some configurations, predicting a production or injection rate from individual wells or a group of wells during a subsurface operation, based at least on the injection pressure, where predicting the numerical model output data includes, in some configurations, predicting injection schemes that enhance production or storage under pre-selected constraints, where the pre-selected constraints include, but are not limited to including, bottom hole pressure and reservoir pressure. The system also includes evaluating performance based at least upon the one or more predicted performance indicator, where the one or more predicted performance indicator includes, but is not limited to including, conformance, voidage replacement, maps, operation efficiency, or curvefitting. The system also includes selecting an operating parameter that, based on the one or more predicted performance indicator, needs modification, where the one or more predicted performance indicator is provided to a user, where the user modifies the operating parameter based on the one or more predicted performance indicator, where the operating parameter includes, for example, but not limited to, choke position or injection rates, where the proxy model is trained to evaluate the operating parameter with respect to the one or more predicted performance indicator and recommend modifications to the operating parameter, or automatically implement the modifications. The system also includes feeding the modifications to the proxy model. The system also includes updating the numerical model periodically, where the updating includes, but is not limited to including, feeding field data collected during an operation to the numerical model, updating a representation of the subterranean volume in the numerical model, executing the numerical model to produce the numerical model output data, and training the proxy model with the numerical model output data. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0160] One general aspect includes a computing system for controlling parameters in a subsurface operation by understanding an impact of introducing new data to a numerical model of the subsurface operation without having to simulate the numerical model. The computing system also includes one or more processors. The system also includes a memory storing instructions that, when executed by at least one of the one or more processors, cause the computing system to perform operations for predicting one or more performance indicator and updating the numerical model, the operations may include, but are not limited to including, receiving volume data representing a volume of interest; constructing the numerical model based at least on physical characteristics of the volume of interest; training a proxy model to predict numerical model output data for the volume of interest; receiving subsurface operation data representing the subsurface operation; predicting the numerical model output data by providing subsurface operation data to the proxy model creating predicted proxy model output data; determining the one or more performance indicators based on the predicted proxy model output data; selecting an operating parameter that, based on the one or more predicted performance indicator, needs modification; and updating the numerical model periodically based on data associated with the subsurface operation and the predicted proxy model output data. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0161] Implementations may include one or more of the following features. The computing system as may include: where the volume of interest includes, in some configurations, a subterranean volume of interest or a reservoir, where the volume data includes, for example, but not limited to, seismic surveys, well logs, core samples, lidar surveys, satellite imagery, InSAR, or gravity surveys, and where the volume data are used to calculate or estimate physical characteristics of the volume of interest. The numerical model is based at least on physics, and where numerical model output from the numerical model is deterministic based on numerical model input to the numerical model, where the numerical model is, in some configurations, a reservoir model, or, in some configurations, a geological model, or, in some configurations, a geomechanical model, or, in some configurations, a combination of models, and where the numerical model simulates, in some configurations, fluid flow or, in some configurations, thermal, hydraulic, mechanical, chemical processes in the volume of interest, or both, and where the numerical model is based, in some configurations, on dynamics of the fluid flow, or, in some configurations, geomechanics of the volume of interest, or, in some configurations, geology of the volume of interest, or based on all of the above or other factors. The proxy model is, in some configurations, based on the numerical model and is calibrated to historical performance of production data, and measurements of laboratory data or stress tests, where, in some configurations, multiple executions of the numerical model produce the numerical model output data that are used to train the proxy model, and where the proxy model is, in some configurations, an artificial neural network, or where the proxy model is, in some configurations, a machine learning model. The operations further may include, but are not limited to including, validating the proxy model, where the validating includes: executing the proxy model to produce proxy model output data; analyzing confidence levels of the proxy model output data; and continually training the proxy model if the confidence levels in the proxy model output data do not meet a first preselected threshold or if correlations between the proxy model output data and the numerical model output data do not meet a second pre-selected threshold. The subsurface operation includes, but is not limited to including, a production operation, a recovery operation, a waterflooding operation, a well treatment, a fracturing operation, a gas storage operation, or other operation, where the subsurface operation is performed, at least partially, in the volume of interest, where the subsurface operation data are collected, for example, but not limited to, continuously, or hourly, or daily, or monthly, where the subsurface operation data include, but are not limited to including, injection rates/pressures, choke positions, production rates/pressures, or changes in geological conditions, and where receiving the subsurface operation data includes, but is not limited to including, performing waterflood pattern balancing daily by accessing daily injection and production rates. The predicted proxy model output data includes one or more predicted performance indicator, where predicting the numerical model output data includes, but is not limited to including, predicting, in some configurations, a production or injection rate from individual wells or a group of wells during the subsurface operation, based at least on an injection pressure, or predicting, in some configurations, injection schemes that enhance production or storage under pre-selected constraints, and where the pre-selected constraints include, but are not limited to including, bottom hole pressure and reservoir pressure. The one or more predicted performance indicator includes, but is not limited to including, conformance, voidage replacement, maps, operation efficiency, or curvefitting. The updating includes, but is not limited to including, feeding field data collected during an operation to the numerical model, updating a representation of the volume of interest in the numerical model, executing the numerical model to produce the numerical model output data, and training the proxy model with the numerical model output data. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

[0162] One general aspect includes a computing system for controlling parameters in a subsurface operation by understanding an impact of introducing new data to a numerical model of the subsurface operation without having to simulate the numerical model. The computing system also includes one or more processors. The system also includes a memory storing instructions that, when executed by at least one of the one or more processors, cause the computing system to perform operations for predicting one or more performance indicators and updating the numerical model, the operations may include, but are not limited to including, receiving volume data representing a volume of interest, constructing the numerical model based at least on physical characteristics of the volume of interest, training a proxy model to predict numerical model output data for the volume of interest, receiving subsurface operation data representing the subsurface operation, predicting the numerical model output data by providing subsurface operation data to the proxy model creating predicted proxy model output data, and updating the numerical model periodically based on data associated with the subsurface operation and the predicted proxy model output data. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0163] Implementations may include one or more of the following features. The computing system may include, but is not limited to including, determining the one or more performance indicators based on the predicted proxy model output data; and selecting an operating parameter that, based on the one or more predicted performance indicator, needs modification. The volume of interest includes, but is not limited to including, a subterranean volume of interest or a reservoir, where the volume data includes, but is not limited to including, seismic surveys, well logs, core samples, lidar surveys, satellite imagery, InSAR, or gravity surveys, and where the volume data are used to calculate or estimate physical characteristics of the volume of interest. Numerical model output from the numerical model is deterministic based on, but is not limited to being based on, numerical model input to the numerical model, dynamics of fluid flow, geomechanics and geology of the volume of interest. The proxy model is based on multiple executions of the numerical model that produce the numerical model output data that are used to train the proxy model, and where the proxy model is, in some configurations, an artificial neural network, or where the proxy model is, in some configurations, a machine learning model, or other type of network or model. The operations further may include, but are not limited to including, validating the proxy model, where the validating includes, but is not limited to including, executing the proxy model to produce proxy model output data; analyzing confidence levels of the proxy model output data; and continually training the proxy model if the confidence levels in the proxy model output data do not meet a first pre-selected threshold or if correlations between the proxy model output data and the numerical model output data do not meet a second pre-selected threshold The subsurface operation includes, but is not limited to including, a production operation, a recovery operation, a waterflooding operation, a well treatment, a fracturing operation, a gas storage operation, or other type of operation or combination of operations, where the subsurface operation is performed, at least partially, in the volume of interest, where the subsurface operation data are collected, for example, but not limited to, continuously, or hourly, or daily, or monthly, where the subsurface operation data include, but are not limited to including, injection rates/pressures, choke positions, production rates/pressures, or changes in geological conditions, and where receiving the subsurface operation data includes, but is not limited to including, performing waterflood pattern balancing daily by accessing daily injection and production rates. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

[0164] Figure 16 illustrates a flowchart of a method 411 for field development, e.g., field development planning, according to an embodiment. The worksteps of the method 411 may be conducted in the order presented herein or in any other. Moreover, individual worksteps may be partitioned into two or more worksteps, conducted at least partially in parallel, or combined, without departing from the scope of the present disclosure.

[0165] The method 411 may include, for example, receiving data (e.g., measurements) representing a subterranean volume, e.g., an oilfield, basin, reservoir, etc., as at 401. The data may be employed to generate a multi-domain model that digitally represents one or more features of the subterranean volume, as at 403. In addition, the multi-domain model may represent other aspects/domains of the subterranean volume, such as economic measures of hydrocarbon production from the subterranean volume, e.g., costs and/or price models associated therewith. Each of these models may carry uncertainty, and each may be run in a stochastic, probabilistic, or other type of model that accounts for uncertainty, e.g., by generating multiple outcomes or “realizations” of the model. In some embodiments, such realizations can be generated by simulating one or more processes in the model.

[0166] The output of the model simulation may be one or more physical parameters or characteristics of the subterranean volume (and/or an economic aspect thereof). Values for the physical parameters may have a range of uncertainty, and a probability distribution within that range. Moreover, the values for the physical parameters may be binary or otherwise non-linear, e g., one characteristic might be the presence or non-presence of a feature (e g., a fault) at a particular location. A series of realizations may be generated in which the fault is in the location, and another series generated in which the fault is not present at that location, but potentially present at a different location. Each of these realizations may have a different probability, which may be at least partially dependent upon the probability of the fault being at the given location.

[0167] Another example of uncertainty that may be propagated through may be for flow simulation the subsurface volume, which may be discretized into a grid. The discretization can be driven by the features or feature position, size, orientation etc. and how these features interact with each other. Accordingly, in some embodiments, a “binary” feature could be choice between competing grids that host the flow simulation (or geomechanics evaluation or combination). As a result some realizations use grid A, some B, some C.

[0168] Accordingly, the multi-domain model of the subterranean domain may establish an “ensemble” of realizations, which may include complex elements representing the different permutations of realizations of the multiple underlying models that are used to generate the multidomain model. Thus, rather than, for example, passing a few representative realizations (e.g., a worst case, best case, and medium case) from a geological model of hydrocarbon recovery to a commercial model, the present method 411 may permit the entire ensemble of the realizations to be built upon in successive models, e.g., successively adding to the complexity (e.g., dimensionality) of individual elements of the ensemble. Further, in at least some embodiments, processes in successive modeling domains may be able to select, e.g., based on statistical or other analyses, realizations from the predecessor models, rather than the predecessor domain providing the realizations to the successive domain.

[0169] The method 411 may then include sampling realizations of the multi-domain model, as at 406. In other words, elements of the ensemble may be accessed by a field development engine. This may again be a statistical sampling, in that it is not done at random, but using some analysis (in some embodiments, including machine learning) of the ensemble from which to select elements (i.e., realizations of the multi-domain model). Such sampling measures may be configured to identify areas of the uncertainty space where additional realizations should be selected, where outliers are present that may call for additional investigation (or may be ignored), where too many realizations have been selected for simulation, or where too few have been selected. Other examples for sampling include using k-means clustering and probability bands, among any number of other possibilities. [0170] In some embodiments, the goal may be to select, for the complex simulation conducted by the field development engine, a few realizations that the field development engine considers to be suited for simulation, rather than relying on the individual domain model simulations to provide to the field development engine which realizations to use. Moreover, the same concept may be true on the model-to-model level, as noted above and as will be discussed in greater detail below, in which the subsequent models may selected from realizations provided in the ensemble by predecessor models, rather than relying on the predecessor models to provide representative realizations (for subsequent models that the predecessor models may not be tuned for). The ensemble may thus provide linked elements that permit the uncertainty to be carried through to the different domains.

[0171] The method 411 may then include simulating the realizations using the field development engine, as at 407. The realizations may be simulated to determine a probability of success, viability, profitability, etc., of various combinations of inputs and outputs. The inputs might include, for example, different locations, equipment, drilling parameters, drilling activities, well trajectories, intervention processes, production parameters, etc. The inputs may also include economic models of price and cost of the resource extracted from the subterranean domain (e.g., hydrocarbon).

[0172] From this information one or more model realizations may be selected, and then equipment used and operations conducted, to the extent practical, based on the field development plan. In this respect, it will thus be appreciated that the generation of a field development plan, which more accurately accounts for uncertainty is a practical application for this method 411, which benefits the oil and gas exploration, drilling, and production technical fields. As known in the art, a field development plan provides an outline for developing, producing, and maintaining hydrocarbon resources in a particular field. Moreover, it forms an input for designing associated surface facilities. Accordingly, in at least some embodiments, the field development plan may be displayed to one or more users for such resource planning, facilities design, and process management. The method 411 may also include performing a wellsite action, as at 401 and 409. The wellsite action may be performed based upon a simulation using a multi-domain model of the subterranean terrain. The wellsite action may be or include generating and/or transmitting a signal (e.g., using a computing system) that causes a physical action to occur at a wellsite. The wellsite action may also or instead include performing the physical action at the wellsite. The physical action may be or include varying a weight and/or torque on a drill bit, varying a drilling trajectory, varying a concentration and/or flow rate of a fluid pumped into a wellbore, or the like.

[0173] Figure 17 illustrates a flowchart of a method 500 for generating a multi-domain model, according to an embodiment. The method 521 of Figure 17 may be part of the method 411 of Figure 16, e.g., the box 403. Accordingly, the methods 411 and 521 should not be considered mutually exclusive. The worksteps of the method 521 may be conducted in the order presented herein or in any other. Moreover, individual worksteps may be partitioned into two or more worksteps, conducted at least partially in parallel, or combined, without departing from the scope of the present disclosure.

[0174] The method 521 may include generating a first model, as at 501. For example, the first model may be or include one or more subsurface models (e g., geological, facies, basin, rock, fluid flow, etc ). These models cover uncertainties associated with the underground volume, e.g., location of underground water, pore size, etc.) as well as well trajectory, location, etc. The subsurface models may be generated from data collected in the oilfield, such as core data, seismic data, well logs, etc.

[0175] The method 521 may also include simulating one or more processes using the first model, as at 503. This simulating may generate realizations, which may be different outputs/outcomes of the simulated model based on the uncertainty in the models, uncertainty in the inputs, and accounting for probabilistic occurrences, etc. Each of these realizations thus may include different outputs, each with a different confidence level. Moreover, as noted above, at least some of the outputs, e.g., parameters, may not be on a continuous spectrum or range of values, but may include binary determinations and/or other non-linearities.

[0176] The realizations may be stored in an ensemble, with, for example, each element of the ensemble representing a different realization, as at 505. In some embodiments, the first model simulated may initially populate the uncertainty space, and may represent the least complexity of the uncertainty space, as the dimensionality of the uncertainty space may be determined according to the output parameters of the first model. As subsequent models are built and realized, this complexity may increase, as the individual elements may each be used to generate multiple additional realizations, which may be added to the associated elements of the ensemble. This creation of an ensemble with elements that store and/or otherwise represent the realizations may preserve the uncertainty information from the model and its simulations and provide it for access to subsequent models/simulations.

[0177] The method 521 may then include generating a second model at least partially by accessing the ensemble, as at 505. As mentioned above, the second model may build upon the first model, using the first model (e.g., from the physical domain) for modelling cost associated with a process. The second model may be a commercial model, configured to analyze options available to commercialize the output from the subsurface model (e.g., sell gas on the local market or build liquefied natural gas plats to sell on the international market). Such second model may have its own uncertainty parameters, and may thus be simulated, as at 507, based on the output of the individual realizations of the first model and/or at least some of the raw inputs to the first model. Given that the second model may be a probabilistic model, the output of the second model may include a plurality of realizations, covering a range of outcomes with different levels of confidence/uncertainty. The second model may thus be able to select from the universe of first model realizations, rather than, for example, the first model (e.g., in the subterranean domain) selecting which model realizations would be most representative for the second model (e.g., in the commercial domain) to work from.

[0178] Each of the realizations of the second model may be added to the element of the ensemble representing the realization of the first model and stored therein, as at 509. As such, the complexity of the uncertainty space/ensemble increases, as individual elements, which previously represented a realization of the first model, may now represent a plurality of realizations of the second model based on the first model, each with potentially a different uncertainty, in addition to representing the realization of the first model.

[0179] A third model may similarly be generated and simulated by accessing the ensemble, as at 509. The third model may be, for example, an economic model, permitting analysis of market conditions for investment and commercialization of the estimated reserves (e.g., oil price, cost of operations, capital expenditure to drill wells and build facilities, etc.). The third model may be a probabilistic model, and thus accessing a single realization of the second model, within a single realization of the first model, may generate a plurality of third model realizations. These may be added to the ensemble, and subsequent models likewise built by repeating this sequence. Again, for each subsequent model, the entire ensemble (or potentially a curated part) of the model realizations may be available to use for inputs to the subsequent model. The subsequent models may thus statistically sample from the available realizations in the ensemble for simulation, or even simulate all of the realizations.

[0180] Figure 18 illustrates an example of a system 601 for field development planning, according to an embodiment. The system 601 may be configured to implement one or more embodiments of the method(s) 411, 521 discussed above, and thus at least some of the elements of the system 601 may be provided by software, hardware, or a combination thereof. The system 601 may include an ensemble generator 603. This may be the repository for the model realizations, which may be successively added and linked, as discussed above. These models may be generated by a modelling environment 604, which may receive inputs (e.g., raw measurements and/or outputs from predecessor models) and may simulate the models, generating the new realizations that are added to the ensemble generator 603.

[0181] The modelling environment 604 and the ensemble generator 603 may be part of a data ecosystem 607. The data ecosystem 607 may provide rapid access to the modelling data that the modelling environment 604 manipulates/simulates. Accordingly, large amounts of data may be quickly accessed by successive modelling environments by reference to a location within the data ecosystem, rather than, for example, having to pass the data itself, which can be too large for practical transmission times. The data ecosystem can also provide for model management 609, automated analysis 610, and key realization selection 612. The “key” realizations selection may refer to realizations being selected for either simulation in a field development plan engine 614 or for further consideration (e.g., display to a human user or team of human users) for implementation. One reason to display the “key” realization(s) may be to investigate one or more outlier realizations. Another reason might be to inspect/validate in detail one or more realizations are conforming as expected to physically realistic flow (e.g. flow around a fault).

[0182] Figure 19 illustrates a conceptual view of building an ensemble 701 of realizations of a multi-dimensional model, according to an embodiment. By way of example, this view shows the increasing complexity of the ensemble 701 as successive modelling domains are implemented. The ensemble 700 may begin as data, e.g., seismic cubes, as at 703. The data may be interpreted, as at 705, providing several different probabilistic interpretations according to the different models used to interpret the data. The interpretations may then be modeled and gridded at 707. The models may then be used to form stratigraphic models, as at 707. In turn, the stratigraphic models may be used to create petrophysical models 709, which in turn are used to generated dynamic models 711. At each stage of the modelling process, the ensemble 701 expands, as multiple realizations may be formed from a single realization of the prior stage. That is, there are more stratigraphic model possibilities, for example, than structural models. Based on the dynamic models 711, insights can be gleaned, as at 713, such as recommendations for field development plans or portions thereof. [0183] Referring now to Figure 20, a flowchart of a method 801 is depicted, showing operations for a reservoir analysis process. The method 801 may occur prior to generating the multidimensional model at 404 of the method 411 of Figure 16. The method 801 may include storing, as at 803, one or more shared files in a central database including file relationship data and locations of bulk files. The method 801 may also include extracting one or more simulation models from the one or more shared files, as at 805, and providing metadata associated with the one or more simulation models to one or more client devices, as at 807. For example, the method 801 may include evaluating the metadata associated with the one or more simulation models to identify one or more simulation models to use in the multi-domain model. The simulations models, or a selection thereof based, e.g., on the metadata, may then be provided to the method 411, e.g., for generating the multi-domain model at 403.

[0184] For example, simulators have a relatively complicated input model, which is particularly true of the ECLIPSE® reservoir simulators and INTERSECT® reservoir simulators. These input models may be generated and modified by a number of workflows including manual edits and via the PETREL® subsurface software. Managing these models, including tracking updates and changes, as well as the associated results files is currently a manual process and usually accomplished via file naming conventions and comments in the models. These manual approaches are both hard to audit and error prone.

[0185] Figure 21 illustrates an example conceptual topography for a system to implement such a reservoir analysis process, according to an embodiment. The system may include a version control system for storing simulation data that may be designed to automate the versioning of simulator input and output files providing access to previous versions of the model, consistent auditing and tracking, and centralized storage for simulation models in collaborative workflows. The simulation version control system, referred to herein as “sim-store,” has similarities to version control systems for source code, although Sim-Store has additional logic to understand the relationship between the various files that comprise a complete simulation model. Versioned storage for simulation models has been prototyped in the past, but not with this additional logic. [0186] In some embodiments, reservoir analysis process may include the ability to extract simulation models from collections of fdes. The Sim-Store may provide a relationship between simulation input and output and the ability to identify if simulation results are stale. Embodiments may include the preservation of shared fdes and the ability to update multiple models through shared fdes. Embodiments may also provide a unique ID for simulations in the various environments (e.g., the DELFI® workspace). Sim-Store may not reverse the original data into an internal domain model.

[0187] In some embodiments, Sim-Store functionality may be delivered at least in part via a web applications programming interface (API). The SWAGGER EDITOR® API definition defines the endpoints for the service and may be viewed by cutting and pasting into the SWAGGER EDITOR® software. Traversal of the API may be achieved via following the links in the responses. URL mangling/construction may be avoided.

[0188] In some embodiments, reservoir analysis process may allow for the upload or update of one or more fdes. For example, if working with a new collection of fdes, the process may create a collection by POSTing on /vO/collections. The URL of the created collection may be returned in the response Location header. The process may GET the created collection using the location provided in last request, collectionld is in the "id" field of the payload. For a given collection, the process may create a staging area by POSTing on /vO/collections/{collectionId}/stagings. The URL of the created staging area may be returned in the response Location header. For each file to be created/changed POST to /vO/stagings/{stagingId}/changes/created or .../changed with payloads of the form

{

"data": {

"changeType": "created",

"path": [

"test.txt"

]

}

}

[0189] In some embodiments, the process may get the Upload link in the response Location header. The process may GET the Upload using the location provided in the previous response Using the content link in the Upload payload start the chunked upload. On getting 200 responses from the blob storage complete the upload by POSTing to the complete link provided in the Upload payload. The process may GET the FileChange using the location provided in the previous response. For each fde to be deleted POST on /vO/stagings/{stagingId}/changes/deleted. The POST on created, changed and deleted will fail if any of the files are wrongly categorized. When the files have been uploaded, POST on /vO/stagings/{stagingId}/complete to commit the set of files and create a new revision on the collection. Again, the POST may fail if any of the files have become wrongly categorized since the time they were uploaded.

[0190] In some embodiments, the process may get the files and results associated with a simulation. For a simulation URL GET the simulation information from/vO/simulation/ {simulationld} and from the response retrieve the array of file links. These are the files required to run the simulation. From the simulation response retrieve the results link and GET from /vO/simulation/{simulationId}/results. From the response retrieve the array of file links. These are the results associated with the simulation.

[0191] In some embodiments, the process may get the latest version of a simulation. Using simulation URL GET the simulation information from /v0/simulation/{ simulationld} and recover the array of version links. Sort and select the last link from the array of version links.

[0192] In some embodiments, the process may get the latest version of a file. Using a file URL GET the simulation information from /vO/files/{filesId} and recover the array of version links. The process may sort and select the last link from the array of version links.

[0193] In some embodiments, one or more extensions may be used to handle “bulk” ingestion scenarios where a large quantity of data that would take multiple days, or much longer, to ingest would limit the adoption of Sim-Store and DELFI® Reservoir Engineering. Approaches include “Shallow” Sim-Store in which the data is distributed between both the clients and the central server and can be moved on demand.

[0194] Alternatively, “Deferred” Sim-Store allows the meta-data of the file to be initially uploaded to sim-store, including the MD5 checksum, but the file content uploaded at a later date and checked against the original MD5.

[0195] Figures 22A-22C illustrate a flowchart of a method 1000, according to an embodiment. The method 1000 may include, before generating a multi-domain model, storing one or more shared files in a central database including file relationship data and locations of bulk files (e.g., 802, Figure 20), as at 1002. The method 1000 may also include extracting one or more simulation models from the one or more shared files (e.g., block 805, Figure 20), as at 1004. The method 1000 may further include evaluating metadata associated with the one or more simulation models to identify one or more simulation models to use in the multi-domain model (e.g., block 807, Figure 20), as at 1006. The method 1000 includes receiving input data representing a subterranean volume (e.g., block 401, Figure 16), as at 1008.

[0196] The method 1000 also includes generating a multi-domain model of the subterranean volume (e.g., block 403, Figure 16), as at 1010. In an embodiment, generating the multi-domain model includes generating an ensemble of a plurality of realizations of a first model based in least in part on the input data, an uncertainty of the input data, and an uncertainty of the first model (e.g., blocks 501-505, Figure 17), as at 1012. Generating the ensemble of the plurality of first realizations may include simulating a process using the first model (e.g., block 501, Figure 17), as at 1014. Generating the multi-domain model may also include generating a plurality of second realizations of a second model based at least in part on the ensemble of the plurality of first realizations and an uncertainty of the second model (e.g., blocks 507-509, Figure 17), as at 1016. Generating the multi-domain model may further include including the plurality of second realizations in the ensemble in connection with the realizations of the first model (e.g., block 511, Figure 17), as at 1018.

[0197] Generating the multi-domain model may include generating an uncertainty space in which the ensemble is represented, the realizations of the multi-domain model being distributed in the uncertainty space (e.g., 503 and 511, Figure 17), as at 1020. In some embodiments, the first model may include a model of at least one physical characteristic of the subterranean volume, and the second model comprises a commercial model, an economic model, or a combination thereof, as at 1021.

[0198] The method 1000 further includes statistically sampling one or more of the realizations of the multi-domain model based at least in part on an uncertainty associated therewith (e.g., block 405, Figure 16), as at 1022. Statistically sampling the one or more of the realizations includes statistically sampling the one or more realizations from the uncertainty space based on a distribution of the realizations in the uncertainty space, as at 1024. Statistically sampling from the uncertainty space may include identifying one or more areas of the uncertainty space that are underrepresented in the sampling, overrepresented in the sampling, represent one or more outlier realizations, or a combination thereof, as at 1026. Statistically sampling may include using machine learning, k-means clustering, probability bands, or a combination thereof to select the one or more realizations from among other, non-selected realizations, as at 1028.

[0199] The method 1000 includes simulating the sampled one or more of the realizations using a field development planning engine (e.g., block 407, Figure 16), as at 1030. The method 1000 includes generating a field development plan based at least in part on the simulated one or more of the realizations (e.g., block 409, Figure 16), as at 1040. In an embodiment, the method 1000 includes visualizing the field development plan, at least a portion of the multi-domain model, or both, to support one or more field development processes, as at 1042. The method 1000 may also include performing a wellsite action, as at 1006 (Figure 22A) and 1034 (Figure 22C). The wellsite action may be performed based upon the model realizations and simulations. The wellsite action may be or include generating and/or transmitting a signal (e.g., using a computing system) that causes a physical action to occur at a wellsite. The wellsite action may also or instead include performing the physical action at the wellsite. The physical action may be or include varying a weight and/or torque on a drill bit, varying a drilling trajectory, varying a concentration and/or flow rate of a fluid pumped into a wellbore, or the like.

[0200] In one or more embodiments, the functions described can be implemented in hardware, software, firmware, or any combination thereof. For a software implementation, the techniques described herein can be implemented with modules (e.g., procedures, functions, subprograms, programs, routines, subroutines, modules, software packages, classes, and so on) that perform the functions described herein. A module can be coupled to another module or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, or the like can be passed, forwarded, or transmitted using any suitable means including memory sharing, message passing, token passing, network transmission, and the like. The software codes can be stored in memory units and executed by processors. The memory unit can be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.

[0201] The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or limiting to the precise forms disclosed Many modifications and variations are possible in view of the above teachings. Moreover, the order in which the elements of the methods described herein are illustrate and described may be re-arranged, and/or two or more elements may occur simultaneously. The embodiments were chosen and described in order to best explain the principles of the disclosure and its practical applications, to thereby enable others skilled in the art to best utilize the disclosed embodiments and various embodiments with various modifications as are suited to the particular use contemplated.