WO2017004476A1

WO2017004476A1 - Fluid relationship tracking to support model dependencies

Info

Publication number: WO2017004476A1
Application number: PCT/US2016/040605
Authority: WO
Inventors: David Saier; Kurt Andreas George SCHMIDT
Original assignee: Schlumberger Technology Corporation; Schlumberger Canada Limited; Services Petroliers Schlumberger; Geoquest Systems B.V.
Priority date: 2015-07-01
Filing date: 2016-07-01
Publication date: 2017-01-05
Also published as: US20180156014A1; EP3317785A4; EP3317785A1

Abstract

A method, apparatus, and program product manage model dependencies in a petroleum simulation environment. Version data is maintained both for a model or data set used by a first simulation application and for a dependent model used by a second simulation application and based upon the model or data set used by the first simulation application. After the model or data set used by the first simulation application is updated, as well as the version data therefor, a determination is made as to whether the dependent model is antiquated based upon the version data maintained for the dependent model and the version data for the updated model or data set used by the first simulation application.

Description

FLUID RELATIONSHIP TRACKING TO SUPPORT MODEL DEPENDENCIES

Cross-Reference to Related Applications

[0001] This application claims the filing benefit of U.S. Provisional Patent Application Serial No. 62/187,399, U.S. Provisional Patent Application Serial No.

62/187,403, U.S. Provisional Patent Application Serial No. 62/187,313, and U.S.

Provisional Patent Application Serial No. 62/187,319, all of which were filed on July 1 , 2015, and all of which are incorporated by reference herein in their entirety.

Background

[0002] Fluid simulation is used in the oil & gas industry to model the physical properties of petrochemicals, as the physical properties of such fluids can have a significant impact on the extraction, production and flow of such fluids within a petroleum production system. Fluids recovered from a reservoir generally include hydrocarbons of various molecular weights and other organic compounds, as well as some proportion of water, and depending upon the temperature and pressure to which such fluids are exposed, such fluids may include varying concentrations of liquid and gas components. Fluid models generated by fluid simulations may also be used by various types of other simulations, e.g., reservoir simulations that model the quantities and locations of recoverable hydrocarbons in reservoirs and/or the flow of such hydrocarbons within wells drilled into such reservoirs, surface network simulations that model the flow of recovered hydrocarbons through pipelines and other surface production components, etc.

Summary

[0003] The embodiments disclosed herein provide a method, apparatus, and program product that manage model dependencies in a petroleum simulation environment. Version data is maintained both for a model or data set used by a first simulation application and for a dependent model used by a second simulation application and based upon the model or data set used by the first simulation application. After the model or data set used by the first simulation application is updated, as well as the version data therefor, a determination is made as to whether the dependent model is antiquated based upon the version data maintained for the dependent model and the version data for the updated model or data set used by the first simulation application.

[0004] Some embodiments also include notifying at least one user in response to determining that the dependent model is antiquated, while some embodiments include automatically updating the dependent model in response to determining that the dependent model is antiquated. In addition, in some embodiments, the first simulation application is a fluid simulator, the model or data set used by the first simulation application is a first fluid model, and a second model used by the dependent model is automatically updated in response to determining that the dependent model is antiquated. Some embodiments also include automatically running a simulation in the second simulation application using the dependent model and the automatically updated second fluid model used by the dependent model in response to determining that the dependent model is antiquated, while in some embodiments automatically updating the second fluid model used by the dependent model includes generating the automatically updated second fluid model by performing a tuning or lumping operation on the first fluid model. Further, in some embodiments, generating the automatically updated second fluid model further includes determining the tuning or lumping operation to be performed by accessing version data for the second fluid model.

[0005] In some embodiments, the first simulation application is a fluid simulator, the model or data set used by the first simulation application is a fluid model, a first version of the fluid model is generated from preliminary data collected from a downhole fluid analyzer, and updating the model or data set used by the first simulation

application includes generating a second version of the fluid model from data generated from analysis of a physical fluid sample. In some embodiments, the first simulation application is a fluid simulator, the model or data set used by the first simulation application is a first fluid model, the dependent model is among multiple coupled dependent models including a reservoir simulation model, a surface network simulation model and a facilities fluid model, and each of the multiple dependent models uses a different fluid model derived from the first fluid model.

[0006] In addition, in some embodiments, the version data includes a unique identifier, a time stamp, an update history, a lumping scheme, a tuning approach, an experiment from which a data set is derived, or an experiment from which a model is derived, and in some embodiments, the version data for the dependent model is attached to the dependent model or maintained in a version database. Further, in some embodiments determining whether the dependent model is antiquated is performed in response to opening a project, and a determination is made as to whether any of multiple models or data sets in the project is antiquated. Some embodiments also include determining whether to update the dependent model based upon an

experimental data classification of the dependent model.

[0007] In addition, in some embodiments a fluid model used by a fluid simulator may be dynamically tuned by receiving first user input selecting a first set of one or more properties among multiple tunable properties for the fluid model, in response to receiving the first user input, dynamically running a regression for the first set of one or more properties and generating a display of expected tuning results for the first set of one or more properties, thereafter receiving second user input selecting a different, second set of one or more properties while the display of expected tuning results for the first set of one or more properties is displayed, and in response to receiving the second user input, dynamically running a regression for the second set of one or more properties and updating the display to display expected tuning results for the second set of one or more properties.

[0008] In some embodiments, dynamically running the regression for the first set of one or more properties and dynamically running the regression for the second set of one or more properties are performed in a background process or thread, dynamically running the regression for each property in the first set of one or more properties is performed in parallel, and dynamically running the regression for the first set of one or more properties and dynamically running the regression for the second set of one or more properties are performed as full or fast regressions. Further, in some embodiments dynamically running the regression for the first set of one or more properties and dynamically running the regression for the second set of one or more properties are each performed by generating values for an objective function, an initial value for the objective function associated with the fluid model is generated without any tuning, and dynamically running the regression for the first set of one or more properties is performed by running a regression for each individual property in the first set of one or more properties and running a regression for each possible combination of the properties in the first set of one or more properties.

[0009] In addition, in some embodiments, properties of a fluid are determined by for each of multiple conditions over which to generate a flash grid, determining a range corresponding to the condition, for each determined range, determining multiple values of the corresponding condition and distributed within the range, for each combination of determined values within the determined ranges of the multiple conditions, performing a flash calculation to calculate one or more fluid properties of the fluid, and displaying a visualization based upon the flash calculations.

[0010] In some embodiments, the multiple conditions includes n conditions, an n- dimensional array having n coordinates respectively corresponding to the n conditions is generated, and each coordinate includes the determined values within the determined range of the corresponding condition. Further, some embodiments perform flash calculations in parallel, and interpolate the one or more fluid properties for at least one combination of values of the multiple conditions, while some embodiments perform, in response to user input to zoom in on the visualization, additional flash calculations within a subset of at least one of the determined ranges, and interpolate, prior to performing the additional flash calculations, a fluid property for at least one combination of values of the multiple conditions within the subset of the at least one of the

determined ranges such that the performance of the additional flash calculations replaces the interpolated fluid property. [0011] In addition, in some embodiments, fluids modeled by a fluid simulator are compared by receiving user input selecting at least two fluids among multiple fluids modeled by the fluid simulator, in response to the user input, generating a data visualization that compares the selected fluids, and displaying the data visualization.

[0012] Some embodiments also display at least one user control representing the multiple fluids, where the user input is received from the at least one user control, and some embodiments receive additional user input selecting a different subset of fluids from among the multiple fluids and dynamically update the data visualization in response to the additional user input. Some embodiments also receive additional user input changing a first fluid among the selected fluids and dynamically update the data visualization in response to the additional user input, while in some embodiments, the multiple fluids include multiple versions of a first fluid, and the multiple versions differ based upon one or more of lumping, tuning or flash package.

[0013] Other embodiments may include an apparatus including at least one processing unit and program code configured upon execution by the at least one processing unit to perform any of the above-described operations. Still other

embodiments may include a program product including a non-transitory computer readable medium and program code stored on the computer readable medium and configured upon execution by at least one processing unit to perform any of the above- described operations.

[0014] These and other advantages and features, which characterize the invention, are set forth in the claims annexed hereto and forming a further part hereof. However, for a better understanding of the invention, and of the advantages and objectives attained through its use, reference should be made to the Drawings, and to the accompanying descriptive matter, in which there is described example embodiments of the invention. This summary is merely provided to introduce a selection of concepts that are further described below in the detailed description, and 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

[0015] FIGURE 1 is a block diagram of an example hardware and software environment for a data processing system in accordance with implementation of various technologies and techniques described herein.

[0016] FIGURES 2A-2D illustrate simplified, schematic views of an oilfield having subterranean formations containing reservoirs therein in accordance with

implementations of various technologies and techniques described herein.

[0017] FIGURE 3 illustrates a schematic view, partially in cross section of an oilfield having a plurality of data acquisition tools positioned at various locations along the oilfield for collecting data from the subterranean formations in accordance with implementations of various technologies and techniques described herein.

[0018] FIGURE 4 illustrates a production system for performing one or more oilfield operations in accordance with implementations of various technologies and techniques described herein.

[0019] FIGURE 5 is a block diagram of a simulation platform in accordance with implementations of various technologies and techniques described herein.

[0020] FIGURE 6 is a block diagram illustrating a propagation of updates to a fluid model to a reservoir simulation fluid in accordance with implementations of various technologies and techniques described herein.

[0021] FIGURE 7 is a flowchart of an open project routine in accordance with implementations of various technologies and techniques described herein.

[0022] FIGURE 8 is a block diagram of an example user interface for dynamically tuning a fluid model in accordance with implementations of various technologies and techniques described herein.

[0023] FIGURE 9 is a flowchart of a tune fluid model routine in accordance with implementations of various technologies and techniques described herein. [0024] FIGURE 10 illustrates a phrase envelope visualization generated by a conventional algorithm.

[0025] FIGURE 11 illustrates a flash grid visualization in accordance with implementations of various technologies and techniques described herein.

[0026] FIGURE 12 is a flowchart of a generate flash grid routine in accordance with implementations of various technologies and techniques described herein.

[0027] FIGURE 13 is a flowchart of a zoom in on flash grid routine in accordance with implementations of various technologies and techniques described herein.

[0028] FIGURE 14 is a flowchart of an export operating envelope routine in accordance with implementations of various technologies and techniques described herein.

[0029] FIGURE 15 is a block diagram of an example user interface for comparing different versions of a fluid in accordance with implementations of various technologies and techniques described herein.

[0030] FIGURE 16 is a flowchart of an open comparison user interface routine in accordance with implementations of various technologies and techniques described herein.

[0031] FIGURE 17 is a flowchart of a fluid changed routine in accordance with implementations of various technologies and techniques described herein.

[0032] FIGURE 18 is a flowchart of a save changes routine in accordance with implementations of various technologies and techniques described herein.

Detailed Description

[0033] Turning now to the drawings, wherein like numbers denote like parts throughout the several views, Fig. 1 illustrates an example data processing system 10 in which the various technologies and techniques described herein may be implemented. System 10 is illustrated as including one or more computers 12, e.g., client computers, each including a central processing unit (CPU) 14 including at least one hardware- based processor or processing core 16. CPU 14 is coupled to a memory 18, which may represent the random access memory (RAM) devices comprising the main storage of a computer 12, as well as any supplemental levels of memory, e.g., cache memories, non-volatile or backup memories (e.g., programmable or flash memories), read-only memories, etc. In addition, memory 18 may be considered to include memory storage physically located elsewhere in a computer 12, e.g., any cache memory in a

microprocessor or processing core, as well as any storage capacity used as a virtual memory, e.g., as stored on a mass storage device 20 or on another computer coupled to a computer 12.

[0034] Each computer 12 also generally receives a number of inputs and outputs for communicating information externally. For interface with a user or operator, a computer 12 generally includes a user interface 22 incorporating one or more user input/output devices, e.g., a keyboard, a pointing device, a display, a printer, etc.

Otherwise, user input may be received, e.g., over a network interface 24 coupled to a network 26, from one or more external computers, e.g., one or more servers 28 or other computers 12. A computer 12 also may be in communication with one or more mass storage devices 20, which may be, for example, internal hard disk storage devices, external hard disk storage devices, storage area network devices, etc.

[0035]A computer 12 generally operates under the control of an operating system 30 and executes or otherwise relies upon various computer software

applications, components, programs, objects, modules, data structures, etc. For example, a petro-technical module or component 32 executing within an exploration and production (E&P) platform 34 may be used to access, process, generate, modify or otherwise utilize petro-technical data, e.g., as stored locally in a database 36 and/or accessible remotely from a collaboration platform 38. Collaboration platform 38 may be implemented using multiple servers 28 in some implementations, and it will be appreciated that each server 28 may incorporate a CPU, memory, and other hardware components similar to a computer 12. [0036] In one non-limiting embodiment, for example, petro-technical module 32 may include one or more simulators such reservoir simulators, flow simulators, fluid simulators, surface network simulators, production simulators, etc., E&P platform 34 may implemented as the PETREL Exploration & Production (E&P) software platform, while collaboration platform 38 may be implemented as the STUDIO E&P

KNOWLEDGE ENVIRONMENT platform, all of which are available from Schlumberger Ltd. and its affiliates. It will be appreciated, however, that the techniques discussed herein may be utilized in connection with other platforms and environments, so the invention is not limited to the particular software platforms and environments discussed herein.

[0037] In general, the routines executed to implement the embodiments disclosed herein, whether implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions, or even a subset thereof, will be referred to herein as "computer program code," or simply "program code." Program code generally comprises one or more instructions that are resident at various times in various memory and storage devices in a computer, and that, when read and executed by one or more hardware-based processing units in a computer (e.g., microprocessors, processing cores, or other hardware-based circuit logic), cause that computer to perform the steps embodying desired functionality. Moreover, while embodiments have and hereinafter will be described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments are capable of being distributed as a program product in a variety of forms, and that the invention applies equally regardless of the particular type of computer readable media used to actually carry out the distribution.

[0038] Such computer readable media may include computer readable storage media and communication media. Computer readable storage media is non-transitory in nature, and may include volatile and non-volatile, and removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules or other data.

Computer readable storage media may further include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable readonly memory (EEPROM), flash memory or other solid state memory technology, CD- ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and which can be accessed by computer 10.

Communication media may embody computer readable instructions, data structures or other program modules. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above may also be included within the scope of computer readable media.

[0039] Various program code described hereinafter may be identified based upon the application within which it is implemented in a specific embodiment of the invention. However, it should be appreciated that any particular program nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature.

Furthermore, given the endless number of manners in which computer programs may be organized into routines, procedures, methods, modules, objects, and the like, as well as the various manners in which program functionality may be allocated among various software layers that are resident within a typical computer (e.g., operating systems, libraries, API's, applications, applets, etc.), it should be appreciated that the invention is not limited to the specific organization and allocation of program functionality described herein.

[0040] Furthermore, it will be appreciated by those of ordinary skill in the art having the benefit of the instant disclosure that the various operations described herein that may be performed by any program code, or performed in any routines, workflows, or the like, may be combined, split, reordered, omitted, and/or supplemented with other techniques known in the art, and therefore, the invention is not limited to the particular sequences of operations described herein. [0041] Those skilled in the art will recognize that the example environment illustrated in Fig. 1 is not intended to limit the invention. Indeed, those skilled in the art will recognize that other alternative hardware and/or software environments may be used without departing from the scope of the invention.

Oilfield Operations

[0042] Figs. 2A-2D illustrate simplified, schematic views of an oilfield 100 having subterranean formation 102 containing reservoir 104 therein in accordance with implementations of various technologies and techniques described herein. Fig. 2A illustrates a survey operation being performed by a survey tool, such as seismic truck 106.1 , to measure properties of the subterranean formation. The survey operation is a seismic survey operation for producing sound vibrations. In Fig. 2A, one such sound vibration, sound vibration 1 12 generated by source 1 10, reflects off horizons 1 14 in earth formation 1 16. A set of sound vibrations is received by sensors, such as geophone-receivers 1 18, situated on the earth's surface. The data received 120 is provided as input data to a computer 122.1 of a seismic truck 106.1 , and responsive to the input data, computer 122.1 generates seismic data output 124. This seismic data output may be stored, transmitted or further processed as desired, for example, by data reduction.

[0043] Fig. 2B illustrates a drilling operation being performed by drilling tools 106.2 suspended by rig 128 and advanced into subterranean formations 102 to form wellbore 136. Mud pit 130 is used to draw drilling mud into the drilling tools via flow line 132 for circulating drilling mud down through the drilling tools, then up wellbore 136 and back to the surface. The drilling mud may be filtered and returned to the mud pit. A circulating system may be used for storing, controlling, or filtering the flowing drilling muds. The drilling tools are advanced into subterranean formations 102 to reach reservoir 104. Each well may target one or more reservoirs. The drilling tools are adapted for measuring downhole properties using logging while drilling tools. The logging while drilling tools may also be adapted for taking core sample 133 as shown. [0044] Computer facilities may be positioned at various locations about the oilfield 100 (e.g., the surface unit 134) and/or at remote locations. Surface unit 134 may be used to communicate with the drilling tools and/or offsite operations, as well as with other surface or downhole sensors. Surface unit 134 is capable of communicating with the drilling tools to send commands to the drilling tools, and to receive data therefrom. Surface unit 134 may also collect data generated during the drilling operation and produces data output 135, which may then be stored or transmitted.

[0045] Sensors (S), such as gauges, may be positioned about oilfield 100 to collect data relating to various oilfield operations as described previously. As shown, sensor (S) is positioned in one or more locations in the drilling tools and/or at rig 128 to measure drilling parameters, such as weight on bit, torque on bit, pressures,

temperatures, flow rates, compositions, rotary speed, and/or other parameters of the field operation. Sensors (S) may also be positioned in one or more locations in the circulating system.

[0046] Drilling tools 106.2 may include a bottom hole assembly (BHA) (not shown), generally referenced, near the drill bit (e.g., within several drill collar lengths from the drill bit). The bottom hole assembly includes capabilities for measuring, processing, and storing information, as well as communicating with surface unit 134. The bottom hole assembly further includes drill collars for performing various other measurement functions.

[0047] The bottom hole assembly may include a communication subassembly that communicates with surface unit 134. The communication subassembly is adapted to send signals to and receive signals from the surface using a communications channel such as mud pulse telemetry, electro-magnetic telemetry, or wired drill pipe

communications. The communication subassembly may include, for example, a transmitter that generates a signal, such as an acoustic or electromagnetic signal, which is representative of the measured drilling parameters. It will be appreciated by one of skill in the art that a variety of telemetry systems may be employed, such as wired drill pipe, electromagnetic or other known telemetry systems. [0048] Generally, the wellbore is drilled according to a drilling plan that is established prior to drilling. The drilling plan sets forth equipment, pressures, trajectories and/or other parameters that define the drilling process for the wellsite. The drilling operation may then be performed according to the drilling plan. However, as information is gathered, the drilling operation may need to deviate from the drilling plan. Additionally, as drilling or other operations are performed, the subsurface conditions may change. The earth model may also need adjustment as new information is collected

[0049] The data gathered by sensors (S) may be collected by surface unit 134 and/or other data collection sources for analysis or other processing. The data collected by sensors (S) may be used alone or in combination with other data. The data may be collected in one or more databases and/or transmitted on or offsite. The data may be historical data, real time data, or combinations thereof. The real time data may be used in real time, or stored for later use. The data may also be combined with historical data or other inputs for further analysis. The data may be stored in separate databases, or combined into a single database.

[0050] Surface unit 134 may include transceiver 137 to allow communications between surface unit 134 and various portions of the oilfield 100 or other locations. Surface unit 134 may also be provided with or functionally connected to one or more controllers (not shown) for actuating mechanisms at oilfield 100. Surface unit 134 may then send command signals to oilfield 100 in response to data received. Surface unit 134 may receive commands via transceiver 137 or may itself execute commands to the controller. A processor may be provided to analyze the data (locally or remotely), make the decisions and/or actuate the controller. In this manner, oilfield 100 may be selectively adjusted based on the data collected. This technique may be used to optimize portions of the field operation, such as controlling drilling, weight on bit, pump rates, or other parameters. These adjustments may be made automatically based on computer protocol, and/or manually by an operator. In some cases, well plans may be adjusted to select optimum operating conditions, or to avoid problems. [0051] Fig. 2C illustrates a wireline operation being performed by wireline tool 106.3 suspended by rig 128 and into wellbore 136 of Fig. 2B. Wireline tool 106.3 is adapted for deployment into wellbore 136 for generating well logs, performing downhole tests and/or collecting samples. Wireline tool 106.3 may be used to provide another method and apparatus for performing a seismic survey operation. Wireline tool 106.3 may, for example, have an explosive, radioactive, electrical, or acoustic energy source 144 that sends and/or receives electrical signals to surrounding subterranean

formations 102 and fluids therein.

[0052] Wireline tool 106.3 may be operatively connected to, for example, geophones 1 18 and a computer 122.1 of a seismic truck 106.1 of Fig. 2A. Wireline tool 106.3 may also provide data to surface unit 134. Surface unit 134 may collect data generated during the wireline operation and may produce data output 135 that may be stored or transmitted. Wireline tool 106.3 may be positioned at various depths in the wellbore 136 to provide a survey or other information relating to the subterranean formation 102.

[0053] Sensors (S), such as gauges, may be positioned about oilfield 100 to collect data relating to various field operations as described previously. As shown, sensor S is positioned in wireline tool 106.3 to measure downhole parameters which relate to, for example porosity, permeability, fluid composition and/or other parameters of the field operation.

[0054] Fig. 2D illustrates a production operation being performed by production tool 106.4 deployed from a production unit or Christmas tree 129 and into completed wellbore 136 for drawing fluid from the downhole reservoirs into surface facilities 142. The fluid flows from reservoir 104 through perforations in the casing (not shown) and into production tool 106.4 in wellbore 136 and to surface facilities 142 via gathering network 146.

[0055] Sensors (S), such as gauges, may be positioned about oilfield 100 to collect data relating to various field operations as described previously. As shown, the sensor (S) may be positioned in production tool 106.4 or associated equipment, such as Christmas tree 129, gathering network 146, surface facility 142, and/or the production facility, to measure fluid parameters, such as fluid composition, flow rates, pressures, temperatures, and/or other parameters of the production operation.

[0056] Production may also include injection wells for added recovery. One or more gathering facilities may be operatively connected to one or more of the wellsites for selectively collecting downhole fluids from the wellsite(s).

[0057] While Figs. 2B-2D illustrate tools used to measure properties of an oilfield, it will be appreciated that the tools may be used in connection with non-oilfield operations, such as gas fields, mines, aquifers, storage, or other subterranean facilities. Also, while certain data acquisition tools are depicted, it will be appreciated that various measurement tools capable of sensing parameters, such as seismic two-way travel time, density, resistivity, production rate, etc., of the subterranean formation and/or its geological formations may be used. Various sensors (S) may be located at various positions along the wellbore and/or the monitoring tools to collect and/or monitor the desired data. Other sources of data may also be provided from offsite locations.

[0058] The field configurations of Figs. 2A-2D are intended to provide a brief description of an example of a field usable with oilfield application frameworks. Part, or all, of oilfield 100 may be on land, water, and/or sea. Also, while a single field measured at a single location is depicted, oilfield applications may be utilized with any combination of one or more oilfields, one or more processing facilities and one or more wellsites.

[0059] Fig. 3 illustrates a schematic view, partially in cross section of oilfield 200 having data acquisition tools 202.1 , 202.2, 202.3 and 202.4 positioned at various locations along oilfield 200 for collecting data of subterranean formation 204 in accordance with implementations of various technologies and techniques described herein. Data acquisition tools 202.1 -202.4 may be the same as data acquisition tools 106.1 -106.4 of Figs. 2A-2D, respectively, or others not depicted. As shown, data acquisition tools 202.1 -202.4 generate data plots or measurements 208.1 -208.4, respectively. These data plots are depicted along oilfield 200 to demonstrate the data generated by the various operations. [0060] Data plots 208.1 -208.3 are examples of static data plots that may be generated by data acquisition tools 202.1 -202.3, respectively, however, it should be understood that data plots 208.1 -208.3 may also be data plots that are updated in real time. These measurements may be analyzed to better define the properties of the formation(s) and/or determine the accuracy of the measurements and/or for checking for errors. The plots of each of the respective measurements may be aligned and scaled for comparison and verification of the properties.

[0061] Static data plot 208.1 is a seismic two-way response over a period of time. Static plot 208.2 is core sample data measured from a core sample of the formation 204. The core sample may be used to provide data, such as a graph of the density, porosity, permeability, or some other physical property of the core sample over the length of the core. Tests for density and viscosity may be performed on the fluids in the core at varying pressures and temperatures. Static data plot 208.3 is a logging trace that generally provides a resistivity or other measurement of the formation at various depths.

[0062] A production decline curve or graph 208.4 is a dynamic data plot of the fluid flow rate over time. The production decline curve generally provides the production rate as a function of time. As the fluid flows through the wellbore, measurements are taken of fluid properties, such as flow rates, pressures, composition, etc.

[0063] Other data may also be collected, such as historical data, user inputs, economic information, and/or other measurement data and other parameters of interest. As described below, the static and dynamic measurements may be analyzed and used to generate models of the subterranean formation to determine characteristics thereof. Similar measurements may also be used to measure changes in formation aspects over time.

[0064] The subterranean structure 204 has a plurality of geological formations 206.1 -206.4. As shown, this structure has several formations or layers, including a shale layer 206.1 , a carbonate layer 206.2, a shale layer 206.3 and a sand layer 206.4. A fault 207 extends through the shale layer 206.1 and the carbonate layer 206.2. The static data acquisition tools are adapted to take measurements and detect characteristics of the formations.

[0065] While a specific subterranean formation with specific geological structures is depicted, it will be appreciated that oilfield 200 may contain a variety of geological structures and/or formations, sometimes having extreme complexity. In some locations, generally below the water line, fluid may occupy pore spaces of the formations. Each of the measurement devices may be used to measure properties of the formations and/or its geological features. While each acquisition tool is shown as being in specific locations in oilfield 200, it will be appreciated that one or more types of measurement may be taken at one or more locations across one or more fields or other locations for comparison and/or analysis.

[0066] The data collected from various sources, such as the data acquisition tools of Fig. 3, may then be processed and/or evaluated. Generally, seismic data displayed in static data plot 208.1 from data acquisition tool 202.1 is used by a geophysicist to determine characteristics of the subterranean formations and features. The core data shown in static plot 208.2 and/or log data from well log 208.3 are generally used by a geologist to determine various characteristics of the subterranean formation. The production data from graph 208.4 is generally used by the reservoir engineer to determine fluid flow reservoir characteristics. The data analyzed by the geologist, geophysicist and the reservoir engineer may be analyzed using modeling techniques.

[0067] Fig. 4 illustrates an oilfield 300 for performing production operations in accordance with implementations of various technologies and techniques described herein. As shown, the oilfield has a plurality of wellsites 302 operatively connected to central processing facility 354. The oilfield configuration of Fig. 4 is not intended to limit the scope of the oilfield application system. Part or all of the oilfield may be on land and/or sea. Also, while a single oilfield with a single processing facility and a plurality of wellsites is depicted, any combination of one or more oilfields, one or more processing facilities and one or more wellsites may be present. [0068] Each wellsite 302 has equipment that forms wellbore 336 into the earth. The wellbores extend through subterranean formations 306 including reservoirs 304. These reservoirs 304 contain fluids, such as hydrocarbons. The wellsites draw fluid from the reservoirs and pass them to the processing facilities via surface networks 344. The surface networks 344 have tubing and control mechanisms for controlling the flow of fluids from the wellsite to processing facility 354.

Simulation Platform

[0069] Fig. 5 illustrates an example simulation platform 400, e.g., similar to E&P platform 34 of Fig. 1 . Platform 400 may support a plurality of simulation applications, or simulators, such as one or more fluid simulators 402, one or more reservoir simulators 404, one or more surface network simulators 406, etc. Simulators 402-406 may be used in some embodiments in connection with integrated asset modeling, and as such, may be used to collectively model both the subsurface and surface elements of a petroleum production system. It will be appreciated that different simulators that utilize fluids in various simulations may be used in different embodiments, including various types of reservoir, surface, flow assurance and facilities simulators, among others.

[0070] Platform 400 may also support projects 408, representing collections of related data and analysis results for a particular collection of assets, e.g., for a particular field, reservoir, etc. Projects 408, for example, may include one or more fluid-related data sets 410 including experimental data collected for one or more fluids, as well as one or more data sets 412 including experimental data collected for use by other simulators, e.g., seismic data, wellbore data collected via MWD or LWD, etc., as well as other associated data such as surface network and well layouts, sensor data, etc. Such data may be used in the generation of one or more models for use in analyzing the collection of assets for the project. For fluid simulator 402, for example, one or more fluid models 414 may be developed to model one or more fluids present at various points in the collection of assets, and likewise, for other types of simulators (e.g., simulators 404, 406), one or more simulator models 416 may be used to model other aspects of a collection of assets, e.g., modeling flow in a reservoir, modeling a surface network, modeling a wellbore, etc.

[0071] In some embodiments, each data set 410, 412 and/or each model 414, 416 may include version data 418, which may include information suitable for

distinguishing or identifying the data/model. Further, in some embodiments, version data 418 may include information for use in maintaining coherence between different data sets and/or models, e.g., such that if one model is based upon another model and/or a particular data set, and that other model or particular data set is updated, a lack of coherence with the other model may be determined, enabling a user associated with the project to be notified and/or for a model to be automatically updated.

Fluid Relationship Tracking to Support Model Dependencies

[0072] Some asset modeling approaches may utilize fragmented fluid models of the same fluid system in order to model various sectors of petroleum production operations. Difficulties may arise in an asset modelling workflow when coupling the various sectors in an overall workflow. One example of this is coupling a reservoir simulation fluid model with a surface network simulation fluid model to a facilities fluid model. These fluids are often different due to the nature of the fluid models, the numerical methods in each sector and the desired level of fidelity in the components to capture the physics of the fluid. Various different types of fluid simulators, also known as PVT (Pressure Volume Temperature) software, may be used to create a fluid model at each stage of the process, and there may be limited knowledge of the fluid to which a simulation is coupled (forward and backward). This may result in various

inconsistencies in the physics of a fluid and no chain of custody from which to base asset model decisions. Fluid models may become out of synchronization with one another and the various simulations that depend upon such fluid models, and as a result these dependent simulations may not be updated accordingly when the underlying fluid models are modified. Fluid data repository systems may be used in some instances to store various versions of a fluid; however, comparisons of those various versions is generally not supported. It therefore becomes incumbent on users to manually update simulations when fluid models are updated, increasing user efforts and posing a risk that updates will be missed.

[0073] In embodiments consistent with the invention, on the other hand, version data is maintained for one or more fluids to assist in maintaining relationships between different models of a fluid used by different simulation applications. As such, when additional experimental data is acquired and used to generate a new version of a "master" fluid model, the version data for other previously developed fluid models used for other simulation applications may be accessed to determine whether such fluid models have become out of sync with the master fluid model (or data set). If so, a warning to a user or users may be given to indicate the fluid models used in previous simulations are antiquated, and in some instances, antiquated simulations may be updated to reflect the changes made to the master fluid model.

[0074] In some embodiments, a user may compare (QC) or update all or a partial list of fluid models derived from a master fluid model. If the changes are insufficient, as determined by a QC process, to warrant a new fluid model then a user may re-sync those fluids without changing the fluid model. However, if the additional data warrants new fluid models then new fluid models may be created and compared in a simulation application and a syncing process may be initiated.

[0075] Embodiments of the invention may therefore provide a system for facilitating the relationships between different versions of a fluid by automatically detecting whenever a dependent model, e.g., a simulation model that has been generated based upon a fluid model or a derivation of that fluid model, has become antiquated. Consider for example the following workflow:

[0076] Initially experimental data from a formation tester (downhole fluid analyzer) is obtained, containing preliminary results of the fluid (composition, PVT and viscosity). This data may be a reduced set of the data that may be obtained from a PVT laboratory report, and may be used to generate a preliminary reservoir simulation model containing an Equation of State and viscosity model representation of the fluid. The model may be generated from the compositional information and then tuned to the available PVT and viscosity data, and may be used in preliminary reservoir simulations and in determining if more downhole fluid analyzer (DFA) stations are required.

[0077] Thereafter, a physical fluid sample may be collected from the reservoir (bottomhole, wellhead, and separator) and sent to a PVT laboratory for a

comprehensive suite of experiments used to characterize the fluid. This data may then be used to update the fluid model derived from the formation tester data set. Similar to the process described above, a model for reservoir simulation may be generated from the experimental data, and due to the fidelity of the data obtained from the PVT lab, the overall fluid model may be updated and may be considered to be more representative compared to the model generated from the DFA data set. In this process, the reservoir simulation fluid model has changed and the reservoir simulations generated from the preliminary data set have become antiquated. It is therefore desirable for the reservoir simulation, and thus the reservoir model generated therefrom, to be updated with the new fluid model.

[0078] In embodiments consistent with the invention, version data may be maintained for each of these models, and thus, the fact that a reservoir simulation was run with an antiquated fluid model may be detected and a user may be notified.

Further, in some embodiments, the reservoir simulation may be automatically re-run with the new fluid model. In addition, in some embodiments, the reservoir fluid model may be automatically updated based on some heuristics (lumping, tuning) determined by a user's organization. In some embodiments therefore, a fluid model is always up to date and notifications may be sent out to the owners and/or users of the reservoir simulations to indicate an updated fluid is available to update the reservoir simulations. Further, throughout the course of the creation of models, as new fluid data comes in, the respective simulations may accurately reflect the latest data, and may be

automatically updated.

[0079] In some embodiments, each of the fluids and experimental data sets for a given collection of assets may be contained in a fluid modelling project. A similar process may be followed when any simulation fluid (network, facilities, etc.) has been derived from an experimental data set. Any update to an experimental data set may result in automatically updating any child (dependent) simulation model fluids. This process may also be irrespective of the nature of the derived fluid models

(compositional, black oil, black oil tables, property tables, etc.).

[0080]As noted above, each fluid model, as well as each other simulation model, may be associated with version data that provides information used to identify what fluid models were used for various simulations. Version data may therefore include information such as unique identifiers, time stamps, update histories, lumping schemes, tuning approaches, etc., such that essentially an "audit trail" is accessible for a particular project. In addition, in some embodiments, the version data may be used to compare fluids or fluid models with each other to ensure consistency between reservoir, network, facility and other simulations. Version data may also be attached to data sets in some embodiments, such that the particular data used in the generation of a fluid model may be ascertained.

[0081] In some embodiments, a determination of which simulation model(s) need to be updated may be based on an experimental data classification. For example additional data based on experimental flow assurance (e.g., wax, asphaltene, scale, hydrate, etc.) may only be relevant to network models rather than facilities models.

Similarly, enhanced oil recovery experiments may not be relevant to facility models. As such, version data may also include information on the experiment(s) from which a data set and/or model was derived.

[0082] A fluid model audit trail may also be used to facilitate accurate lumping and/or de-lumping of components. Simulation fluid models may be lumped differently for various sectors or simulations in asset modelling studies. An audit trail may therefore ensure that when simulation model fluids are de-lumped (and potentially re-lumped), the pseudo components are de-lumped back to their original components rather than another set of pseudo components. Doing so may ensure all fluid simulation models are tied back to the original experimental component set. [0083]As shown in Fig. 6, for example, an original fluid model 430 may be related to a dependent reservoir simulation fluid 432 used in a reservoir simulation, with lumping used to derive the reservoir simulation fluid 432 from the original fluid model 430. Upon an update to the original fluid model, as illustrated at 434, dependent reservoir simulation fluid 432 may be determined to be antiquated, and a user and/or owner may be notified of the updated fluid model 434. Either manually by the user or owner, or automatically, an updated reservoir simulation fluid 436 may be generated from the updated fluid model 434, with the same lumping performed based upon the version information to ensure that the same pseudo components are reflected in the updated reservoir simulation fluid 436.

[0084] Fig. 7 next illustrates an example open project routine 500 that may be executed, for example, by a simulation application or platform in response to a user request to open a project, e.g., by a synchronization module 420 (Fig. 5). In block 502, the project files are loaded, and in block 504, a FOR loop is initiated to evaluate each dependent model in the project, i.e., to evaluate each model in the project that is dependent on another, "parent" fluid model or data set. For each such model, block 504 passes control to block 506 to assess version data for one or both of the dependent and parent models, which may include accessing version data for a fluid or fluid model used by the dependent model, as well as version data for any data set used to generate a dependent or parent fluid model. Block 508 then determines from the assessment whether the dependent model is antiquated, and if not, returns control to block 504 to process any additional dependent models.

[0085] If not, however, block 508 passes control to block 510 to determine whether auto-update is desired. In some embodiments, for example, a system setting may determine whether or not a dependent model should be automatically updated, while in other embodiments, whether or not a dependent model should be automatically updated may be based upon factors such as whether or not the dependent model can be automatically updated based upon the available data. If so, block 510 passes control to block 512 to re-run the simulation for the dependent model based upon the updated data and thereby update the simulation model. Block 512 may also incorporate re-generating a fluid or fluid model used by the simulation model from the updated "master" or parent fluid model. Control then returns to block 504 to process additional dependent models.

[0086] Returning to block 510, if auto-update is not enabled, control passes to block 514 to mark the dependent model as needing an update, and control returns to block 504 to process additional dependent models.

[0087] Once each dependent model has been processed, block 504 passes control to block 516 to notify the user and/or any others or owners of the project of any model updates and/or model(s) needing updates, and routine 500 is complete. Thus, a user may be notified after a model has been updated, or a user may be notified, in the event no auto-update is performed, that a model requires a manual update. In some embodiments, no notification may be made to the user. Notifications may be made in various manners, e.g., via a dialog box, an electronic message, etc.

[0088] It will be appreciated that when any new model is generated or any new data set is received, appropriate version data may be generated and stored to properly identify and distinguish the model/data set. Version data may in some embodiments be attached to the data/model itself, or may be maintained in a separate version database.

[0089]Various modifications may be made in other embodiments. For example, assessment of version data may be performed in other scenarios, e.g., in response to a manual check initiated by a user, whenever a dependent model is loaded (rather than an entire project), or in other scenarios. Moreover, in some embodiments, version data may be maintained for other types of model dependencies where models used by different simulation applications are dependent on models and/or data sets maintained by other simulation applications. Some embodiments therefore enable a model used by one simulation application to be automatically updated, or a user of such simulation application to be notified, whenever a model or data set used by another simulation application is updated. Dynamic Fluid Model Tuning

[0090] Fluid simulators or simulation applications, which may also be referred to as PVT (Pressure Volume Temperature) software, may be used in the oil and gas industry to help understand the properties of fluids encountered within a reservoir as well as at various points in a production system. Fluid simulators generally enable a user to create a simulation model of a fluid that accurately predicts real life fluid behavior, and the accuracy of such a model is generally based upon how closely the model matches experimental data collected on a sample of the fluid.

[0091]A regression operation, which may be referred to as "tuning", may be performed to optimize a fluid model to better match collected experimental data. Fluid simulators may support a number of tunable parameters, or properties; however, the selection of which properties to tune may be a challenge in some instances. Some properties may have a large positive effect, while others may not have much of an effect at all, if tuned individually. Further, when tuning multiple properties together, the combined effects may be harder to predict and may necessitate a substantial amount of trial and error by users. This trial and error process may further be complicated by the need to select one or more properties, run a regression, parse the data, and rerun the regression if a different result is desired.

[0092] Some fluid simulators may provide complex statistical information to a user after running a regression, e.g., the sensitivities of the different properties to each of potentially hundreds of experimental data points, as well the correlation, covariance and hessian between properties. Such data is generally provided after running a regression, so the overall process may time consuming due to the need to iterate between running a regression, analyzing the statistical information, and selecting different combinations of properties, and may require a high level of expertise in order to properly analyze the statistical information and determine how to improve the tuning.

[0093] Embodiments consistent with the invention, on the other hand may support dynamic fluid model tuning to provide users with real-time (or near real-time) information or feedback when selecting properties or combinations of properties, thereby enabling users to more rapidly identify optimal properties or combinations of properties upon which to optimize or tune a fluid model. Further, in some embodiments, when a user chooses multiple properties to tune, the user may be provided with not only expected tuning results reflective of how much the selected properties are expected to improve the fluid model's match with experimental data (e.g., as defined by a chosen objective function), but also expected tuning results reflective of how much various combinations of those selected properties are expected to improve the fluid model's match with the experimental data. Further, in some embodiments, parallelization in a computer system may be leveraged to accelerate a display of expected tuning results, as one or more different threads or processes may be used to run regressions based upon various combinations of selected properties and provide feedback as to how the various combinations will affect a fluid model's match with the experimental data.

[0094] In some embodiments, rather than providing statistical feedback for a set of properties such as sensitivity, covariance, and correlation, which may be difficult for some users to interpret, an objective function is defined to enable provide the user with a metric related to the actual improvement the selected properties will provide. This may be easier and quicker for a user to understand and may facilitate the user making better decisions more quickly.

[0095] Furthermore, in some embodiments feedback is provided dynamically when a user selects and/or unselects different properties to enable a user to quickly change the selected properties and experiment with what the expected tuning results of different possible solutions might be.

[0096] In one embodiment, for example, during the tuning of a fluid model, a user may first specify an objective function. The objective function itself may be a measure of how far the simulation model of the fluid is from the experimental data. In some instances, the objective function may be refined by the user to add additional weight (importance) to specific factors, or exclude factors altogether, resulting in a weighted objective function. The initial objective function against which potential tunings are compared is the objective function before any tuning takes place, and the initial objective function may include an initial value of the objective function associated with the fluid model without any tuning being performed.

[0097] Next, the user may choose what property or properties to tune. For a simulation model of a fluid, many choices may be presented, including properties such as properties of the components defined by the equation of state (e.g., Critical Pressure and Critical Temperature), interaction coefficients between components, variables in a viscosity model, etc. Each of these properties may have a substantial impact on how a simulation model behaves. Furthermore, many of these properties have correlation effects with each other, so the specific combination of properties selected to tune may have a significant effect on the overall improvement to the objective function.

[0098] Fig. 8, for example, illustrates an example user interface 530, illustrating in a list box control 532 a list of checkboxes 534a-d representing different selectable properties capable of being tuned via a regression or optimization, e.g., a critical pressure of component 1 property (PCritl ), a critical temperature of component 1 property (TCritl ), a critical pressure of component 2 property (PCrit2), and a critical temperature of component 2 property (TCrit2). A bar graph 536 is also displayed in real-time comparing the initial objective function (prior to any tuning, and represented by bar 538) with the value of the objective function after tuning each of the selected properties (represented by bars 540), as well as after tuning each possible combination of the selected properties (represented by bars 542). As illustrated in Fig. 8, for example, once a user has selected properties PCritl , TCritl and PCrit2 via checkboxes 534a-c, three bars 540 are displayed corresponding respectively to properties PCritl , TCritl and PCrit2, and four bars 542 are displayed corresponding respectively to the combination of PCritl and TCritl , PCritl and PCrit2, TCritl and PCrit2, and PCritl , TCritl and PCrit2.

[0099] In this embodiment, as the user selects different properties, a regression or optimization may be initiated for the currently selected property or properties, e.g., in one or more background threads or processes, with the expected tuning results presented to the user via a user interface in real-time or near real-time, indicating to the user how much the selected property or properties, and all possible combinations thereof, alter the objective function. Specifically, the objective function is calculated for each regression and displayed, with the initial objective function also displayed for comparison.

[00100] The respective objective function results may provide a user with a good understanding of how effective tuning different properties is going to be. In the example illustrated in Fig. 8, for example, it may be seen that, on its own, PCrit2 is the best individual property for tuning (as it lowers the objective function the most relative to the initial objective function, and thus results in the best match to the experimental data). However, a better solution results by tuning both PCritl and TCritl , as the objective function is even lower, indicating an even better match to the experimental data. As such, a user is better able to see the correlation and sensitivity effect of the properties, and doing so in a more direct manner.

[00101] It will be appreciated that different combinations of user interface controls may be used to select properties in different embodiments, and that dynamic updates to the objective function may be made in some embodiments in response to any change in the selected properties, or only in response to a confirmation by a user after one or more changes are made to the selected properties (e.g., by pressing a dedicated button after changing the selections). It will also be appreciated that other visualizations may be used as an alternative to bar graph 536, including other graphical visualizations as well as non-graphical visualizations displaying the

properties/combinations and their resulting objective functions. In addition, sorting may be performed to list or rank properties/combinations based upon their resulting objective functions, and highlighting may be used in some embodiments, e.g., to direct a user's focus to the properties/combinations with the lowest objective functions.

[00102] Fig. 9 next illustrates a tune fluid model routine 600 that may be executed by a simulation application or platform such as platform 400 of Fig. 5.

Functionality for implementing at least portions of this routine may be implemented in some embodiments within a tuning module 422 of fluid simulator 402, although the invention is not so limited. Routine 600 may be executed, for example, in response to a user selection of a control on a graphical display associated with tuning a model.

Routine 600 begins in block 602 by querying the user for an objective function and receiving a user selection of the objective function to be used to quantify the expected results of tuning various properties. Block 602 may present the user with a user interface enabling the user to select various factors and/or various weights to apply to different factors, thereby defining the metric against which various tunings will be compared. In some embodiments, one or more predetermined objective functions may be defined, enabling a user to select from among the predetermined objective functions.

[00103] Next, block 604 displays a user interface with one or more controls associated with a plurality of selectable and tunable properties, e.g., as shown in Fig. 8, and block 606 awaits user input. One type of input that may be received is the selection of one or more of the selectable properties. Thus, in response to receiving user input, control passes to block 608, which determines whether the user input has changed the set of selected properties. If so, control passes to block 610 to notify a background process 612 of the current property selection, and then to return control to block 606 to await further input from a user.

[00104] Background process 612, which may instead be implemented in a separate thread in some embodiments, may executed on the same computer as routine 600, e.g., on the same or different processor or processor core, or may execute on a different computer in communication with the computer upon which routine 600 is running, e.g., in a client-server or cloud-based environment. Within this process, a regression or optimization is performed for each selected property and for each possible combination when multiple properties are selected. In some embodiments, however, regressions may only be performed for subsets of combinations of properties, and in some embodiments, no regressions may be performed for any combinations.

[00105] Along with performing the regressions or optimizations, process 612 also calculates the value of the objective function for each property/combination, as well as updates the user interface to display the value of the objective function for each selected property/combination, e.g., as shown in Fig. 8. In some embodiments, update of the user display may not be performed by process 612, and may instead be performed by a different process/computer (e.g., the process/computer running routine 600), whereby process 612 may only return regression results and/or objective function values for use in updating the user interface.

[00106] In addition, in some embodiments process 612 may incorporate result caching to reduce the overhead of running regressions, e.g., to eliminate the need to rerun a regression that has already been run. Thus, block 614 may analyze the current property selection provided from block 610 of routine 600 to identify any properties and/or combinations of properties for which regression results have not been cached. If a regression has not been performed for any such properties/combinations, block 614 passes control to block 616 to run a background regression or optimization for any property and/or combination of properties lacking cached results.

[00107] Block 616 may, in some instances, run multiple regressions in parallel in multiple processes, threads, processors and/or computers to leverage parallelization and thereby reduce latency. Furthermore, while in some embodiments full regressions may be performed, in other embodiments a simplified regression or optimization, referred to herein as a fast regression, may be performed to further reduce latency. It will be appreciated that development of a full or simplified regression or optimization algorithm for tuning one or more tunable properties of a fluid model would be well within the abilities of one of ordinary skill in the art having the benefit of the instant disclosure.

[00108] After running the regression or regressions in block 616, block 618 caches the results thereof, and passes control to block 620 to retrieve these cached results, along with any other cached results generated as a result of prior property selections. Block 622 then updates the user interface to display the results, and process 612 is finished with handling the updated property selection. In addition, returning to block 614, if all results for a current property selection are already cached, block 614 passes control directly to block 620, thereby bypassing blocks 616 and 618. [00109] Returning to block 606, another type of user input that may be received via the user interface is the selection of a particular property or combination of properties with which to tune the fluid model. Such input may be generated, for example, when a user has found, based upon the selection of various properties, a property or combination of properties that is suitable for tuning the fluid model and thereby improving the match of the fluid model to the experimental data. The user input may include, for example, selection of one of the bars in a bar graph (e.g., as shown in Fig. 8), coupled with selection of a button that is associated with performing a full optimization or regression of the fluid model based upon which bar in the bar graph is selected, although other controls and/or combinations of controls may be used in other embodiments.

[00110] Thus, returning to block 608, if user input received from block 606 does not change the property selection, control passes to block 624 to determine if the user input selects a particular property/combination to tune the fluid model. If not, control passes to block 626 to handle the user input as appropriate, before returning control to block 606 to await further input. If, however, the user input does select a particular property/combination to tune, block 624 passes control to block 628 to run a full regression or optimization on the selected property/combination of properties and save the results, thereby tuning the fluid model. Routine 600 may then be complete. It will be appreciated that in some embodiments, e.g., where full optimizations are performed by background process 612, block 628 may retrieve previously-cached results rather than running a full optimization.

[00111] Dynamic fluid model tuning may be implemented differently in other embodiments. For example, in some embodiments, rather than user selection of specific properties, a user may instead be presented with different end use fluid types (e.g., the simulators with which a fluid model may be used, such as a reservoir simulator, a flow assurance simulator, a surface network simulator, or a facilities simulator), and a tuning module may characterize/tune a fluid model based only on the selected end use fluid type, e.g., based on heuristics such as which parameters, range of parameters, weights of experiments, etc. In such embodiments, the tuning module may analyze all the possible variations and report the optimal variation to the user.

Flash Grid Calculation and Visualization

[00112] Fluid simulators or simulation applications, which may also be referred to as PVT (Pressure Volume Temperature) software, may be used in the oil and gas industry to help understand the properties of fluids encountered within a reservoir as well as at various points in a production system. Fluid simulators generally enable a user to create a simulation model of a fluid that accurately predicts real life fluid behavior, and the accuracy of such a model is generally based upon how closely the model matches experimental data collected on a sample of the fluid.

[00113] Properties of a fluid that may be used in some applications include phase behavior (e.g., how much gas is dissolved in oil or how much oil is vaporized in gas) and how it changes with pressure and temperature, phase densities, phase enthalpies, phase viscosities, etc. As a result, some fluid simulators incorporate flash and phase envelope functionality. A flash generally refers to a simulation of fluid properties at specific conditions, e.g., at a given pressure and temperature point. A phase envelope, at its simplest, is a pressure-temperature plot with a line outlining the two phase region where both oil and gas are present. Some fluid simulators can also plot quality lines, which can be thought of as contour lines, where the contour represents the quality, i.e., the fraction of gas in the two phase region.

[00114] Due to the difficulty and computational resources needed to generate the data for a phase envelope, conventional phase envelopes are generally created by detecting a location of a phase change and then tracing along a line. Fig. 10, for example, illustrates a phase envelope 630 upon which a line 632 representing a location of a phase change.

[00115] Embodiments consistent with the invention, on the other hand, may employ a "flash grid," or a grid of flashes, to generate the properties of a fluid, e.g., for use in generating and displaying a phase envelope, as well as in generating and displaying other properties and/or visualizations of properties of a fluid. In some embodiments, for example, the algorithm is simpler to implement, is subjected to fewer challenges when simulating complicated fluids, and allows for a wide variety of fluid properties to be calculated and/or visualized, e.g. , properties such as vapor mole fraction, vapor mass fraction, vapor volume fraction, density, volume, enthalpy, viscosity, etc.

[00116] Further, fluid properties may be visualized in a number of different manners in different embodiments. For example, in some embodiments, if a two dimensional (2D) flash grid is used, results may be plotted as a three dimensional (3D) surface, or with colors representing the values. In other embodiments, a 3D flash grid may be used. Colors may also be used with a 3D flash grid, and results may be viewed as a solid object that can be navigated through, or as a video, where time represents one of the grid dimensions.

[00117] In embodiments consistent with the invention, instead of following a line, fluid properties are calculated by performing numerous flashes on an n-dimensional grid, and storing the results. Any property resulting from the flashes may then be displayed, with colors representing values, or in other manners that will be appreciated by those of ordinary skill in the art. Thus, for example, in some respects, a 2D flash grid may be considered to be somewhat analogous to a computer display, where lines are actually made up of colored pixels.

[00118] More generally, therefore, it will be appreciated that embodiments consistent with the invention may implement a flash grid by performing flash

calculations to calculate one or more fluid properties at a plurality of values of each of a plurality of conditions. An n-dimensional flash grid may therefore be considered to have a set of n coordinates, with each of the n coordinates corresponding to a condition ci ... Cn. Furthermore, for each condition a, a corresponding range n may be defined, with the range n partitioned into a set of rrn values.

[00119] In some embodiments, for example, properties of a fluid may be determined by, for each of a plurality of conditions over which to generate a flash grid, determining a range corresponding to the condition; for each determined range, determining a plurality of values of the corresponding condition and distributed within the range; for each combination of determined values within the determined ranges of the plurality of conditions, performing a flash calculation to calculate one or more fluid properties of the fluid; and displaying a visualization based upon the flash calculations. Furthermore, in some embodiments, the determined ranges may each be contiguous, such that properties are calculated substantially throughout an n-dimensional space.

[00120] Thus, for example, to create a two-dimensional flash grid where the conditions are temperature and pressure, a range of temperature from 0 to 750 Kelvin, and a range of pressure from 0 to 40,000 psia, 100 values of each coordinate may be selected to define a 100 x 100 flash grid, such that adjacent coordinates would be separated by steps of 7.5 Kelvin and 400 psia.

[00121] It will be appreciated that if the property chosen to calculate and display is vapor mole fraction, and the conditions forming the coordinates of the flash grid are temperature and pressure, then the plot provides essentially the same information as a conventional phase envelope. Fig. 1 1 , for example, illustrates an example visualization 640 of essentially the same information in phase envelope 630 of Fig. 10, but with colored or shaded regions 642 representing different vapor mole fractions at different combinations of pressure and temperature.

[00122] Other flash grid calculations and visualizations are contemplated, including, for example, 2D grids such as pressure vs. enthalpy, temperature vs.

enthalpy, etc., as well as 3D grids.

[00123] Embodiments consistent with the invention may provide a number of advantages over conventional phase envelope algorithms. Generating fluid properties via a flash grid may be based upon a simpler algorithm, as following a line, as is generally performed with conventional phase envelope algorithms, can be tricky if the line is discontinuous or has loops. In additional, a flash grid may not be restricted to displaying a single property. Further, in some embodiments, a flash grid may be used to display data in three or more dimensions. Thus, for example, two axes of a flash grid may be used for the traditional axes, pressure and temperature. The third axis may be used, for example, to show the effects of mixing two fluids: e.g. the axis may be the fraction of the first fluid in the mixture. So when the fraction is one, the plot may show the property of the first fluid, and when the fraction is zero the plot may show the property of the second fluid. The user may use such a flash grid to identify the properties of various mixtures by changing the fraction.

[00124] It will be appreciated that the generation of a flash grid may require many flashes to be performed, and that, for high resolution, a fine grid may be required and therefore more flashes may be calculated. In some embodiments, a large number of flashes may take a substantial amount of time and/or computing resources; however, once calculated, many fluid properties can be examined without further calculation. Furthermore, in some embodiments flash grids may leverage computer parallelization to accelerate the calculation of properties throughout the ranges of conditions, by essentially performing calculations for different coordinates in parallel using different threads, processes, processors, processor cores, computers, nodes, etc.

[00125] Fig. 12, for example, illustrates an example generate flash grid routine 700 that may be executed by a simulation application or platform such as platform 400 of Fig. 5. Functionality for implementing at least portions of this routine may be implemented in some embodiments within a flash grid module 424 of fluid simulator 402, although the invention is not so limited. Routine 700 may be executed, for example, in response to a user selection of a control on a graphical display associated with generating a flash grid. It will be appreciated that a user interface may be presented to a user to configure the flash grid, e.g., by selecting which fluid properties to calculate, which conditions to use to define the coordinates of the grid, the range of each condition over which to calculate the fluid properties, and the resolution of each coordinate of the grid (i.e., the number of data points over which to represent the range of the condition corresponding to that coordinate). A user may also be able to define one or more settings of the resulting visualization, e.g., what properties to display and how those properties should be represented in the visualization. [00126] Routine 700 begins in block 702 by generating an n-dimensional array for storing one or more fluid properties generated for a particular fluid, over selected ranges of n conditions. Block 704 then determines a path through the array. In some embodiments, for example, the path may be sequential, while in other embodiments, other paths may be used, e.g., to leave some array elements empty such that interpolation may be used to calculate those elements based upon flash calculations performed for their neighboring elements, or to partition the array elements into different groupings for calculation in parallel.

[00127] Block 706 next sequences through each element of the array according to the determined path, and for each such element, passes control to block 708 to determine whether sufficient nearby results are available to use interpolation.

Interpolation may be desirable in some embodiments to reduce the number of flash calculations performed.

[00128] If not, block 708 passes control to block 710 to perform a flash calculation for the element, based upon the conditions represented by the coordinates of the element, and store the results (i.e., one or more calculated fluid properties) in the element. Control then returns to block 706 to process other elements.

[00129] Returning to block 708, if sufficient neighboring results are available to perform interpolation, control is instead passed to block 712 to interpolate the fluid property or properties based upon the fluid properties calculated for one or more neighboring elements. Control then returns to block 706 to process other elements.

[00130] Once all elements have been processed, block 706 passes control to block 714 to generate and display a visualization of the flash grid to the user, e.g., based upon one or more selected properties stored in each of the array elements.

Routine 700 is then complete.

[00131] It will be appreciated that in some embodiments, no interpolation may be used. Further, in some embodiments, parallelization techniques may be used to partition the workload associated with performing the flash calculations among multiple threads, processes, processor cores, processors, computers, etc.

[00132] Embodiments consistent with the invention may also support interactive visualizations. For example, as illustrated by zoom in on flash grid routine 720 in Fig. 13, it may be desirable in some embodiments to enable a user to zoom in and out of a flash grid visualization, and in some embodiments, dynamically perform additional flash calculations as needed. Routine 720 may be executed, for example, in response to a user selecting a zoom button or selecting a region of a visualization, and may begin in block 722 by pre-populating a new visualization with existing data from the flash grid. For example for a 2X zoom, a new array may be created based upon the original flash grid visualization, but with every other element populated with data from the original visualization. Interpolation may then be performed in block 724 to fill in the remaining elements with interpolated data. Block 726 may then initiate flash calculations on the interpolated visualization locations, e.g., in a background process, such that the visualization may be updated in block 728 with the flash calculation results, thereby completing routine 720. Blocks 726 and 728 may, in some embodiments, operate in a parallel and piecemeal fashion such that as results are obtained for particular elements, the visualization is dynamically updated for those elements, until eventually all interpolated elements are replaced with flash calculation results.

[00133] It may also be desirable in some embodiments to support the export of fluid properties to external applications, and to do so interactively. For example, as illustrated by export operating envelope routine 740 of Fig. 14, it may be desirable in some embodiments to enable a user to select an operating envelope from a

visualization (block 742), e.g., by drawing a rectangular frame corresponding to particular subsets of ranges of the conditions depicted in a visualization. Once an operating envelope is selected, the corresponding fluid properties within that envelope may be extracted from the corresponding region of the array (block 744) and exported to the external application (block 746). In one embodiment, for example, if it is known that a fluid will be conveyed through a surface network that will maintain the fluid within a particular ranges of temperature and pressure, the operating envelope corresponding to those ranges may be selected in a visualization, and the corresponding fluid properties may be extracted and exported to a pipeline simulator for use in simulating a production network.

[00134] It will also be appreciated that in some embodiments, the exported data may be output in various data file formats, suitable for the appropriate end uses, and may be used in various end uses that may use interpolation and extrapolation, as appropriate.

Fluid Comparison

[00135] Fluid simulators or simulation applications, which may also be referred to as PVT (Pressure Volume Temperature) software, may be used in the oil and gas industry to help understand the properties of fluids encountered within a reservoir as well as at various points in a production system. Fluid simulators generally enable a user to create a simulation model of a fluid that accurately predicts real life fluid behavior. It has been found that in use, it may be desirable to create different versions of a fluid, e.g., with different levels of fidelity, based on factors such as how performant a simulation of the fluid is expected to be. As part of this work, a user may go through different processes to manipulate an initial model, performing tasks such as splitting and lumping the components of the fluids, or tuning properties of those components to experimental data.

[00136] An issue users may encounter with fluid simulators is the difficulty in managing different "versions" of a fluid, as many fluid simulators only understand the concept of a "current" fluid. When a user performs an operation on a fluid in a fluid simulator, the prior version of the fluid is generally overridden. In order to keep different versions, a user may have to save their project to different files. Doing so, however, complicates any comparison of the different versions of the fluid, and even if different versions of a fluid are capable of being stored in a same project, no user interface is supported to facilitate any fluid comparisons. [00137] Embodiments consistent with the invention, on the other hand, provide a user interface within a simulation platform, e.g., within a fluid simulation application, that supports comparing different fluids, including different versions of a fluid. Different versions may include fluids or fluid models that differ based upon being direct characterizations, lumpings, tunings, etc. In some embodiments, a user is provided with an ability to manage all of the versions of one or more fluids, as well as an ability to plot, grid, and/or perform other quality control operations to be able to compare the validity for each associated fluid model. In addition, in some embodiments, users may compare the same fluid using different flash packages, with automated functionality for converting between the different flash packages.

[00138] In some embodiments, for example, as a user creates different versions of a fluid by performing various operations supported by a fluid simulator (e.g., lumping, de-lumping, tuning, varying properties, etc.), a simulation platform may retain an understanding of the different versions through stored version data associated with each version. Then, through a user interface, the different versions may be presented to the user to enable the user to compare multiple fluids in plots and tables at any time.

[00139] Lumping, for example, may include generating pseudo components that model multiple components of a fluid to simplify a fluid model and decrease the amount of computational resources needed to run a simulation, e.g., to speed up performance of a fluid simulator. Tuning may include running optimizations or regressions to better match a model with experimental data collected for a fluid.

[00140] As noted above, each fluid or fluid model may be associated with version data that identifies or distinguishes different versions of a fluid. Version data may include information such as unique identifiers, time stamps, update histories, lumping schemes, tuning approaches, etc., such that essentially an "audit trail" is accessible for a particular fluid. Version data also may be attached to data sets in some

embodiments, such that the particular data used in the generation of a fluid model may be ascertained, and in some embodiments, the version data may be stored with each fluid or fluid model, while in other embodiments, the version data may be maintained in a separate database.

[00141] Fig. 15 illustrates an example user interface 750, illustrating in a hierarchical tree 752 various versions of a fluid. In this example, a user has created an initial fluid model represented at 754a, and different versions represented at 754b-g distinguished by different lumpings (e.g., the versions represented at 754b and 754f), different tunings (e.g., the versions represented at 754c-754e) and different flash packages (e.g., the versions represented at 754a and 754g). It will be appreciated that different hierarchical arrangements may be used in other embodiments, as may different user interface controls.

[00142] By selecting different representations 754a-754g, a user may compare the original model to various derived and changed models, all from within the same user interface. Thus, as shown in Fig. 15, by selecting representations 754a, 754c and 754g, a user may compare the different versions, e.g., using a plot 756 of particular properties of each version of the fluid, represented by corresponding lines 758a, 758c and 758g. As such, in some embodiments a user may see not only every version of a fluid, but understand what the differences are between the various versions of the fluid.

[00143] It will be appreciated that different data visualizations may be performed in different embodiments, and may be selected by a user. For example, different types of charts, tables, graphs, and plots of various properties of each fluid may be generated and displayed, as may other types of visualizations such as phase envelopes, etc.

Visualizations may be two dimensional or three dimensional, and visualizations may be overlapping for different versions or may be displayed adjacent to one another. Various fluid properties may be displayed, including both input properties to a fluid model and output properties generated in response to input properties, e.g., fluid components, density, molality, etc.

[00144] In some embodiments, a fluid comparison user interface may also be dynamically updated in response to changes applied to versions of a fluid, e.g., where one version of a fluid is changed by a user while a visualization of that version is being displayed. In addition, in some embodiments, a user may be allowed to make changes to a version of a fluid and either create a new version based on the changes or overwrite the version to which the changes were made.

[00145] Figs. 16-18 next illustrate a number of routines that may be executed by a simulation application or platform such as platform 400 of Fig. 5. Functionality for implementing at lease portions of such routines may be implemented in some embodiments within a fluid comparison module 426 of fluid simulator 402, although the invention is not so limited.

[00146] Fig. 16 illustrates an open comparison Ul (user interface) routine 800 that may be executed, for example, in response to a user selection of a control on a graphical display. Routine 800 begins in block 802 by building an displaying a tree of fluids in the current project, with nodes of the tree representing different versions of each fluid in the project (e.g., as shown in Fig. 15). Checkboxes or other controls may also be displayed in the tree to enable a user to select or de-select individual versions or groups of versions, and as such, block 804 determines whether user input has been received that changes the collection of fluid versions that are selected by the user.

[00147] If so, control passes to block 806 to generate or re-generate a visualization that compares the currently selected version(s), and then to block 808 to display the visualization to the user. Control then returns to block 804 to await further user input.

[00148] If no user input is received to change the selected versions, block 804 passes control to block 810 to determine if user input has been received that changes the visualization. If not, control returns to block 804 to continue waiting on user input.

[00149] If so, however, block 810 passes control to block 812 to generate a new visualization with the currently selected version(s). It will be appreciated that when the user interface is first opened, a default visualization may be displayed, or the last visualization selected by the user may be displayed. As noted above, various visualizations, such as charts, tables, graphs, and plots of various properties of a fluid may be generated, and as such, a user may be permitted to change the type of visualization displayed, the scale of the visualization, the property or properties being depicted, or practically any other variable that may affect how and what data may be displayed to a user. Control then passes to block 808 to display the new visualization to the user, and control then returns to block 804 to wait for additional user input.

[00150] As noted above, a fluid comparison user interface may be dynamically updatable in response to user modifications to fluids or fluid models. For example, as illustrated by fluid changed routine 820 of Fig. 17, in response to a change made to a fluid, e.g., a change in properties, a change due to lumping or tuning, etc., block 822 may be executed to update the fluid model as necessary (e.g., by re-running a simulation). Block 824 then updates the visualization displayed to the user, and routine 820 is complete.

[00151] In addition, as illustrated by save changes routine 830 of Fig. 18, it may be desirable in some embodiments to maintain version data for each version of a fluid in response to changes made to that fluid. Routine 830 may be called, for example, in response to a user's selection of a control to save a fluid, or may be called automatically in response to changes made to the fluid by the user. Routine 830 begins in block 832 by determining whether the changes should be saved as a new version, or whether the changes should be incorporated into the same version, thus overwriting the current version. The determination may be made, for example, based upon a user setting, or based upon a query to the user.

[00152] If the changes are to be saved as a new version, control passes to block 834 to save the fluid as a new version, and then to block 836 to store version data associated with the new version of the fluid. If the changes are to be incorporated into the current version, block 832 instead passes control to block 838 to overwrite the current version of the fluid, and then to block 836 to store version data for the updated current version of the fluid. Upon completion of block 836, routine 830 terminates.

[00153] Although the preceding description has been described herein with reference to particular means, materials, and embodiments, it is not intended to be limited to the particular disclosed herein. By way of further example, embodiments may be utilized in conjunction with a handheld system (i.e., a phone, wrist or forearm mounted computer, tablet, or other handheld device), portable system (i.e., a laptop or portable computing system), a fixed computing system (i.e., a desktop, server, cluster, or high performance computing system), or across a network (i.e., a cloud-based system). As such, embodiments extend to all functionally equivalent structures, methods, uses, program products, and compositions as are within the scope of the appended claims. In addition, while particular embodiments have been described, it is not intended that the invention be limited thereto, as it is intended that the invention be as broad in scope as the art will allow and that the specification be read likewise. It will therefore be appreciated by those skilled in the art that yet other modifications could be made without deviating from its spirit and scope as claimed.

Claims

What is claimed is:

1 . A method of managing model dependencies, comprising:

maintaining version data for a model or data set used by a first simulation application;

maintaining version data for a dependent model used by a second simulation application and based upon the model or data set used by the first simulation application;

updating the model or data set used by the first simulation application, including updating the version data therefor; and

after updating the model or data set used by the first simulation application, determining whether the dependent model is antiquated based upon the version data maintained for the dependent model and the version data for the updated model or data set used by the first simulation application.

2. The method of claim 1 , further comprising notifying at least one user in response to determining that the dependent model is antiquated.

3. The method of claim 1 , further comprising automatically updating the dependent model in response to determining that the dependent model is antiquated.

4. The method of claim 1 , wherein the first simulation application is a fluid simulator, wherein the model or data set used by the first simulation application is a first fluid model, and wherein the method further comprises automatically updating a second fluid model used by the dependent model in response to determining that the dependent model is antiquated.

5. The method of claim 4, further comprising automatically running a simulation in the second simulation application using the dependent model and the automatically updated second fluid model used by the dependent model in response to determining that the dependent model is antiquated.

6. The method of claim 4, wherein automatically updating the second fluid model used by the dependent model includes generating the automatically updated second fluid model by performing a tuning or lumping operation on the first fluid model.

7. The method of claim 6, wherein generating the automatically updated second fluid model further includes determining the tuning or lumping operation to be performed by accessing version data for the second fluid model.

8. The method of claim 1 , wherein the first simulation application is a fluid simulator, wherein the model or data set used by the first simulation application is a fluid model, wherein a first version of the fluid model is generated from preliminary data collected from a downhole fluid analyzer, and wherein updating the model or data set used by the first simulation application includes generating a second version of the fluid model from data generated from analysis of a physical fluid sample.

9. The method of claim 1 , wherein the first simulation application is a fluid simulator, wherein the model or data set used by the first simulation application is a first fluid model, wherein the dependent model is among a plurality of coupled dependent models including a reservoir simulation model, a surface network simulation model and a facilities fluid model, and wherein each of the plurality of dependent models uses a different fluid model derived from the first fluid model.

10. The method of claim 1 , wherein the version data includes a unique identifier, a time stamp, an update history, a lumping scheme, a tuning approach, an experiment from which a data set is derived, or an experiment from which a model is derived.

1 1 . The method of claim 1 , wherein the version data for the dependent model is attached to the dependent model or maintained in a version database.

12. The method of claim 1 , wherein determining whether the dependent model is antiquated is performed in response to opening a project, the method further comprising determining whether any of a plurality of models or data sets in the project is antiquated.

13. The method of claim 1 , further comprising determining whether to update the dependent model based upon an experimental data classification of the dependent model.

14. A program product, comprising:

a non-transitory computer readable medium; and

program code stored on the computer readable medium and configured upon execution by at least one processing unit to manage model dependencies by:

updating the model or data set used by the first simulation application, including updating the version data therefor; and after updating the model or data set used by the first simulation application, determining whether the dependent model is antiquated based upon the version data maintained for the dependent model and the version data for the updated model or data set used by the first simulation application.

15. An apparatus, comprising:

at least one processing unit; and

program code configured upon execution by the at least one processing unit to manage model dependencies by: maintaining version data for a model or data set used by a first simulation application;

16. The apparatus of claim 15, wherein the program code is further configured to notify at least one user in response to determining that the dependent model is antiquated.

17. The apparatus of claim 15, wherein the program code is further configured to automatically update the dependent model in response to determining that the dependent model is antiquated.

18. The apparatus of claim 15, wherein the first simulation application is a fluid simulator, wherein the model or data set used by the first simulation application is a fluid model, and wherein the program code is further configured to automatically update a fluid model used by the dependent model in response to determining that the dependent model is antiquated.

19. The apparatus of claim 15, wherein the program code is further configured to dynamically tune a fluid model used by a fluid simulator by:

receiving first user input selecting a first set of one or more properties among a plurality of tunable properties for the fluid model;

in response to receiving the first user input, dynamically running a regression for the first set of one or more properties and generating a display of expected tuning results for the first set of one or more properties;

thereafter receiving second user input selecting a different, second set of one or more properties while the display of expected tuning results for the first set of one or more properties is displayed; and

in response to receiving the second user input, dynamically running a regression for the second set of one or more properties and updating the display to display expected tuning results for the second set of one or more properties.

20. The apparatus of claim 19, wherein the program code is configured to dynamically run the regression for the first set of one or more properties and

dynamically run the regression for the second set of one or more properties in a background process or thread, to dynamically run the regression for each property in the first set of one or more properties in parallel, and to dynamically run the regression for the first set of one or more properties and dynamically run the regression for the second set of one or more properties as full or fast regressions.

21 . The apparatus of claim 19, wherein the program code is configured to dynamically run the regression for the first set of one or more properties and

dynamically run the regression for the second set of one or more properties each by generating values for an objective function, to generate an initial value for the objective function associated with the fluid model without any tuning, and to dynamically run the regression for the first set of one or more properties by running a regression for each individual property in the first set of one or more properties and running a regression for each possible combination of the properties in the first set of one or more properties.

22. The apparatus of claim 15, wherein the program code is further configured to determine properties of a fluid by:

for each of a plurality of conditions over which to generate a flash grid, determining a range corresponding to the condition;

for each determined range, determining a plurality of values of the corresponding condition and distributed within the range;

for each combination of determined values within the determined ranges of the plurality of conditions, performing a flash calculation to calculate one or more fluid properties of the fluid; and

displaying a visualization based upon the flash calculations.

23. The apparatus of claim 22, wherein the plurality of conditions includes n conditions, wherein the program code is further configured to generate an n- dimensional array having n coordinates respectively corresponding to the n conditions, each coordinate including the determined values within the determined range of the corresponding condition.

24. The apparatus of claim 22, wherein the program code is further configured to perform flash calculations in parallel, and to interpolate the one or more fluid properties for at least one combination of values of the plurality of conditions.

25. The apparatus of claim 22, wherein the program code is further configured to, in response to user input to zoom in on the visualization, perform additional flash calculations within a subset of at least one of the determined ranges, and wherein the program code is further configured to, prior to performing the additional flash

calculations, interpolate a fluid property for at least one combination of values of the plurality of conditions within the subset of the at least one of the determined ranges such that the performance of the additional flash calculations replaces the interpolated fluid property.

26. The apparatus of claim 15, wherein the program code is further configured to compare fluids modeled by a fluid simulator by:

receiving user input selecting at least two fluids among a plurality of fluids modeled by the fluid simulator;

in response to the user input, generating a data visualization that compares the selected fluids; and

displaying the data visualization.

27. The apparatus of claim 26, wherein the program code is further configured to display at least one user control representing the plurality of fluids, wherein the user input is received from the at least one user control.

28. The apparatus of claim 26, wherein the program code is further configured to receiving additional user input selecting a different subset of fluids from among the plurality of fluids and dynamically update the data visualization in response to the additional user input.

29. The apparatus of claim 26, wherein the program code is further configured to receive additional user input changing a first fluid among the selected fluids and dynamically update the data visualization in response to the additional user input.

30. The apparatus of claim 26, wherein the plurality of fluids includes a plurality of versions of a first fluid, and wherein the plurality of versions differ based upon one or more of lumping, tuning or flash package.