The following description relates to simulating fluid flow in a fractured subterranean region.
Flow models have been used to simulate fluid flow in hydraulic fracture treatments and other environments. During a conventional fracture treatment of a subterranean reservoir, pressurized fluid is communicated from a wellbore into the reservoir at high pressure, and the pressurized fluid propagates fractures within the reservoir rock. Flow models can be used to simulate the flow of fluid within the fracture network. In some cases, flow models can be used to simulate leak-off and flow-back processes that are coupled to the fracture network.
Fluid flow models can be used to analyze fluid flow, for example, in a well system environment (e.g., in a wellbore, a fracture network, within the reservoir rock matrix, in a well system tool, etc.) or other environments. In some environments, the fluid flow is unsteady and multi-dimensional (e.g., three-dimensional or at least two-dimensional). For example, in some types of fractures, the dominant flow is two-dimensional, and includes transient behaviors. In some instances, two-or three-dimensional flow can be described by a one-dimensional flow model, for example, by integrating the governing flow equations over the cross-section of the two-or three-dimensional flow path. In some cases, the resulting equations include nonlinear partial differential equations that can be solved using finite difference, finite volume, or finite element methods. In some cases, the use of one-dimensional flow models can reduce computational costs, and allow for faster or more computationally efficient simulations. In some instances, a flow model can be used to perform numerical simulations in real time, for example, during a fracture treatment or during another well system activity.
In some cases, a fluid flow model models the flow of fluid in a fracture, for example, during a hydraulic fracturing treatment or another type of injection treatment. Hydraulic fracturing can improve the conductivity of a hydrocarbon reservoir, and modeling the hydraulic fracturing treatment can help to efficiently design, analyze, or optimize the treatment. In some cases, a hydraulic fracturing model combines simulations of fracture propagation, rock deformation, fluid flow, proppant transport, and other phenomena. The fluid flow models used in these and other types of simulations can account for the complex physical environments and conditions associated with some hydraulic fracturing activities. For example, in cases where the fluid pressure in the fractures and the rock deformation are implicitly coupled, the flow models can interact such that the solution of one model affects the other. As another example, some subterranean formations include low-permeability, naturally-fractured rock media, and the flow models can model a discrete or complex fracture network where the induced fractures interact with natural fractures. Other types of environments and conditions can be modeled, such as a flow-back network or a reservoir medium.
Accurate simulation and prediction of leak-off and flow-back processes between different fluid flow domains, for example, between fractures' fluids and reservoirs, can provide enhanced production during hydraulic fracturing of unconventional reservoirs and other types of reservoirs. In some cases, the leak-off process mainly affects the net pressure in the fracture network during the fracturing stage, hence accurate capturing of leak-off can allow more accurate predictions of the effective fracture length and width, which in turn can affect the overall permeability of the rock bed. This can also lead to a good estimate of loss of fracture fluid to the reservoir, for example, during the early stage of the fracturing. Similarly, correct prediction of the flow-back process can be important to determine net output from the reservoir in some instances. The modeling of these processes can account for the large extent of the computational domain associated with the reservoir, for example, using efficient computational techniques.
Some example computational flow modeling techniques are described here in terms of example flow equations and associated one-dimensional structures for fractures and leak-off models. The example techniques can be used with flow equations of different form or type, and the example techniques can be used with other types of flow structures. For example, some of the examples can be applied to any system that includes multiple one-dimensional models with connections at one end of each individual model.
The computing subsystem 110 can include one or more computing devices or systems located at the wellbore 102 or other locations. The computing subsystem 110 or any of its components can be located apart from the other components shown in
The example subterranean region 104 may include a reservoir that contains hydrocarbon resources, such as oil, natural gas, or others. For example, the subterranean region 104 may include all or part of a rock formation (e.g., shale, coal, sandstone, granite, or others) that contain natural gas. The subterranean region 104 may include naturally fractured rock or natural rock formations that are not fractured to any significant degree. The subterranean region 104 may include tight gas formations that include low permeability rock (e.g., shale, coal, or others).
The example well system 100 shown in
The example injection system 108 can inject treatment fluid into the subterranean region 104 from the wellbore 102. For example, a fracture treatment can be applied at a single fluid injection location or at multiple fluid injection locations in a subterranean zone, and the fluid may be injected over a single time period or over multiple different time periods. In some instances, a fracture treatment can use multiple different fluid injection locations in a single wellbore, multiple fluid injection locations in multiple different wellbores, or any suitable combination. Moreover, the fracture treatment can inject fluid through any suitable type of wellbore, such as, for example, vertical wellbores, slant wellbores, horizontal wellbores, curved wellbores, or combinations of these and others.
The example injection system 108 includes instrument trucks 114, pump trucks 116, and an injection treatment control subsystem 111. The example injection system 108 may include other features not shown in the figures. The injection system 108 may apply injection treatments that include, for example, a multi-stage fracture treatment, a single-stage fracture treatment, a mini-fracture test treatment, a follow-on fracture treatment, a re-fracture treatment, a final fracture treatment, other types of fracture treatments, or a combination of these. The injection system 108 may inject fluid into the formation above, at or below a fracture initiation pressure for the formation; above, at or below a fracture closure pressure for the formation; or at another fluid pressure.
The pump trucks 116 can include mobile vehicles, immobile installations, skids, hoses, tubes, fluid tanks, fluid reservoirs, pumps, valves, mixers, or other types of structures and equipment. The example pump trucks 116 shown in
The instrument trucks 114 can include mobile vehicles, immobile installations, or other suitable structures. The example instrument trucks 114 shown in
The injection system 108 may also include surface and down-hole sensors to measure pressure, rate, temperature or other parameters of treatment or production. For example, the injection system 108 may include pressure meters or other equipment that measure the pressure of fluids in the wellbore 102 at or near the ground surface 106 level or at other locations. The injection system 108 may include pump controls or other types of controls for starting, stopping, increasing, decreasing or otherwise controlling pumping as well as controls for selecting or otherwise controlling fluids pumped during the injection treatment. The injection treatment control subsystem 111 may communicate with such equipment to monitor and control the injection treatment.
The example injection treatment control subsystem 111 shown in
In the example shown in
In some implementations, the computing subsystem 110 can simulate fluid flow in the well system 100. For example, the computing subsystem 110 can include flow models for simulating fluid flow in or between various locations of fluid flow in the well system, such as, for example, the wellbore 102, the perforations 120, the conduit 112 or components thereof, the dominant fractures 132, the natural fracture networks 130, the rock media in the subterranean region 104, or a combination of these and others. The flow models can model the flow of incompressible fluids (e.g., liquids), compressible fluids (e.g., gases), or a combination of multiple fluid phases. The flow models can model the flow of fluid in an intersection of flow paths. In some cases, the flow models can model the flow of fluids during leak-off or flow-back processes. In some instances, the flow models can model flow in one, two, or three spatial dimensions. The flow models can include nonlinear systems of differential or partial differential equations. The computing subsystem 110 can use the flow models to predict, describe, or otherwise analyze the dynamic behavior of fluid in the well system 100. In some cases, the computing subsystem 110 can perform operations such as generating or discretizing governing flow equations or processing governing flow equations.
The computing subsystem 110 can perform simulations before, during, or after the injection treatment. In some implementations, the injection treatment control subsystem 111 controls the injection treatment based on simulations performed by the computing subsystem 110. For example, a pumping schedule or other aspects of a fracture treatment plan can be generated in advance based on simulations performed by the computing subsystem 110. As another example, the injection treatment control subsystem 111 can modify, update, or generate a fracture treatment plan based on simulations performed by the computing subsystem 110 in real time during the injection system.
In some cases, the simulations are based on data obtained from the well system 100. For example, pressure meters, flow monitors, microseismic equipment, tiltmeters, or other equipment can perform measurements before, during, or after an injection treatment; and the computing subsystem 110 can simulate fluid flow based on the measured data. In some cases, the injection treatment control subsystem 111 can select or modify (e.g., increase or decrease) fluid pressures, fluid densities, fluid compositions, and other control parameters based on data provided by the simulations. In some instances, data provided by the simulations can be displayed in real time during the injection treatment, for example, to an engineer or other operator of the well system 100.
Some of the techniques and operations described herein may be implemented by one or more computing systems configured to provide the functionality described. In various instances, a computing system may include any of various types of devices, including, but not limited to, personal computer systems, desktop computers, laptops, notebooks, mainframe computer systems, handheld computers, workstations, tablets, application servers, computer clusters, distributed computing systems, storage devices, or any type of computing or electronic device.
The communication link 280 can include any type of communication channel, connector, data communication network, or other link. For example, the communication link 280 can include a wireless or a wired network, a Local Area Network (LAN), a Wide Area Network (WAN), a private network, a public network (such as the Internet), a WiFi network, a network that includes a satellite link, or another type of data communication network.
The memory 250 can store instructions (e.g., computer code) associated with an operating system, computer applications, and other resources. The memory 250 can also store application data and data objects that can be interpreted by one or more applications or virtual machines running on the computing system 200. As shown in
In some instances, the data 254 include treatment data relating to fracture treatment plans. For example the treatment data can indicate a pumping schedule, parameters of a previous injection treatment, parameters of a future injection treatment, or parameters of a proposed injection treatment. Such parameters may include information on flow rates, flow volumes, slurry concentrations, fluid compositions, injection locations, injection times, or other parameters.
In some instances, the data 254 include geological data relating to geological properties of a subterranean region. For example, the geological data may include information on wellbores, completions, or information on other attributes of the subterranean region. In some cases, the geological data includes information on the lithology, fluid content, stress profile (e.g., stress anisotropy, maximum and minimum horizontal stresses), pressure profile, spatial extent, porosity, or other attributes of reservoir media in the subterranean zone. The geological data can include information collected from well logs, rock samples, outcroppings, microseismic imaging, or other data sources.
In some instances, the data 254 include fracture data relating to fractures in the subterranean region. The fracture data may identify the locations, sizes, shapes, and other properties of fractures in a model of a subterranean zone. The fracture data can include information on natural fractures, hydraulically-induced fractures, or any other type of discontinuity in the subterranean region. The fracture data can include fracture planes calculated from microseismic data or other information. For each fracture plane, the fracture data can include information (e.g., strike angle, dip angle, etc.) identifying an orientation of the fracture, information identifying a shape (e.g., curvature, aperture, etc.) of the fracture, information identifying boundaries of the fracture, or any other suitable information.
In some instances, the data 254 include fluid data relating to well system fluids. The fluid data may identify types of fluids, fluid properties, thermodynamic conditions, and other information related to well system fluids. The fluid data can include flow models for compressible or incompressible fluid flow. For example, the fluid data can include systems of governing equations that represent fluid flow generally or fluid flow under certain types of conditions. In some cases, the governing flow equations define a nonlinear system of equations. The fluid data can also include information about truncation error thresholds or other system constraints. The fluid data can include data related to native fluids that naturally reside in a subterranean region, treatment fluids to be injected into the subterranean region, hydraulic fluids that operate well system tools, or other fluids that may or may not be related to a well system.
The applications 258 can include software applications, scripts, programs, functions, executables, or other modules that are interpreted or executed by the processor 260. For example, the applications 258 can include a fluid flow simulation module, a hydraulic fracture simulation module, a reservoir simulation module, or another type of simulator. The applications 258 may include machine-readable instructions for performing one or more of the operations related to
The processor 260 can execute instructions, for example, to generate output data based on data inputs. For example, the processor 260 can run the applications 258 by executing or interpreting the software, scripts, programs, functions, executables, or other modules contained in the applications 258. The processor 260 may perform one or more of the operations related to
The example architecture 300 shown in
The example fluid system 310 can include any physical system where fluid flow or other fluid phenomena occur. The fluid system 310 can represent a well system environment (e.g., the well system 100 shown in
The data acquisition system 320 can include systems or hardware that obtain data from the fluid system 310. For example, the data acquisition system 320 can include flow sensors, pressure sensors, temperature sensors, and other types of measurement devices. The data acquisition system 320 can include communication and data storage systems that store, transfer, manipulate, or otherwise manage the information obtained from the fluid system 310.
The fluid flow simulation system 330 can include one or more computer systems or computer-implemented programs that simulate fluid flow. The fluid flow simulation system 330 can receive information related to the fluid system 310 and simulate fluid flow and other fluid phenomena that occur in the fluid system 310. For example, the fluid flow simulation system 330 can calculate flow velocities or other aspects of fluid flow based on data from the data acquisition system 320 or another source.
The example fluid flow simulation system 330 includes fluid system data 332, flow models 334, and a solver 342. The fluid flow simulation system can include additional or different features, and the features of a fluid flow simulation system 330 can be configured to operate in another manner. The modules of the fluid flow simulation system 330 can include hardware modules, software modules, or other types of modules. In some cases, the modules can be integrated with each other or with other system components. In some example implementations, the fluid flow simulation system 330 can be implemented as software running on a computing system, and the modules of the fluid flow simulation system 330 can be implemented as software functions or routines that are executed by the computing system.
The fluid system data 332 can include any information related to the fluid system 310 or another fluid system. For example, the fluid system data 332 can indicate physical properties (e.g., geometry, cross-sectional areas, surface properties, etc.) of one or more flow paths in the fluid system 310, material properties (e.g., density, porosity, viscosity, Reynolds number, etc.) of one or more fluids in the fluid system 310, thermodynamic data (e.g., fluid pressures, fluid temperatures, fluid flow rates, etc.) measured at one or more locations in the fluid system 310, and other types of information. The fluid system data 332 can include information received from the data acquisition system 320 and other sources.
The flow models 334 can include any information or modules that can be used to simulate fluid flow. As shown in
The flow model 334 can include multiple subsystem models to represent various physical subsystems of the fluid system 310. For example, the flow model 334 can include fracture models to represent flow within fractures, flow-back models to represent fluid flow between reservoir rock and adjacent fractures, wellbore models to represent fluid flow within wellbores or wellbore tools, and other types of subsystem models. In some cases, the subsystem models are coupled, for example, by boundary conditions, by governing flow equations, or by other considerations.
In some examples, the flow equations 336 include a set of governing flow equations for a one-dimensional flow model. A first subset of the governing flow equations can represent flow within a fracture, while a second subset of the governing flow equations represents flow within a reservoir medium (e.g., rock or another type of material) adjacent to the fracture. The set of governing flow equations can include additional or different equations or subsets of equations. In some instances, the flow equations include a reduced set of governing flow equations. The reduced set of equations can be generated, for example, by eliminating a subset of governing flow equations. In some cases, equations can be eliminated based on fluid coupling between disparate subsystem models (e.g., coupling between a fracture model and a flow-back model). In some instances, the reduced set of equations contains fewer unknown values, as compared to the non-reduced set of equations.
The decompositions 338 can include equations, data structures, or other information for eliminating equations from a set of governing flow equations. For example, the decompositions 338 can include a Cholesky decomposition of a flow-back model or another type of flow model, and the Cholesky decomposition can be used to reduce the number of governing flow equations in the overall flow model 334, for example, as described below. As another example, the decompositions 338 can include a banded LU decomposition of a flow-back model or another type of flow model. Other types of decompositions can be used.
The flow models 334 can include spatial discretization data, such as, for example, discrete nodes that represent locations of fluid flow along flow paths in the fluid system 310. Generally, the flow models 334 can represent any number of intersecting flow path branches, including any type of flow path intersection. In some cases, the flow path branches represent a fracture network and reservoir media in a subterranean region, and connectivity between the flow path branches can correspond to the fracture connectivity in the fracture network, or fluid coupling between fractures and reservoir media. In some cases, the flow paths represent flow conduits in a wellbore, perforations in a wellbore casing, hydraulic fractures extending from a wellbore, natural fractures connected to hydraulic fractures or a wellbore, flow paths for leak-off or flow-back processes, or other types of interconnected flow paths in a well system environment.
The spatial discretization of the flow paths can be implemented by any suitable algorithm. For example, the system can be discretized according to a finite difference model, a finite volume model, finite element model, or another technique. The system can be discretized in a manner that permits spatial derivatives or partial spatial derivatives to be solved in the discretized spatial domain using numerical methods.
In some implementations, the fluid flow simulation system 330 can also include a time marching module to perform calculations in a discretized time domain. For example, the governing flow equations may include derivatives or partial derivatives in the time domain, and the time marching module can calculate such quantities based on a time marching algorithm. Example time marching schemes include the backward Euler scheme, the Crank-Nicolson scheme, and others.
The solver 342 can include any information or modules that can be used to solve a system of equations. For example, the solver 342 can be a direct solver or another type of solver. In some implementations, the solver 342 receives inputs from the other components of the fluid flow simulation system 330. For example, the inputs can include a reduced set of the discretized governing flow equations, the fluid system data 332, or any other information. The inputs can also include data generated or reported from a separate simulation or model. The solver 342 can generate a numerical solution for a variable of interest based on the inputs. The solution can be generated for some or all of the nodes in a discretized spatial domain. For example, the solver 342 may calculate values of fluid velocity, fluid pressure, or another variable over a spatial domain; the values can be calculated for an individual time step or multiple time steps.
The analysis system 360 can include any systems, components, or modules that analyze, process, use, or access the simulation data generated by the fluid flow simulation system 330. For example, the analysis system 360 can be a real time analysis system that displays or otherwise presents fluid data (e.g., to a field engineer, etc.) during an injection treatment. In some cases, the analysis system 360 includes another simulator or a simulation manager that uses the fluid simulation data to simulate other aspects of a well system. For example, the analysis system 360 can be a fracture simulation suite that simulates fracture propagation based on the simulated fluid flow data generated by the fluid flow simulation system 330. As another example, the analysis system 360 can be a reservoir simulation suite that simulates fluid migration in a reservoir based on the simulated fluid flow data generated by the fluid flow simulation system 330.
The example fluid flow model 400 includes multiple nodes. Nodes 411a, 411b, 411c represent locations along the fracture flow path 410 within a fracture. Nodes 421a, 421b, 421c, 421d represent locations along the reservoir flow path 420 within the reservoir media adjacent to the fracture. Nodes 431a, 431b, 431c, 431d represent locations along the reservoir flow path 430 within the reservoir media adjacent to the fracture. Nodes 441a, 441b, 441c, 441d represent locations along the reservoir flow path 440 within the reservoir media adjacent to the fracture. In the example, shown, the reservoir flow paths 420, 430, 440 are coupled to the fracture flow path 410 at the nodes 411a, 411b, 411c.
Each node represents a respective location of fluid flow along one of the flow paths. The flow paths can extend through one, two, or three spatial dimensions. As such, the spatial dimension of a one-dimensional flow model does not necessarily correspond to a single physical spatial dimension. In some cases, a one-dimensional flow model can incorporate flow in more than one spatial dimension, for example, to account for intersecting flow paths, curved flow paths, etc. The example flow model 400 can also include initial conditions, boundary conditions, connection conditions, governing flow equations, etc. The governing flow equations can include, for example, Navier-Stokes equations, continuity equations, and others.
In some instances, the fluid flow model can model a flow-back process. An interaction between a reservoir medium and its surrounding fluid can be approximated via a fluid flow model such as a flow-back model. The flow-back model can model the two-way flows between the fracture network and the reservoir medium. The two-way flows designated as leak-off or flow-back can be mathematically identical, and the terms can be used interchangeably with respect to the models; for example, a “flow-back model” can cover flow-back, leak-off, and similar flows. The two-way flows can be governed by the difference in the pressures between pressure in the core of the reservoir medium and that of the fluid flows around its boundaries. The two-way flow interactions between the fracture flow and the reservoir medium can be modeled in different situations. For example, the fracture flow model and the flow-back model can be coupled via pressure variables. The domains of the reservoir and the fracture can be two-dimensional or three-dimensional.
A flow-back process can be modeled by a one-dimensional Darcy type of relation, given by
α
In equation (1),
The Darcy flow direction y can be defined as positive into the reservoir media with the interface between the fracture and the flow-back network defined as y=0. In some instances, flow-back flow can be in the direction of decreasing y and leak-off flow can be in the direction of increasingy. If the domain of Equation (1) is finite, the maximum value for y can be given as yR, and Equation (1) can be discretized using a method such as finite differences, finite volumes, finite elements, or another method. If the domain of Equation (1) is infinite, then a finite element discretization can be used.
In the case of a slightly compressible fluid in a compressible reservoir medium, the parameters in Equation (1) can be written as:
α=φρ(cf+(φ0/φ)cr) (2)
and
In Equations (2) and (3), φ is the formation porosity, k is the formation permeability, ρ is the fluid density, μ is the fluid viscosity, cf is the fluid compressibility and cr is the formation compressibility.
To obtain solutions of Equation (1), appropriate and physical boundary conditions can be supplied at both ends of the computational domain. For example, a Dirichlet boundary can be implemented at the fracture interface (y=0), in which the flow-back pressure
Fluid mass balance in the overall system can be conserved when using the example model for flow-back. The mass flux from the fracture to the flow-back network at y=0 can be given by v=−β
In equation (4), A is the area of the fracture cross-section, p is the fluid pressure along the fracture, x is the spatial variable along the fracture direction, and μ is the fluid viscosity coefficient. Other fracture fluid flow models could be used, e.g. the full Navier-Stokes equations or a simplification thereof.
A naïve way of solving this system would be to discretize the governing equations described by Equation (1) and Equation (4), and then solve the resulting system to advance the solution in time. Henceforth, this naïve approach will be referred as Approach 1 (A1).
A more efficient algorithm (measured in terms of wall-time and the memory requirement) can be used as follows, referred to as Approach 2 (A2). The governing equations such as Equation (1) and Equation (4) can be discretized using the implicit backward Euler method in time and second-order central differences for the spatial derivatives. Other discretization techniques can be used in time (e.g. Crank-Nicolson) and space (e.g. finite volume methods, finite element methods, or other finite difference methods).This gives the local coefficient matrix Ai for equation (1) in a particular leak-off or flow-back path i:
In the local coefficient matrix Ai, the α and β variables are given by Equation (2) and Equation (3), respectively.
The local coefficient matrix Ai can be solved or reduced via a variety of techniques. For example, the matrix Ai can be solved using Cholesky decomposition. In Cholesky decomposition, the local coefficient matrix Ai is decomposed as:
Ai=LLT (6)
In Equation (6), the L denotes a lower triangular matrix, and LT is its transpose. For the cases where the parameters α, β, h and Δt are fixed, the Cholesky decomposition can be performed once and stored and reused in other computations. The example coefficient matrix shown in Equation (5) is an example of a tri-diagonal matrix, and a tri-diagonal version of the Cholesky method can be used for the decomposition.
For each flow-back flow path i, an internal elimination can be performed on the respective local variables in the discretization of Equation (1). Thus, Equation (1) can be eliminated from the discretized system, reducing the total number of discrete equations in the flow model. For example, if Equation (1) is eliminated, only Equation (4) remains. The coupling of Equations (1) and Equation (4) can be contained entirely in the
The example models described here can use a finite difference discretization under uniform mesh spacing. However, other discretization methods such as finite volumes and finite elements, utilization of non-uniform meshes, or employing higher-order discretization schemes could be used. For example, non-uniform meshes could be used to resolve the filter-cake effects. In addition, other matrix solving procedures can be used. For example, a banded LU decomposition could be used for solving discretization matrices that are not symmetric.
Multiple fluids of different types can also be modeled. For example, standard multiphase porous media flow equations in one-dimension can be used instead of Equation (1). The equations can be linearized by several possible methods, including Newton-Raphson or quasi-linearization. A method such as banded LU decomposition can be used to solve the associated local coefficient matrix. A banded LU decomposition can decompose a matrix into a product of a lower triangular matrix and an upper triangular matrix.
For example, two fluids can be modeled by a piston-like displacement of the reservoir fluid by the leak-off or flow-back fluid. If the leak-off or flow-back fluid and the reservoir fluid are both compressible, then Equation (1) can be used to model both fluids in two contiguous moving domains. The two fluids can have different parameters α and β. At the interface between the two fluids, a boundary condition can be imposed to enforce a continuous Darcy velocity. If the leak-off or flow-back fluid is incompressible (e.g. in the case of water leaking off into a gas reservoir), then the equation for the leak-off or flow-back fluid can be simplified to spatially constant velocity, β
The example process 500 can be used to simulate the flow of various fluids. In some cases, the process 500 is used to simulate one or more well system fluids. Here, the term “well system fluid” is used broadly to encompass a wide variety of fluids that may be found in or near, or may be used in connection with, a well system. Well system fluids can include one or more native fluids that reside in a subterranean region (e.g., brine, oil, natural gas, etc.), one or more fluids that have been or will be injected into a subterranean region (e.g., fracturing fluids, treatment fluids, etc.), one or more fluids that have been or will be communicated within a wellbore or within one or more tools installed in the well bore (e.g., drilling fluids, hydraulic fluids, etc.), and other types of fluids. The example process 500 can also simulate multiple types of fluid flowing within the same system.
The example process 500 can simulate fluid flow based on a one-dimensional fluid flow model. The flow model can include nodes of a discretized one-dimensional flow path. For example, the process 500 can use the example flow model 400 shown in
At 502, intersecting flow paths are identified. In some cases, the intersecting flow paths are identified by identifying an intersection node shared by two flow paths in the flow model. The intersecting flow paths can be one or more fracture flow paths and reservoir flow paths. The intersection can represent leak-off or flow-back between a fracture and reservoir rock media in a subterranean region. For example, the flow-back flow paths can be coupled to fracture flow paths at the intersections.
At 504, the governing equations are discretized. The governing flow equations can be provided by the flow model or another source. The governing flow equations can include, for example, Navier-Stokes equations, Darcy flow equations, convection or diffusion equations, continuity equations, and others. The governing equations can be discretized according to a finite difference technique or another discretization method. For example, the implicit backward Euler method can be used for time and second-order central differences can be used for spatial derivatives. In some cases, discretizing the governing flow equations can generate one or more coefficient matrices. The discretization for each node can incorporate fluid communication with an adjacent node in each flow direction. The discretization can incorporate fluid communication across more than one adjacent node in each flow direction. For example, the discretization at each node can incorporate fluid communication across two or three adjacent nodes in each direction of flow.
At 506, a reduced set of discretized governing flow equations is generated. The reduced set of governing flow equations can be generated by eliminating a subset of governing flow equations. In some cases, the subset of governing flow equations is eliminated by solving or reducing a coefficient matrix. For example, a method such as Cholesky or LU decomposition can be implemented. In some implementations, governing flow equations for flow-back are eliminated based on coupling with governing flow equations for a fracture.
At 520, a solution is obtained. The solution can be obtained based on the reduced set of discretized governing flow equations. In some implementations, the discretized governing flow equations are solved numerically. For example, an iterative method such as Newton's method can be used to solve the equations and obtain the solution. The solution can indicate one or more flow velocities, pressures, or values for other variables at each discretized location on the flow paths.
In some cases, the equations for the fracture flow paths are solved, and then the solutions are propagated to the equations for flow-back flow paths to solve the entire system. For example, with reference to
The plots in
Table 1 shows that, in this example, Approach 2 can give identical results with less than half of the calculation time as Approach 1.
Table 1 shows simulation results as calculated on a serial computer. Given that the internal elimination operations are independent of each other, they can be performed in parallel enabling significant improvement in the elapsed calculation time. An example parallel run result is reported in Table 2.
As shown in Table 2, a parallel computation technique can reduce calculation time, in some instances significantly.
Some embodiments of subject matter and operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Some embodiments of subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a computer storage medium for execution by, or to control the operation of, data processing apparatus. A computer storage medium can be, or can be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).
The term “data processing apparatus” encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing. The apparatus can include special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The apparatus and execution environment can realize various different computing model infrastructures, such as web services, distributed computing and grid computing infrastructures.
A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
Some of the processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. A computer includes a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. A computer may also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices (e.g., EPROM, EEPROM, flash memory devices, and others), magnetic disks (e.g., internal hard disks, removable disks, and others), magneto optical disks , and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
To provide for interaction with a user, operations can be implemented on a computer having a display device (e.g., a monitor, or another type of display device) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse, a trackball, a tablet, a touch sensitive screen, or another type of pointing device) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.
A computer system can be or include a single computing device, or multiple computers that operate in proximity or generally remote from each other and typically interact through a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an inter-network (e.g., the Internet), a network comprising a satellite link, and peer-to-peer networks (e.g., ad hoc peer-to-peer networks). A relationship of client and server may arise by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
While this specification contains many details, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular examples. Certain features that are described in this specification in the context of separate implementations can also be combined. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple embodiments separately or in any suitable subcombination.
A number of examples have been described. Nevertheless, it will be understood that various modifications can be made. Accordingly, other implementations are within the scope of the following claims.
This application claims priority to U.S. Provisional Application Ser. No. 61/870,716, filed on Aug. 27, 2013, entitled “Simulating a Fluid Flow in a Subterranean Region.”
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2013/059409 | 9/12/2013 | WO | 00 |
Number | Date | Country | |
---|---|---|---|
61870716 | Aug 2013 | US |