PLATFORM

Cross-Reference to Related Applications

[0001] This application claims priority to U.S. Provisional Patent Application No. 63/376319, which was filed on September 20, 2022 and is incorporated herein by reference in its entirety.

Background

[0002] Oilfield entities, e.g., drillers, owners, service companies, operators, etc. rely on data collected not only at their wellsite, but also at other wells, oilfields, etc., to prepare oilfield plans and execute operations efficiently. The sheer size of the data can make this task a challenge, both to identify relevant or helpful data for a particular project and to perform analysis on the data that is considered relevant. Indeed, the data is generally stored in one or more silos or data stores, and then moved to processing resources for analysis. The transit time for this data can be non-trivial and lead to delays in arriving at insights. Further, the “freshness” of the data can be an on-going challenge, since the transit time is non-trivial, the frequency with which the data is updated may be relatively low, and thus stale data may be used in some cases.

[0003] Recently, shared platforms for data management have been developed and implemented in the industry. Once such platform is the Open Subsurface Data Universe (OSDU), which can provide a scalable data platform and may be agnostic to the end-user’s operating environment. That is, OSDU or other (open-source or proprietary) data aggregation platforms may provide data in a manageable way, enforcing data compliance standards, streaming updates, while permitting fast addition and development of data types for new workflows, and application-program interface (API) flexibility. However, challenges with data transmission times and consequential data freshness have persisted, even despite the increased efficiency provided with these platforms.

Summary

[0004] Examples of the present disclosure include a method for oilfield workflow processing that includes receiving a script from a first computing device at a data aggregation platform, the data aggregation platform comprising one or more processors and oilfield data, executing the script using the one or more processors and the oilfield data of the platform, and transmitting one or more results of the execution of the script back to the first computing device. At least some of the oilfield data that was used in executing the script is not transmitted back to the first computing device.

[0005] Examples of the present disclosure include a computing system including one or more processors, and a memory system comprising one or more non-transitory computer-readable media storing instructions that, when executed by at least one of the one or more processors, cause the computing system to perform operations. The operations include receiving a script from a first computing device at a data aggregation platform, the data aggregation platform comprising one or more processors and oilfield data, executing the script using the one or more processors and the oilfield data of the platform, and transmitting one or more results of the execution of the script back to the first computing device. At least some of the oilfield data that was used in executing the script is not transmitted back to the first computing device.

[0006] Examples of the present disclosure include a non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a computing system, cause the computing system to perform operations. The operations including receiving a script from a first computing device at a data aggregation platform, the data aggregation platform comprising one or more processors and oilfield data, executing the script using the one or more processors and the oilfield data of the platform, and transmitting one or more results of the execution of the script back to the first computing device. At least some of the oilfield data that was used in executing the script is not transmitted back to the first computing device.

[0007] It will be appreciated that this summary is intended merely to introduce some aspects of the present methods, systems, and media, which are more fully described and/or claimed below. Accordingly, this summary is not intended to be limiting.

Brief Description of the Drawings

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

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

[0010] Figure 2 illustrates a block diagram of a system for processing oilfield data, according to an example. [0011] Figure 3 illustrates a flowchart of a method for processing oilfield data, according to an example.

[0012] Figure 4 illustrates a display, including a plot of data points ingested over time, according to an example.

[0013] Figure 5 illustrates a view of a user’s data accessible within a data aggregation platform, according to an example.

[0014] Figure 6 illustrates a dashboard showing a data quality control analysis, according to an example.

[0015] Figure 7 illustrates a schematic view of a computing system, according to an example.

Detailed Description

[0016] Reference will now be made in detail to examples, examples of which are illustrated in the accompanying drawings and figures. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent to one of ordinary skill in the art that the invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the examples.

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

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

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

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

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

[0022] In an example example, the simulation component 120 may rely on entities 122. Entities 122 may include earth entities or geological objects such as wells, surfaces, bodies, reservoirs, etc. In the system 100, the entities 122 can include virtual representations of actual physical entities that are reconstructed for purposes of simulation. The entities 122 may include entities based on data acquired via sensing, observation, etc. (e.g., the seismic data 112 and other information 114). An entity may be characterized by one or more properties (e.g., a geometrical pillar grid entity of an earth model may be characterized by a porosity property). Such properties may represent one or more measurements (e.g., acquired data), calculations, etc. [0023] In an example example, the simulation component 120 may operate in conjunction with a software framework such as an object-based framework. In such a framework, entities may include entities based on pre-defined classes to facilitate modeling and simulation. A commercially available example of an object -based framework is the MICROSOFT® .NET® framework (Redmond, Washington), which provides a set of extensible object classes. In the .NET® framework, an object class encapsulates a module of reusable code and associated data structures. Object classes can be used to instantiate object instances for use in by a program, script, etc. For example, borehole classes may define objects for representing boreholes based on well data.

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

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

[0026] In an example example, the management components 110 may include features of a commercially available framework such as the PETREL® seismic to simulation software framework (Schlumberger Limited, Houston, Texas). The PETREL® framework provides components that allow for optimization of exploration and development operations. The PETREL® framework includes seismic to simulation software components that can output information for use in increasing reservoir performance, for example, by improving asset team productivity. Through use of such a framework, various professionals (e.g., geophysicists, geologists, and reservoir engineers) can develop collaborative workflows and integrate operations to streamline processes. Such a framework may be considered an application and may be considered a data- driven application (e.g., where data is input for purposes of modeling, simulating, etc.).

[0027] In an example example, various aspects of the management components 110 may include add-ons or plug-ins that operate according to specifications of a framework environment. For example, a commercially available framework environment marketed as the OCEAN® framework environment (Schlumberger Limited, Houston, Texas) allows for integration of add-ons (or plugins) into a PETREL® framework workflow. The OCEAN® framework environment leverages .NET® tools (Microsoft Corporation, Redmond, Washington) and offers stable, user-friendly interfaces for efficient development. In an example example, various components may be implemented as add-ons (or plug-ins) that conform to and operate according to specifications of a framework environment (e.g., according to application programming interface (API) specifications, etc.).

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

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

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

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

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

[0033] In the example of Figure 1, the geologic environment 150 may include layers (e.g., stratification) that include a reservoir 151 and one or more other features such as the fault 153-1, the geobody 153-2, etc. As an example, the geologic environment 150 may be outfitted with any of a variety of sensors, detectors, actuators, etc. For example, equipment 152 may include communication circuitry to receive and to transmit information with respect to one or more networks 155. Such information may include information associated with downhole equipment 154, which may be equipment to acquire information, to assist with resource recovery, etc. Other equipment 156 may be located remote from a well site and include sensing, detecting, emitting or other circuitry. Such equipment may include storage and communication circuitry to store and to communicate data, instructions, etc. As an example, one or more satellites may be provided for purposes of communications, data acquisition, etc. For example, Figure 1 shows a satellite in communication with the network 155 that may be configured for communications, noting that the satellite may additionally or instead include circuitry for imagery (e.g., spatial, spectral, temporal, radiometric, etc.). [0034] Figure 1 also shows the geologic environment 150 as optionally including equipment 157 and 158 associated with a well that includes a substantially horizontal portion that may intersect with one or more fractures 159. For example, consider a well in a shale formation that may include natural fractures, artificial fractures (e.g., hydraulic fractures) or a combination of natural and artificial fractures. As an example, a well may be drilled for a reservoir that is laterally extensive. In such an example, lateral variations in properties, stresses, etc. may exist where an assessment of such variations may assist with planning, operations, etc. to develop a laterally extensive reservoir (e.g., via fracturing, injecting, extracting, etc.). As an example, the equipment 157 and/or 158 may include components, a system, systems, etc. for fracturing, seismic sensing, analysis of seismic data, assessment of one or more fractures, etc.

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

[0036] At least some examples of the present disclosure may provide systems and methods for executing analytics workflows within an oilfield data aggregation platform, such as OSDU. As noted above, OSDU may contain cross-discipline subsurface data, metadata, analysis of the data/metadata, etc. Such data may include drilling reports, well logs, sensor logs, measuring-whiledrilling (MWD) logs, logging-while-drilling (LWD) logs, surveys, subsurface models (e.g., basin models, velocity models, facies models, geomechanical models, etc.), geological data, geographical data, and/or other data.

[0037] Data relevant and accessible to a given end-user may be potentially very large, e.g., terabytes or larger amounts of data, which can take a long time to transmit. Accordingly, examples of the present disclosure may permit at least some processing to occur in-situ at the data aggregation platform. This paradigm presents its own challenges, such as proper governance of the data, such that data that is proprietary to one end user is not exposed to or otherwise used by another end user without the owner’s consent. Some examples of the present disclosure may address these and other challenges.

[0038] Figure 2 illustrates a block diagram view of a system 200, according to an example. The system 200 generally includes a data aggregation platform 202, which may be, for example, OSDU. The platform 202 includes cloud processing capabilities (e.g., servers) 204, oilfield data storage 206, data compliance rules 208, and/or applications 210. The system 200 may also include a remote (client) computing system 212.

[0039] The remote computing system 212 may transmit, e.g., via the internet, applications, scripts, program calls, API calls, aggregations, etc. (collectively referred to herein as “scripts” for simplicity) to the platform 202. In turn, the processors 204 may execute one or more of the applications 210 based on the scripts, so as to achieve a result commanded by the script (e.g., a particular analysis of data, visualization, mapping, quality-control metrics, etc.). While performing such execution, the processors 204 may access the oilfield data, if consistent with the data compliance rules 208, and perform the analysis, visualization, mapping, etc., instructed by the scripts. In some examples, elasticsearch scripts may be used, but in other examples, other types of scripts may be employed. Further, in at least some examples, scripts may be read-only. Write scripts, which could modify the data on the platform 202, may be disallowed, ignored, etc.

[0040] The platform 202 may complete its search, analysis, processing, visualization, etc., of the oilfield data from the storage 206 based on the scripts, and using the applications 210 and oilfield data in the storage 206, and provide results/analysis back to the remote computing system 212. Accordingly, the remote computing system 212 may acquire data useful to its user, e.g., the analysis/visualization of the data, without having to operate on the data itself, but rather via function calls to the APIs and data storage within the platform 202.

[0041] To run an analytics workflow on the data aggregation platform 202, the platform 202 may be extended with other components, represented by the applications 210, providing additional functionality beyond flexible data storage. Such other components may include data analytics applications, such as TIBCO Spotfire Data Visualization and Analytics software and/or mapping or GIS software, such as MapLarge. These specific examples are merely illustrative and not meant to be limiting. Such extended components may add additional licensing, infrastructure and operational costs, which may be flexibly managed by the platform 202.

[0042] In at least some examples, an application 210 may be built, e.g., in Angular DLS, that receives a script (e.g., an elastic syntax aggregation) to express how to calculate a metric from the data. The script may include a render settings configuration to express how to visualize those results e.g., as a grid, pie chart, scatter graph etc.

[0043] This may permit other applications and/or clients to integrate custom views of data acquired from the platform (OSDU data). In turn, an application 210 may permit a domain expert to enter this information and the calculation and visualization pieces, and not the calculation itself. [0044] Figure 3 illustrates a flowchart of a method 300 for executing oilfield workflows using a data aggregation platform, according to an example. The method 300 may be illustrative of operation of the system 200, in at least some examples. The method 300 may include receiving oilfield data onto a cloud-computing platform (the data aggregation platform, e.g., OSDU), as at 302. The method 300 may include generating one or more scripts (e.g., elasticsearch scripts such as inline Painless scripts, other aggregations, applications, program/function calls, etc.) using a remote computing system (e.g., a client device), as at 304. The device may be “remote” in the sense that it is not physically connected to the platform, e.g., relying instead on telecommunications to send and receive data to/from the platform.

[0045] The method 300 may include transmitting data representing the script(s) to the platform from the remote computing system, as at 306, e g., using one or more telecommunications protocols, networks, etc. In turn, the method 300 may include executing the script(s) on the platform using the oilfield data, as at 308. In this manner, the platform “receives” the data transmitted from the remote computing system. That is, the processors (e.g., cloud computing) of the platform may receive the scripts and execute the commands therein, subject to rules, such as the functions of the application being read-only. While executing the applications, the processor(s) of the platform may ensure that data access/compliance rules (e.g., data governance) are maintained, as at 310.

[0046] The execution of the applications may provide a curated search, analysis, and/or visualization of large amounts of oilfield data, which might otherwise result in substantial data transmission times/delays. That is, relatively small amounts of data, representing the scripts and the analysis/visualization results are transmitted, while the oilfield data remains on the platform and is not transmitted. Further, data governance rules can be applied on the platform side, rather than by the user, permitting siloing/encapsulation of data as desired by the end-user, platformprovider, or any other governance entity.

[0047] Once the script is executed, the method 300 may provide data representing results of the execution of the script to a user of the platform, as at 312. For example, the data representing the results may be transmitted back to the remote computing system, e.g., as shown in Figure 2. In at least some examples, none (or in certain examples, a small amount) of the oilfield data may be transmitted to the remote computing system, such that execution latency experienced from transmitted large data files may be avoided.

[0048] Figure 4 illustrates a display, including a plot of data points ingested over time, according to an example. This component may be used by an application engineer as part of a DLS component library. The aggregations run directly against the OSDU instance configured and don’t require any extra components, resources or syncing of data outside the OSDU.

[0049] A user may provide a query in, e.g., two parts. The first is the aggregation or calculation they want to perform on the data and a filter to select the subset of data to perform this on, for instance:

"kind"' "*•*•*•*"

"query": "index. statusCode:404",

"aggregations": {

"records_by_namespace": {

"terms": {

"field": "namespace",

"size": 10

}

}

}, [0050] The second part is the render settings to describe what parts of the result to display and how to display those parts. For instance: "rendersettings": {

"type": "bar",

"title": "Records with missing schema",

"ymax": 3500,

"project": {

"records by namespace.doc count": "Record Count"

},

"by": {

"records_by_namespace.key " : "Namespace"

}

}

[0051] This then results in a quick and unique view of the user’s data they have access to within their OSDU, as shown in Figure 5.

[0052] Integrating a custom view into any application that runs on the OSDU is a challenge, as the platform’s software is required to run. Such a custom view may be integrated, as provided in Figure 6. Figure 6 shows the ease of integrating this into an existing application as opposed to some of the other solutions mentioned.

[0053] Having up-to-date views of the OSDU and performance can also be challenging. Some applications may sync the OSDU data first, but this can cause a delay of potentially many minutes. Moreover, data goes stale quickly and thus such delays have possible compliance issues as if the data compliance state or access rights change in the OSDU this is not replicated in the external tool.

[0054] Examples of the present disclosure provide a tool that runs natively on the OSDU. As a consequence, the results presented are live and up to date and do not expend extra time to sync the data before creating views. [0055] Finally the cost impact of this solution is relatively low, because separate software licenses or servers may not be called for. Examples of the present disclosure may be offered directly in a hosted application environment removing the integration of the component in an individual application. This allows the domain user to generate dashboards having multiple of these components, and instead focusing on how to visualize their data.

[0056] For example, a quality-control (QC) overview of the data can be visualized, as shown in Figure 6. Each UI component shown, the drop downs, the cards and the charts, are a single instance this component using the same approach to aggregate the data and then expressing how to visualize that data, given the domain user freedom without moving data out of their OSDU.

[0057] In some examples, the methods of the present disclosure may be executed by a computing system. Figure 7 illustrates an example of such a computing system 700, in accordance with some examples. The computing system 700 may include a computer or computer system 701 A, which may be an individual computer system 701A or an arrangement of distributed computer systems. The computer system 701A includes one or more analysis modules 702 that are configured to perform various tasks according to some examples, such as one or more methods disclosed herein. To perform these various tasks, the analysis module 702 executes independently, or in coordination with, one or more processors 704, which is (or are) connected to one or more storage media 706. The processor(s) 704 is (or are) also connected to a network interface 707 to allow the computer system 701A to communicate over a data network 709 with one or more additional computer systems and/or computing systems, such as 701B, 701C, and/or 701D (note that computer systems 701B, 701C and/or 701D may or may not share the same architecture as computer system 701A, and may be located in different physical locations, e.g., computer systems 701A and 701B may be located in a processing facility, while in communication with one or more computer systems such as 701C and/or 70 ID that are located in one or more data centers, and/or located in varying countries on different continents).

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

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

[0060] In some examples, computing system 700 contains one or more workflow implementation module(s) 708. In the example of computing system 700, computer system 701A includes the workflow implementation module 708. In some examples, a single workflow implementation module may be used to perform some aspects of one or more examples of the methods disclosed herein. In other examples, a plurality of workflow implementation modules may be used to perform some aspects of methods herein.

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

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

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

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