Patent Description:
Increases in well complexity and associated challenges, especially extended reach wells in hydrocarbon fields (for example, carbonate reservoirs), have led to more complicated well stimulation treatments, for example, matrix acidizing, to increase production of hydrocarbons (for example, petroleum and natural gas). Challenges that consistently arise with planned and performed stimulation treatments include, for example, how to qualitatively evaluate near-wellbore horizontal/vertical permeability and zonal coverage of a well section before and after a stimulation treatment.

Abdulelah <NPL>)). describes receiving actual distributed temperature sensing (DTS) data and pressure data in response to a stimulation treatment applied to a hydrocarbon field through a well in the hydrocarbon field.

<CIT> describes a method for characterising a well using distributed temperature sensor data to optimise a well mode. The method comprises providing a well model of flow and thermal properties of the well, where the well model has a plurality of adjustable physical parameters, providing a data set made up of a plurality of distributed temperature sensor temperature profiles of the well taken at different times during operation of the well, and running the well model with different combinations of the plurality of adjustable physical parameters to match to the plurality of distributed temperature sensor temperature profiles.

In a paper presented at the <NPL> et al. describe application of permanent reservoir monitoring data in a mature offshore Malaysian oil field, for production optimisation and workover control.

<NPL>) describe the application of combined temperature and pressure data interpretation to characterization of near-wellbore reservoir structures.

<CIT> describes a method for calculating a property of a formation using one or more sensors lowered into a well on coiled tubing and surface well testing equipment.

The present patent describes computer-implemented methods for determining zonal coverage and evaluating designed and performed stimulations of hydrocarbon wells to increase hydrocarbon production. The invention is defined in the claims.

The present detailed description relates to evaluation of hydrocarbon well stimulations to increase hydrocarbon production.

The following subject matter is presented to enable person skilled in the art to make and use the disclosed subject matter in the context of one or more particular implementations. Various modifications, alterations, and permutations of the disclosed implementations can be made and will be readily apparent to those skilled in the art, and the general principles defined may be applied to other implementations and applications without departing from scope of the disclosure. Thus, the present disclosure is not intended to be limited to the described or illustrated implementations, but is to be accorded the widest scope consistent with the principles and features disclosed.

Increases in hydrocarbon well complexity and associated challenges, especially extended reach wells in carbonate reservoirs, have led to more complicated well stimulation treatments, for example, matrix acidizing, to increase production of hydrocarbons. Challenges that consistently arise with planned and performed stimulation treatments include, for example, how to qualitatively evaluate near-wellbore permeability (both horizontal and vertical) and zonal coverage of a hydrocarbon well section both before and after a stimulation treatment.

Stimulation evaluations can be time consuming, especially if a software production logging tool (PLT) or pressure transient tests are to be performed for each hydrocarbon well before and after simulation treatment(s), which result in a delay of hydrocarbon production - effectively lost revenue.

Additionally, it is challenging to quantify a hydrocarbon production improvement per foot in horizontal wells following a stimulation treatment. While effort is spent on modem technologies to qualitatively evaluate zonal coverage and estimate a skin factor evolvement after a stimulation, no work has yet answered how a stimulation (for example, a matrix acidizing treatment) alters near-wellbore permeability and affects zonation of a horizontal wellbore when treating carbonate reservoirs.

In long, horizontal wells that are drilled in carbonate formations, it is believed that wormholing significantly alters near-wellbore apparent permeability. Nevertheless, methods to estimate a change in permeability resulting from a matrix acidizing treatment are not known, and usually the change is accounted for in simulators by assigning a very low skin value. Other work conducted in carbonate reservoirs using pressure transient analysis techniques has shown that applying a change in permeability is necessary to obtain a type-curve match, though assumptions of a lump-sum value are made and the other techniques do not consider a skin per foot (S/ft)-type concept.

In this disclosure, a workflow for evaluating hydrocarbon well stimulations is described. The workflow can be used for effective stimulation of mega-reach wells using a real-time temperature profile. In some implementations, the described workflow can estimate changes in critical matrix rock properties and provide a mechanism to incorporate these estimated changes into future simulations. The workflow integrates, for example, while-drilling mobility data, open-hole porosity logs, pressure-transient data, distributed temperature survey data, production logging data, and the like to verify accuracy of a generated pre-stimulation model by using a flow rate as a control parameter for iterations. In applying the workflow that uses distributed temperature survey (DTS) and pressure-transient analysis (PTA), changes in critical matrix rock properties can be estimated and the estimated changes can be incorporated into further simulation(s) for optimizing operational time and for efficient zonal coverage.

In some implementations, detailed flow characteristics before and after a stimulation are obtained in an inverse type solution similar to well test interpretation. The results can be summarized in a table for comparing profiles before and after the stimulation. Several sensitivity runs can be performed to evaluate the effectiveness of each parameter of flow characteristics.

In some implementations, the described workflow allows a systematic reproduction of consistent results for all water injector wells. The workflow output provides reservoir simulation engineers with additional detailed information about flow characteristics in the critical matrix of the wells. The focus of the workflow is on permeability and skin per section of a horizontal section before and after a stimulation (for example, an acidizing matrix treatment).

In some implementations, the workflow focuses on permeability and skin per section of a horizontal section before and after a stimulation (for example, an acidizing matrix treatment). Application of the workflow can be a function of using coiled tubing (CT) that is fiber-optic-enabled to simultaneously pump and monitor a stimulation treatment. The workflow can receive input such as while-drilling mobility data, basic lithological interpretation prior to start of the workflow, and production logging tool (PLT) data either before or after the stimulation. In some implementations, using both before- and after-stimulation PLT data enhances the described workflow.

In some implementations, the described workflow can be implemented as a simulation model or a simulator. The simulation model can model water injection (for example, assuming incompressible fluid injection). The simulation model can include a transient model that uses both thermal finite difference and steady state pressure calculations to solve for a given transient flow within a predefined thermal time-step of pressure and/or flow. In some implementations, the simulation model can use a Joshi Steady State Model for horizontal flow, so consideration of both vertical and horizontal permeabilities are part of the described workflow methodology.

At a high level, <FIG> and <FIG> show an example workflow for generating a simulation model and calibrating the simulation model with actual data. A simulation model can be used to ensure proper execution of a tailored stimulation program. The simulation model includes a number of sub-models or modules for performing various operations, such as, data gathering, stimulation preparation, stimulation execution, stimulation evaluation, thermal modeling, pre-stimulation modeling and final verification and comparison. The output parameter of the simulation model can include, for example, simulated PLT log. The simulation model generates multiple outputs during and after stimulation execution, while the stimulation pumping schedule can be optimized or otherwise improved based on the ouptuts of the simulation model.

<FIG> illustrates a flow chart of an example method <NUM> for determining zonal coverage and evaluating designed and performed stimulations of hydrocarbon wells (for example, petroleum wells) to increase hydrocarbon production from a hydrocarbon field, according to an implementation. For clarity of presentation, the description that follows (including <FIG>) generally describes method <NUM> in the context of <FIG>, <FIG>, <FIG> & <FIG>, and <FIG>. However, it will be understood that method <NUM> may be performed, for example, by any suitable system, environment, software, and hardware, or a combination of systems, environments, software, and hardware as appropriate. In some implementations, various steps of method <NUM> can be run in parallel, in combination, in loops, and/or in any order.

At <NUM>, input well data is gathered or received. For example, input well data can include a wellbore diagram, directional survey, while-drilling mobility data, and processed lithological data or petro-physical logs. In some implementations, gathering input data can also include obtaining DTS thermal parameters for preparing thermal modeling at <NUM>, and/or obtaining permeability and skin parameters for pre-stimulation building at <NUM>. From <NUM>, method <NUM> proceeds to <NUM>.

At <NUM>, a stimulation treatment is prepared. In some implementations, preparing the stimulation treatment of the hydrocarbon field include obtaining DTS data and pressure data associated with the well in the hydrocarbon field. The DTS data and pressure data can be referred to as pre-stimulation DTS data and pressure data as they are collected prior to the execution of the stimulation treatment. In some implementations, preparing the stimulation treatment of the hydrocarbon field include, for example, designing a coiled tubing stimulation; testing the well infectivity; monitoring movement of injected fluid in the well; creating a pressure transient event to be analyzed for the permeability parameter and the skin parameter; or monitoring a warmback profile of the hydrocarbon field.

For example, a coil tubing (CT) stimulation treatment can be designed. Designing the CT stimulation can include, for example, designing a tubing force model (TFM) and a bottomhole assembly (BHA) (that is, a tool string at the bottom of the coil), for example, using software (for example, CoilUMIt) that calculates the TFM associated information. Designing the TFM can include calculating or otherwise determining information such as the dragging forces, buoyancy forces and friction forces. Designing the BHA can include determining information such as measurements of pressure gauge, temperature gauge, gamma ray sensor and DTS.

In some implementations, the TFM calculation is performed by calculating the forces along the length of a CT string at a specific depth in a well. The CT stimulation is run in a wellbore hole to total depth (TD) so that a geothermal DTS baseline profile (a geothermal reference) can be obtained for the wellbore/desired wellbore section. For DTS, a fiber optic line is inserted in the coil tubing that measures several parameters such as temperature and pressure on a continuous basis (for example, in real-time fashion) during the operation or as set (for example, prior to the operation and after completion of operation). In some implementations, the DTS baseline profile can be the measurements taken prior to the stimulation treatment or at a previous time instance of a current stimulation treatment.

Note that several actions (for example, attaching a pump to the wellhead, etc.) may take place between <NUM> and <NUM>. A pre-flush fluid can be bullheaded at a particular rate (typically a maximum allowable rate) for example to test the well injectivity. Pre-flush is a process to clean and prepare the formation for the stimulation job. In some implementations, the pre-flush fluid can include, for example, hydrochloric acid (HCl). The pre-flush fluid can be pumped ahead of the main treating fluid (for example, a mixture of hydrofluoric (HF) and HCl or organic acids) in a sandstone matrix-stimulation treatment.

During the pre-flush, thermal changes occurring in the wellbore are monitored using DTS in the CT annulus. In some implementations, the well injectivity is tested, movement of fluids in the wellbore are monitored, and a pressure transient event is created. A pressure transient event includes two main elements: <NUM>) an injection event (for example, by injecting a fluid with constant flow rate for limited time and <NUM>) a fall-off event (for example, by shutting the pump and measuring the change in pressure response). These two transient element events can be repeated as needed for analyzing K (formation permeability) and S (formation damage skin). The pumps are then shut-in, and warmback profiles (for example, warmback temperature traces) of the hydrocarbon field are obtained. From <NUM>, method <NUM> proceeds to <NUM>.

At <NUM>, it is determined whether enough pre-stimulation DTS and pressure data have been obtained by the stimulation preparation in <NUM>. In some implementations, the DTS data can include temperature, or any other data that are measured or otherwise obtained during a DTS. In some implementations, whether the DTS and pressure data are enough depends on one of the input parameters (reservoir parameters such as permeability K and skin S) for a pre-stimulation model building at <NUM>. For example, the DTS and pressure data is enough if a thermal match model and K and S match can be achieved based on the DTS and pressure data. Because these two parameters may not be the same for any two different wells, the determination at <NUM> can be based on case-by-case predetermined simulation studies.

When enough DTS and pressure data are obtained, stabilized temperature and pressure are reached with minimal changes, which can be a critical step in the data acquisition. In this case, method <NUM> proceeds to <NUM>. If the temperature and pressure have not reached a stabilized condition, the DTS and pressure data are insufficient and more pre-stimulation DTS and pressure data can be obtained. In some implementations, the stimulation preparation can be repeated to help generate additional DTS and pressure data. In some implementations, un-obtained reservoir parameters (that is, not an input) such as section length can be adjusted to obtained additional DTS and pressure data.

At <NUM>, a stimulation treatment is executed or performed. In some implementations, the stimulation treatment is performed by an injection system or another well system that include a computer system that can monitor, control or otherwise manage the execution of the stimulation treatment. For example, using the warmback temperature traces from <NUM>, high intake zones of the wellbore are detected (higher intake into particular wellbore zones (wellbore walls) of pre-flush results in a higher temperature associated with the zone). Given the determined well conditions (for example, high intake zones and DTS or pressure data), stimulation fluid pumping can be optimized by adjusting the flow rate (for example, gal/ft) to match the actual well conditions. Actual well conditions can be monitored in real time by DTS temperature response. In some implementations, in order to match the actual temperature with the temperature from the model, the tuning factor can be a pumping flow rate which can be adjusted from the surface pump during actual operation. Additionally, a decision can be made whether to use a chemical diverter to minimize impact to particular wellbore zones by adjusting the pumping schedule to place the chemical diverter in the particular wellbore zones. From <NUM>, method <NUM> proceeds to <NUM>.

At <NUM>, the stimulation treatment is evaluated. In some implementations, a post-flush fluid is bullheaded into the wellbore using the CT. For example, the post-flush fluid is bullheaded into the CT-Tubing (TBG) annulus (for example, the area between the utilized CT and the existing well TBG). DTS profiles are acquired while injecting the post-flush fluid until the volume of the wellbore is completed. In some implementations, the injection/fall-off of the pre-flush is compared with the injection/fall-off of the post-flush. For example, warmback temperature traces of the post-flush are monitored and compared with the pre-flush warmback temperature traces. The comparison can be used to evaluate chemical diversion and stimulation efficiency. Qualitative injection velocity and injection rate of the stimulation are determined by comparing slope changes (cooling/temperature fall-off) in the warmback temperature traces from both before and after pumping the stimulation. Using this data, improvements in flow paths or pressure response (or both) can be detected, for example, when matches in certain data (such as the match of thermal modeling and reservoir model) are obtained.

In some implementations, a production logging tool (PLT) run is performed (either in real-time or based on stored data). The PLT run can provide detailed information in association with the production of the well in downhole conditions. For example, PLT can generate a production profile of the well that captures the potential of sections/intervals based upon the well completion structure. PLT can also obtain pressure and temperature information. PLT can help obtain the exact downhole measurement of the well rate potential and classification of what sort of effluent is obtained. For instance, if one of the intervals has a lot of undesirable effluent production (for example, water in the case of an oil well), measures can be taken to shutoff those water producing intervals/sections. The PLT run can be performed before stimulation or after stimulation, or even both if required. From <NUM>, method <NUM> proceeds to <NUM>.

Turning to <FIG> is a continuation of illustrated flow chart of <FIG> of an example method <NUM> for determining zonal coverage and evaluating designed and performed stimulations of hydrocarbon wells to increase hydrocarbon production, according to an implementation.

At <NUM>, thermal modeling data is prepared, for example, by further modifying the previously acquired well data in terms of computational algorithm adoption, simulation, and putting data in the rightful format (for example, rates as a format for PLT). For example, the acquired well data can be fine-tuned or otherwise adjusted so that the difference between actual data versus simulated data is within a specified range of accuracy. The preparation can include preparing the previously acquired well data from <FIG> such as the DTS data and pressure data that are obtained prior to or during the stimulation treatment. For example, DTS traces acquired from <FIG> are conditioned or otherwise adjusted. From <NUM>, method <NUM> proceeds to <NUM>.

At <NUM>, a pre-stimulation model is built. The pre-stimulation model can include a thermal model that is created by defining completion and reservoir parameters. For example, the thermal model can be built by defining completion and reservoir sections/zones length using mobility/open-hold log data. The thermal model can receive or include reservoir parameters (for example, K, S, and section/zone length) and generate simulated DTS data and pressure data for the stimulation operation.

In some implementations, the pre-stimulation model can be built prior to the stimulation treatment in order to allow a real-time evaluation. In some implementations, the required changes (for example, a change or update of one or more of K, S, and section/zone length) are applied to match a first transient event (for example, either the cool-down or warm-back transient event) so that the prepared thermal modeling data support the entire simulation operation. As a specific example, changes of K from <NUM> to <NUM> md and S from <NUM> to <NUM> can be made so that the measured temperature profile from DTS sensor is the same or substantially the same as the profile obtained from simulation.

The simulated DTS and pressure data are utilized in the pre-stimulation model and adjusted until a match is achieved for use in the stimulation operation. In some implementations, a temperature transient model is used to estimate what would be a simulated temperature response as well as injection rate that corresponds to the pre-flush events (injection and warmback). An attempt is made to match three simulated thermal events (baseline, pre-flush injection, and pre-flush warmback) with actual data acquired above.

At <NUM>, a determination is made whether a thermal match between the actual DTS and pressure data and the simulated DTS and pressure data was obtained. In some implementations, a thermal match is defined as a difference of <NUM>% or less between the simulated and actual data.

For example, referring to <FIG> is an illustration of an actual vs. simulated injection-warmback DTS plot <NUM> with baseline, according to an implementation. Specifically, curves <NUM>, <NUM> and <NUM> are the actually DTSs during warmback and injection, whereas curves <NUM> and <NUM> the simulated DTSs during warmback and injection, respectively. Curves <NUM> and <NUM> are the baseline actual and simulated DTSs, respectively. As shown in <FIG>, the simulated DTSs match the actual DTSs.

<FIG> is an illustration of a simulated vs. actual DTS injection plot <NUM>, according to an implementation. Specifically, the curve <NUM> shows change of the simulated temperature whereas the curve <NUM> shows change of the actual temperature during injection. As shown in <FIG>, the simulated temperature matches the actual temperature. Returning to <FIG>, from <NUM>, method <NUM> proceeds to <NUM>.

In response to determining that the thermal match between the actual DTS and pressure data and the simulated DTS and pressure data is not obtained, reservoir parameters (for example, K, S, and section/zone length) are adjusted for building the pre-stimulation model and method <NUM> proceeds back to <NUM>. For example, the reservoir parameters (including the K and S parameters) are updated The pre-stimulation model is updated based on the updated reservoir parameters accordingly. Based on the updated pre-stimulation model, the simulated DTS and pressure data are re-generated until the thermal match between the actual DTS and pressure data and the simulated DTS and pressure data is obtained. In response to determining that the thermal match between the actual DTS and pressure data and the simulated DTS and pressure data is obtained, method <NUM> proceeds to <NUM>.

At <NUM>, a determination is made whether the K and S parameters match a performed pressure transient analysis (PTA). PTA is a process to interpret the pressure data and interpret K and S parameters. The K and S parameters match a PTA when the K and S parameters fall within respective ranges of K and S parameters determined by the PTA. In some implementations, the PTA is performed before the first transient event. In some implementations, the PTA is performed by the pressure data attained from the pressure gauge. If NO, reservoir parameters are continued to be adjusted for building the pre-stimulation model and method <NUM> proceeds back to <NUM>. For example, the reservoir parameters (including the K and S parameters) are updated The pre-stimulation model is further updated based on the updated reservoir parameters accordingly. Based on the updated pre-stimulation model, the simulated DTS and pressure data are re-generated until the thermal match between the actual DTS and pressure data and the simulated DTS and pressure data is obtained and the updated K parameter and the updated S parameter match the PTA. In response to determining the thermal match is obtained and the K and S parameters match the PTA, method <NUM> proceeds to <NUM>.

At <NUM>, a final stage processing is performed. Required changes for zonation, formation permeability, and formation damage skin are applied to obtain a thermal match resulting in a synthetic flow profiling (a virtual PLT) before a later stimulation. Data obtained from <NUM> is used to repeat the PLT execution of <NUM> and both <NUM> and <NUM>. The post-stimulation PLT data from the repeat from <NUM> is used to fine-tune the zonation, formation permeability, and formation damage skin values until a profile match is obtained. In some implementations, the data can be verified with the reservoir description and or records from management teams.

<FIG> is an illustration of an actual vs. simulated production rate plot 400a, according to an implementation. Specifically, the curve 402a shows the production rate at different depths based on the PLT, whereas the curve 404a shows the simulated production rate at different depths according to the example techniques described with respect to <FIG> and <FIG>.

<FIG> is an illustration of simulated (DTS driven) permeability of a reservoir before and after a stimulation treatment, according to an implementation. The simulated permeability is obtained using the simulation model described with respect to <FIG> and <FIG>. Specifically, the curve 402b shows the permeability at different depths before the stimulation treatment, whereas the curve 404b shows the simulated production rate at different depths after the stimulation treatment.

<FIG> is a block diagram of an exemplary computer system <NUM> used to provide computational functionalities associated with described algorithms, methods, functions, processes, flows, and procedures as described in the instant disclosure. The illustrated computer <NUM> is intended to encompass any computing device such as a server, desktop computer, laptop/notebook computer, wireless data port, smart phone, personal data assistant (PDA), tablet computing device, one or more processors within these devices, or any other suitable processing device, including both physical or virtual instances (or both) of the computing device. Additionally, the computer <NUM> may comprise a computer that includes an input device, such as a keypad, keyboard, touch screen, or other device that can accept user information, and an output device that conveys information associated with the operation of the computer <NUM>, including digital data, visual, or audio information (or a combination of information), or a GUI.

The computer <NUM> can serve in a role as a client, network component, a server, a database or other persistency, or any other component (or a combination of roles) of a computer system for performing the subject matter described in the instant disclosure. One or more components of the computer <NUM> may be configured to operate within environments, including cloud-computing-based, local, global, or other environment (or a combination of environments).

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

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

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

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

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

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

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

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

Implementations of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be implemented as one or more computer programs, that is, one or more modules of computer program instructions encoded on a tangible, non-transitory, computer-readable computer-storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively, or additionally, the program instructions can be encoded in/on an artificially generated propagated signal, for example, a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. The computer-storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of computer-storage mediums.

The term "real-time," "real time," "realtime," "real (fast) time (RFT)," "near(ly) real-time (NRT)," "quasi real-time," or similar terms (as understood by one of ordinary skill in the art), means that an action and a response are temporally proximate such that an individual perceives the action and the response occurring substantially simultaneously. For example, the time difference for a response to display (or for an initiation of a display) of data following the individual's action to access the data may be less than <NUM>, less than <NUM> sec. , less than <NUM> secs. , etc. While the requested data need not be displayed (or initiated for display) instantaneously, it is displayed (or initiated for display) without any intentional delay, taking into account processing limitations of a described computing system and time required to, for example, gather, accurately measure, analyze, process, store, or transmit the data.

The terms "data processing apparatus," "computer," or "electronic computer device" (or equivalent as understood by one of ordinary skill in the art) refer to data processing hardware and encompass all kinds of apparatus, devices, and machines for processing data, including by way of example, a programmable processor, a computer, or multiple processors or computers. The apparatus can also be or further include special purpose logic circuitry, for example, a central processing unit (CPU), an FPGA (field programmable gate array), or an ASIC (application-specific integrated circuit). In some implementations, the data processing apparatus or special purpose logic circuitry (or a combination of the data processing apparatus or special purpose logic circuitry) may be hardware- or software-based (or a combination of both hardware- and software-based). The apparatus can optionally include code that creates an execution environment for computer programs, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of execution environments. The present disclosure contemplates the use of data processing apparatuses with or without conventional operating systems, for example LINUX, UNIX, WINDOWS, MAC OS, ANDROID, IOS, or any other suitable conventional operating system.

A computer program, which may also be referred to or described as a program, software, a software application, a module, a software module, a script, or code can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program can be stored in a portion of a file that holds other programs or data, for example, 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, for example, files that store one or more modules, sub-programs, or portions of code. While portions of the programs illustrated in the various figures are shown as individual modules that implement the various features and functionality through various objects, methods, or other processes, the programs may instead include a number of sub-modules, third-party services, components, libraries, and such, as appropriate. Conversely, the features and functionality of various components can be combined into single components as appropriate. Thresholds used to make computational determinations can be statically, dynamically, or both statically and dynamically determined.

The methods, processes, logic flows, etc. described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The methods, processes, logic flows, etc. can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, for example, a CPU, an FPGA, or an ASIC.

Computers suitable for the execution of a computer program can be based on general or special purpose microprocessors, both, or any other kind of CPU. Generally, a CPU will receive instructions and data from a read-only memory (ROM) or a random access memory (RAM), or both. The essential elements of a computer are a CPU, for performing or executing instructions, and one or more memory devices for storing instructions and data. Generally, a computer will 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, for example, magnetic, magneto-optical disks, or optical disks. Moreover, a computer can be embedded in another device, for example, a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device, for example, a universal serial bus (USB) flash drive, to name just a few.

Computer-readable media (transitory or non-transitory, as appropriate) 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, for example, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks, for example, internal hard disks or removable disks; magneto-optical disks; and CD-ROM, DVD+/-R, DVD-RAM, and DVD-ROM disks. The memory may store various objects or data, including caches, classes, frameworks, applications, backup data, jobs, web pages, web page templates, database tables, repositories storing dynamic information, and any other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto. Additionally, the memory may include any other appropriate data, such as logs, policies, security or access data, reporting files, as well as others.

To provide for interaction with a user, implementations of the subject matter described in this specification can be implemented on a computer having a display device, for example, a CRT (cathode ray tube), LCD (liquid crystal display), LED (Light Emitting Diode), or plasma monitor, for displaying information to the user and a keyboard and a pointing device, for example, a mouse, trackball, or trackpad by which the user can provide input to the computer. Input may also be provided to the computer using a touchscreen, such as a tablet computer surface with pressure sensitivity, a multi-touch screen using capacitive or electric sensing, or other type of touchscreen. 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, for example, visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

The term "graphical user interface," or "GUI," may be used in the singular or the plural to describe one or more graphical user interfaces and each of the displays of a particular graphical user interface. Therefore, a GUI may represent any graphical user interface, including but not limited to, a web browser, a touch screen, or a command line interface (CLI) that processes information and efficiently presents the information results to the user. In general, a GUI may include a plurality of user interface (UI) elements, some or all associated with a web browser, such as interactive fields, pull-down lists, and buttons. These and other UI elements may be related to or represent the functions of the web browser.

Implementations of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, for example, as a data server, or that includes a middleware component, for example, an application server, or that includes a front-end component, for example, a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of wireline or wireless digital data communication (or a combination of data communication), for example, a communication network. Examples of communication networks include a local area network (LAN), a radio access network (RAN), a metropolitan area network (MAN), a wide area network (WAN), Worldwide Interoperability for Microwave Access (WIMAX), a wireless local area network (WLAN) using, for example, <NUM> a/b/g/n or <NUM> (or a combination of <NUM>. 11x and <NUM> or other protocols consistent with this disclosure), all or a portion of the Internet, or any other communication system or systems at one or more locations (or a combination of communication networks). The network may communicate with, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, or other suitable information (or a combination of communication types) between network addresses.

Claim 1:
A computer-implemented method (<NUM>), comprising:
receiving (<NUM>, <NUM>) actual distributed temperature sensing, i.e., DTS data and pressure data in response to a stimulation treatment applied to a hydrocarbon field through a well in the hydrocarbon field;
building (<NUM>, <NUM>) a pre-stimulation model that includes reservoir parameters, the pre-stimulation model generating simulated DTS and pressure data as a function of the reservoir parameters, the reservoir parameters comprising a permeability parameter and a skin parameter of the hydrocarbon field;
determining (<NUM>, <NUM>) whether a thermal match between the actual DTS and pressure data and the simulated DTS and pressure data is obtained;
in response to determining that the thermal match between the actual DTS and pressure data and the simulated DTS and pressure data is not obtained:
updating the reservoir parameters comprising updating the permeability parameter and the skin parameter;
updating the pre-stimulation model based on the updated reservoir parameters; and
re-generating the simulated DTS and pressure data based on the updated pre-stimulation model until the thermal match between the actual DTS and pressure data and the simulated DTS and pressure data is obtained;
determining (<NUM>) whether the updated permeability parameter and the updated skin parameter match a performed pressure transient analysis, i.e., PTA; and
in response to determining that the updated permeability parameter and the updated skin parameter do not match the PTA
updating the reservoir parameters comprising updating the updated permeability parameter and the updated skin parameter,
updating the pre-stimulation model based on the updated reservoir parameters, and
re-generating (<NUM>) the simulated DTS and pressure data based on the updated pre-stimulation model until the thermal match between the actual DTS and pressure data and the simulated DTS and pressure data is obtained and the updated permeability parameter and the updated skin parameter match the PTA.