BACKGROUND

Field

[0001] The present disclosure relates generally to oil and gas data analytics, and more specifically, to generating a visual flow analyzer for exploratory hypotheses in upstream oil and gas process data.

Related Art

[0002] In the related art, oil and gas rigs utilize computerized systems to assist the operators of the rigs throughout the different phases of the oil or gas rigs (e.g., exploration, drilling, production, completions). Such computer systems are deployed for the development of energy sources such as shale gas, oil sands, and deep water resources. In the related art, attention has shifted to the development of shale gas for supplying future energy needs. Related art advances in horizontal directional drilling and hydraulic fracturing technologies have unlocked the potential for recovering natural gas from shale to become a viable energy source.

[0003] However, the issue of maximizing output from an oil and gas reservoir, particularly shale gas reservoirs, is not well understood, even with the assistance from present computer systems. The process of making production decisions and sizing top-side facilities is a manual process that depends on the judgment of the rig operator. Furthermore, operators often struggle with real-time performance of support for down- hole gauges, semi- submersible pumps, and other equipment. Non-Productive Time (NPT) for a rig may constitute over 30% of the cost of drilling operations.

[0004] One aspect of the issue of output maximization is the lack of effective data processing and data analytics, along with the sheer volume of data received from oil and gas wellsites. The data sets obtained from different upstream processes can be substantial in terms of number of available attributes. Manually developing applications that utilize these attributes can be very time-consuming. [0005] In particular, conducting applications involving flow construction for data viewing may be a tedious task as the users creating flows in a user interface are tasked with connecting operators to streaming processes, and then compiling the flow before viewing the results. The compilation of the flows may take time until an application is created, which can be executed in a user interface window pane for results visualization. Thus, if any errors were made in constructing the flow, the user will not be aware of the errors until the application is generated from the compilation of the flows. Further, the user will not be able to determine where in the flow the errors may occur.

SUMMARY

[0006] Allowing the users to construct flows of analytical operators is a significant step in reducing the time spent for developing applications. The related art has focused on data flow builders which do not allow for inline visualization of results from the flow due to the compilation requirements. Thus, related art implementations only allow user to construct the full flow, then execute and visualize the final results. The related art implementations are an impediment for exploratory visual analytics.

[0007] Example implementations of the present disclosure facilitate inline analytics- based visualization as opposed to waiting for the flow to compile, execute, and then provide visualized results. Example implementations are directed to process-based domain level operators that subsume one or many analytical operators, and preserving context of the flow as the flow is constructed. Through the example implementations, a unique visualization for oil and gas domain exploratory analysis can be provided.

[0008] Aspects of the present disclosure includes an apparatus, which may include a memory configured to store flow information that can include one or more sequences of domain operators, and global context information involving output information from each domain operator in a present sequence from the one or more sequences of domain operators; and a processor, configured to, for a selection of a domain operator from one or more possible subsequent domain operators of a present sequence from the one or more sequences of domain operators, append the domain operator to an end operator of the selected sequence from the flow information; provide information regarding subject analysis of the domain operator from the end operator as input to the domain operator; execute the domain operator to provide additional output information to append to the global context information; and configure a visualization pane to update a visualization based on the additional output information.

[0009] Aspects of the present disclosure may also include a method, which can involve managing flow information involving one or more sequences of domain operators, and global context information involving output information from each domain operator in a present sequence from the one or more sequences of domain operators; and for a selection of a domain operator from one or more possible subsequent domain operators of a present sequence from the one or more sequences of domain operators, appending the domain operator to an end operator of the selected sequence from the flow information; providing information regarding subject analysis of the domain operator from the end operator as input to the domain operator; executing the domain operator to provide additional output information to append to the global context information; and configuring a visualization pane to update a visualization based on the additional output information.

[0010] Aspects of the present disclosure may also include a non-transitory computer readable medium, storing instructions for executing a process. The instructions can involve managing flow information involving one or more sequences of domain operators, and global context information involving output information from each domain operator in a present sequence from the one or more sequences of domain operators; and for a selection of a domain operator from one or more possible subsequent domain operators of a present sequence from the one or more sequences of domain operators, appending the domain operator to an end operator of the selected sequence from the flow information; providing information regarding subject analysis of the domain operator from the end operator as input to the domain operator; executing the domain operator to provide additional output information to append to the global context information; and configuring a visualization pane to update a visualization based on the additional output information.

[0011] Aspects of the present disclosure may also include a computer program, storing instructions for executing a process. The instructions can involve managing flow information involving one or more sequences of domain operators, and global context information involving output information from each domain operator in a present sequence from the one or more sequences of domain operators; and for a selection of a domain operator from one or more possible subsequent domain operators of a present sequence from the one or more sequences of domain operators, appending the domain operator to an end operator of the selected sequence from the flow information; providing information regarding subject analysis of the domain operator from the end operator as input to the domain operator; executing the domain operator to provide additional output information to append to the global context information; and configuring a visualization pane to update a visualization based on the additional output information.

[0012] Aspects of the present disclosure includes an apparatus, which may include means for storing flow information that can include one or more sequences of domain operators, and global context information involving output information from each domain operator in a present sequence from the one or more sequences of domain operators; and means for, for a selection of a domain operator from one or more possible subsequent domain operators of a present sequence from the one or more sequences of domain operators, appending the domain operator to an end operator of the selected sequence from the flow information; means for providing information regarding subject analysis of the domain operator from the end operator as input to the domain operator; means for executing the domain operator to provide additional output information to append to the global context information; and means for configuring a visualization pane to update a visualization based on the additional output information.

BRIEF DESCRIPTION OF DRAWINGS

[0013] FIG. 1(a) illustrates a system involving a plurality of rig systems and a management server, in accordance with an example implementation.

[0014] FIG. 1(b) illustrates an example timeline for a rig system, in accordance with an example implementation.

[0015] FIG. 2 illustrates an example rig in accordance with an example implementation.

[0016] FIG. 3 illustrates an example configuration of a rig system, in accordance with an example implementation.

[0017] FIG. 4 illustrates a configuration of a management server, in accordance with an example implementation. [0018] FIG. 5 illustrates an example system architecture for the management server, in accordance with an example implementation.

[0019] FIG. 6 illustrates an example screenshot for visual analytics provided in the User Interface (UI) layer, in accordance with an example implementation.

[0020] FIG. 7 illustrates an example operator flow for maintaining global context for visualization, in accordance with an example implementation.

[0021] FIG. 8 illustrates an operator design in accordance with an example implementation.

[0022] FIG. 9 illustrates an example flow with execution statistics, in accordance with an example implementation.

[0023] FIG. 10 illustrates a flow ID table, in accordance with an example implementation.

[0024] FIG. 11 illustrates an operator table, in accordance with an example implementation.

[0025] FIG. 12 illustrates flow information, in accordance with an example implementation.

[0026] FIG. 13 illustrates an example flow diagram for inline operator execution, in accordance with an example implementation.

[0027] FIG. 14 illustrates an example of a forked flow, in accordance with an example implementation.

[0028] FIG. 15 illustrate an example flow and data sent to the global context in accordance with an example implementation.

[0029] FIG. 16(a) and 16(b) illustrate an example transition of the visualization, in accordance with an example implementation. DETAILED DESCRIPTION

[0030] The following detailed description provides further details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatic" may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. The term "rig" and "well" may also be used interchangeably. "Rig systems" and "wellsites" may also be utilized interchangeably.

[0031] FIG. 1(a) illustrates a system involving a plurality of rig systems and a management server, in accordance with an example implementation. One or more rig systems 101-1, 101-2, 101-3, 101-4, and 101-5 can each involve a corresponding rig 200- 1, 200-2, 200-3, 200-4, 200-5 as illustrated in FIG. 2 along with a corresponding rig node 300-1, 300-2, 300-3, 300-4, and 300-5 as illustrated in FIG. 3. Each of the rig systems 101-1, 101-2, 101-3, 101-4, and 101-5 is connected to a network 100 which is connected to a management server 102. The management server 102 manages a database 103, which contains data aggregated from the rig systems in the network 100. In alternate example implementations, the data from the rig systems 101-1, 101-2, 101-3, 101-4, and 101-5 can be aggregated to a central repository or central database such as public databases that aggregate data from rigs or rig systems, such as for government compliance purposes, and the management server 102 can access or retrieve the data from the central repository or central database.

[0032] FIG. 1(b) illustrates an example timeline for a rig system, in accordance with an example implementation. The timeline for the rig system 101 may include multiple phases of rig operation. These phases can include (but are not limited to) an exploration phase, a drilling phase, a completions phase, a production phase, a processing phase and a pipeline phase. In the following description, the term "process" may also be used interchangeably with the term "phase". Example implementations may involve data or attributes associated with one or more of the phases of the timeline, depending on the desired implementation. [0033] During the exploration phase, the well is initially drilled to determine whether reservoirs with oil or gas are present and the initial construction of the rig. In example implementations described herein, the rig node may be configured to assist the user in determining how to configure the rig and the parameters for the drilling during the exploration phase.

[0034] The drilling phase follows the exploration phase as determined in the exploration phase, e.g., if promising amounts of oil and gas are confirmed from the exploration phase. During the drilling phase, the size and characteristics of the discovery are determined and technical information is utilized to allow for more optimal methods for recovery of the oil and gas. An appraisal drilling can be performed and a rig is established. In example implementations described herein, the rig node may be configured to assist the user in determining appropriate parameters for the drilling and assist in the management and obtaining of desired characteristics for the rig.

[0035] The completions phase is directed to the determination as to whether the well should be completed as a well, or whether it should be abandoned as a dry hole. The completion phase transforms the drilled well into a producing well. During this phase, the casing of the rig may be constructed, along with the perforations. Various aspects of the construction of the rig, such as cementing, gravel packing and production tree installation may be employed. Sensors may be employed to determine various parameters for facilitating the completion of the rig, such as rate of flow, flow pressure and gas to oil ratio measurements, but not limited thereto.

[0036] The production phase follows the completions phase and is directed to the facilitation of production of oil or gas. The production phase includes the operation of wells and compressor stations or pump stations, waste management, and maintenance and replacement of facility components. Sensors may be utilized to observe the above operations, as well as determining environmental impacts from parameters such as sludge waste accumulation, noise, and so on. Example implementations described herein may provide feedback to rig system operators to maximize the production of the rig based on the use of model signatures.

[0037] During the processing and pipelining phase, the produced oil or gas is processed and transferred to refineries through a pipeline. [0038] FIG. 2 illustrates an example rig 200 in accordance with an example implementation. The example implementation depicted in FIG. 2 is directed to a shale gas rig. However, similar concepts can be employed at other types of rigs as well without departing from the inventive scope of the present disclosure, for example, example implementations described herein can also be applied to horizontal oil wells by integrating features from multiple upstream processes. The well 201 may include one or more gas lift valves 201-1 which are configured to control hydrostatic pressure of the tubing 201-2. Tubing 201-2 is configured to extract gas from the well 201. The well 201 may include a case 201-3 which can involve a pipe constructed within the borehole of the well. One or more packers 201-4 can be employed to isolate sections of the well 201. Perforations 201- 5 within the casing 201-3 allow for a connection between the shale gas reservoir to the tubing 201-2.

[0039] The rig 200 may include multiple sub-systems directed to injection of material into the well 201 and to the production of material from the well 201. For the injection system 250 of the rig 200, there may be a compressor system 202 that includes one or more compressors that are configured to inject material into the well such as air or water. A gas header system 202 may involve a gas header 202- 1 and a series of valves to control the injection flow of the compressor system 202. A choke system 203 may include a controller or casing choke valve which is configured to reduce the flow of material into the well 201.

[0040] For the production system 260 of the rig 200, there may be a wing and master valve system 204 which contains one or more wing valves configured to control the flow of production of the well 201. A flowline choke system 205 may include a flowline choke to control flowline pressure from the well 201. A production header system 206 may employ a production header 206-1 and one or more valves to control the flow from the well 201, and to send produced fluids from the well 201 to either testing or production vessels. A separator system 207 may include one or more separators configured to separate material such as sand or silt from the material extracted from the well 201.

[0041] As illustrated in FIG. 2 various sensors may be applied throughout the rig to measure various data or attributes for a rig node, which are described in further detail below. The sensors are identified by an "S" in an octagon in FIG. 2. These sensors provide feedback to the rig node which can interact with the system as illustrated in FIGS. 1(a) and 1(b), and can be fed to the management server 102 for database storage 103, and/or supplied to a central repository or database such as a public database, which can then be harvested by management server 102.

[0042] FIG. 3 illustrates an example configuration of a rig system 101, in accordance with an example implementation. The rig system 101 includes a rig 200 as illustrated in FIG. 2 which contains a plurality of sensors 210. The rig system 101 includes a rig node 300 which may be in the form of a server or other computer device and can contain a processor 301, a memory 302, a storage 303, a data interface (I/F) 304 and a network I/F 305. The data I/F 304 interacts with the one or more sensors 210 of the rig 200 and store raw data in the storage 303, which can be sent to a management server for processing, or to a central repository or central database. The network I/F 305 provides an interface to connect to the network 100.

[0043] FIG. 4 illustrates a configuration of a management server 102, in accordance with an example implementation. Although the example implementation for apparatuses is described as management server 102, other implementations are also possible depending on the desired implementation. Management server 102 may involve a processor 401, a memory 402, a storage I/F 404 and a network I/F 405. The processor 401 is configured to execute one or more programs in the memory 402, to process data and for calculating composite similarity scores. The storage I/F 404 is the interface to facilitate connections between the management server 102 and the database 103. The network I/F 405 facilitates interactions between the management server 102 and the plurality of rig systems. Data is aggregated to the management server by the network I/F and then subsequently stored in the database, for example, for future analytics. Alternatively, the plurality of rig systems may send the data to a central database or repository, which is then processed by the management server 102. Management server 102 may execute a process for constructing composite similarity scores by using programs stored in memory 402 and executed by processor 401.

[0044] Memory 402 may be configured to store the information as described in FIGS. 10-12 below. The flow information from FIG. 10 can include an index of created flows. Each of the flows can involve one or more sequences of domain operators, the sequence constructed based on references to the previous operator for each operator in the sequence as illustrated in FIG. 12. Memory may also manage global context information, which can include output information from each domain operator in the sequence, as illustrated by the output data from each operator of FIG. 12.

[0045] Processor 401 may be configured to execute one or more functions as described in FIG. 5 and FIG. 7, as well as the flow diagram of FIG. 13. In particular, processor 401 may be configured to provide a visualization of a present sequence of operators selected by a user from the flow information as illustrated in FIG. 6, as well as process a selection of a domain operators based on possible domain operators that can be appended to the present sequence of operators. For a selection of a domain operator from one or more possible subsequent domain operators, of a present sequence from the one or more sequences of domain operators selected from flows of FIG. 10, the processor 401 may append the domain operator to an end operator of the selected sequence from the flow information as illustrated in flow operator pane of FIG. 6, provide information regarding subject analysis of the domain operator from the end operator as input to the domain operator; execute the domain operator in an inline manner to provide additional output information to append to the global context information; and configure a visualization pane to update a visualization based on the additional output information as illustrated in the visualization pane of FIG. 6. The information regarding subject analysis of the domain operator may be restricted to the well IDs, or the identifiers for one or more wells that are selected from the interactive sections of the user interface of FIG. 6, to condense the information sent to the appended operator and assist in faster inline execution of the appended operator.

[0046] The processor 401 is further configured to provide a domain operator pane for operator selection as illustrated in FIG. 6. The domain operator pane may include one or more possible subsequent domain operators of the present sequence based on the end operator of the present sequence. The possible subsequent domain operators may be chosen for presentation based on the output of the end operator, based on the present information in the global context information, and so on, depending on the desired implementation. Processor 401 is also configured to provide a visualization pane configured to provide visualization of the end operator based on the global context information as illustrated in FIG. 6. The visualization pane may provide results in the form of graphs comparing clusters of wells or other visualizations depending on the end operator and the desired implementation. From the selection of the domain operator, the processor 401 may determine the one or more wells from the end operator to be sent as input for the domain operator from the global context information. Such wells can include wells selected in the interactive pane of FIG. 6, wells filtered from the addition of the operator by time, production values, and so on, or by other methods depending on the desired implementation. The output information can be provided from the execution of the analytics of the end operator.

[0047] Processor 401 may also be configured to facilitate rollback functions along the present flow as presented in FIG. 6 based on the present sequence of operators. For example, the processor 401 is configured to process a selection of a prior domain operator before the end operator, allowing the user to rollback the visualizations presented in FIG. 6. For a selection of a prior domain operator before the end operator, the processor 401 is configured to configure the visualization pane to update the visualization based on the output information corresponding to the prior domain operator from the global context information. This can be done by the processor 401 referring back to the global context information corresponding to the selected operator within the sequence as being the end operator and updating the visualization of FIG. 6 from the global context information as if the selected operator is the end operator. Such implementations can also facilitate forking the flow as described with respect to FIG. 12.

[0048] FIG. 5 illustrates an example system architecture for the management server, in accordance with an example implementation. The lower layer of the management server includes the data ingestion layer 500, which is configured to receive data from the network. The data can be external data sources and received directly from rig systems, or can be extracted from central repositories or databases. In an example implementation involving a central database, the data ingestion layer 500 may periodically query the central database, such as a public database that tracks oil and gas management information from rig systems, and obtain data from corresponding rig systems based on API. The data ingestion layer 500 may perform an extract, transform, and load (ETL) to process and forward the data to the raw operational data 501.

[0049] Data is ingested and processed as raw operational data in the raw operational data layer 501. The data that can be processed can include data such as operational data 501-1, Geographic Information Systems (GIS) data 501-2, Geology data 501-3, and so on. In the raw operational data layer 501, a feature extraction process is executed to process the data and extract features for feeding to the core engine layer 502.

[0050] The core engine layer 502 conduct pre-processing and feature extractions 502- 1 to extract features from the raw operational data. Core engine layer 502 may also utilize hidden Markov models (HMM) 502-2 to determine relationships between attributes, including dependencies. Rule based analytics and analytical models 502-3 can be utilized to conduct analytics on the data for generating models, such as the example implementations described herein for generating the composite similarity scores. The outputs are processed and sent to the processed data layer 503, which can manage the features 503-1, co-relations between attributes 503-2 and other information for the decision cube 504. The decision cube layer 504 can also send cube queries to the core engine 502 to manage cube information as necessary. Core engine 502 and decision cube 504 may work in tandem to implement analytics according to the desired implementation, and store the data in the processed data 503. In particular, rule based analytics and analytical models 502-3 can include algorithms needed to implement the desired analytics.

[0051] Visual analytics can also be provided to the User Interface (UI) layer 505 for generating output. The UI interface layer 505 can be configured to take any two attributes from the cube and display them in a desired output format (e.g., bar graph, pie graph, line graph, etc.), with the x-axis and y-axis being based on the cube dimension of the attribute. The units of the x-axis and the y-axis can be scaled up and down according to the hierarchy of the attributes (i.e. along the scalar, spatial and temporal hierarchy).

[0052] FIG. 6 illustrates an example of visual analytics provided in the User Interface (UI) layer 505, in accordance with an example implementation. Example implementations facilitate a mechanism for inline analysis and visualization of custom hypotheses. In the example visual analytics of FIG. 6, there is an interactive pane 601 that is configured to provide (e.g. display) visualization of a map showing different entities (e.g. wells, fields, operators etc.) both over space and time. The interactive pane 601 captures the context of the hypothesis as described below. The hypothesis builder 602 is a domain operator pane that provides filters and operators configured to assist in defining custom hypotheses, and involve several filters (selection according to some criteria) as well as domain level operators according to the exploration, drilling, completions, and production processes. These domain level operators implement specific domain functionalities such that each domain functionality can encompass one or more analytical operations. For example, production operator includes production forecast, drilling operator includes well-log patterns, rock similarity etc. Output data pane 603 is configured to provide a preview of an output result from a custom hypothesis. In the output data pane 603, there is an execution statistics panel which is configured to provide meta-data about the results of the operator(s) (e.g., execution time, resources consumed), and a process output panel which provides results of the inline operator execution.

[0053] Flow tracker pane 604 is configured to keep track of the sequence of operators that a user selects. Each flow may be built automatically as the user selects the operators. Each flow can have its own namespace. Visualization pane 605 is configured to provide visualization for the results of hypothesis in form of charts and the like. Inline visualization of the results is provided as a user chooses the operators. Each operator is configured with a registered visualization. In example implementations, a mechanism where the context of the flow is preserved is also provided. Depending on the desired implementation, visualization pane 605 may include the interactive pane 60 las well to provide additional context to the visualizations.

[0054] In example implementations, the user can utilize the hypothesis flow builder for building custom analysis. At every operation, the user is presented with different domain operators for each process to choose from, based on their requirement.

[0055] In the example as depicted in FIG. 6, the user has selected to add an operator to the present sequence of operators in the flow tracker 604. The user selected the analytics operator panel in the hypothesis builder 602 and selected production operators. The user interface provides a set of possible subsequent operators given the present sequence of operators in the flow tracker 604. From the production operators, the user selected the production forecast (aggregate) as indicated in grey, which is appended to the end operator of the present sequence of operators at flow tracker 604 as indicated in grey. From the selection of the production forecast (aggregate) operator, the hypothesis builder 602 also indicates the input to the operator, the well IDs involved based on the selection in the interactive section 601 as indicated by a selection of wells in the area enclosed in the dashed line, the production feature, and well clusters involved. When the production forecast (aggregate) operator is selected, the system executes the operator, and provides visualizations 605 in the visualization associated with the operator. Here, the visualization associated with the production forecast (aggregate) is indicated in graph form.

[0056] In output data 603, the types of output that can be provided include execution statistics for adding the operator to the present sequence of operators (e.g., resources, memory consumed, time for execution of operator), and process output. In the example of FIG. 6, the user selects the process output (indicated in grey), which provides forecast value information as calculated across the desired groups of wells.

[0057] FIG. 7 illustrates an example operator flow for maintaining global context for visualization, in accordance with an example implementation. In the example illustrated in FIG. 7, the request input to an operator includes needed information related to oil and gas analytics and may be made compact depending on the resources available in the underlying management server. For example, the information can only include the set of the well IDs needed to effect the operator, depending on the desired implementation. The required data for the operator is collected by an input data preparation module based on the set of well IDs received. The output has two aspects: the output to the next operator contains the set of well IDs, the output to the global context can include an operator reference along with reference to its predecessor. In case of the first operator, the previous operator is defined as empty. Further output to the global context can include input parameters and execution statistics of the operator. Every operator has a registered visualization which will utilize the information available in global context to build the necessary chart or other visualization. In the example of FIG. 7, a flow sequence includes a filter operator 700, and one or more operators 701-1, 701-2, 701-3 arranged in sequence that are configured to provide information to the global context 702. Information fed in the global context 702 is sent to visualization 703 which provides a visualization in the visualization pane so that the user can have a visualization of the flow at a given part of the sequence. Global context 702 operates as an aggregate of output from each of the operators in the sequence.

[0058] FIG. 8 illustrates an operator design in accordance with an example implementation. Operator Design involves a domain operator 803 that conducts input data preparation 800, analytics core 801, and output handler 802. The domain operator 803, input data preparation 800, analytics core 801, and output handler 802 can be implemented as modules configured to execute their respective functions. The domain operator 803 takes in an input request for analytics processing, which is sent to input data preparation 800. Input data preparation 800 involves input parser 800-1, validations 800-2, analytic data preparation 800-3, and imputations 800-4. Input parser 800-1 parses input data from the database for processing by analytics core 801. Validations 800-2 parses the input data to determine the validity of the data. Analytic data preparation 800-3 prepares the input data into one or more formats to be processed by analytics core 801. Imputations 800-4 imputes data for missing data points within the input data.

[0059] Analytics core 801 provides the analytics functions to facilitate the construction of the one or more flows, and can include algorithm 801-1, domain configuration 801-2, external adapter 801-3, and execution statistics 801-4. Algorithm

801- 1 includes one or more algorithms that can be utilized to prepare the analytics. Domain configuration 801-2 provides one or more operators configured to provide analytics functions within the domain of the domain operator 803 to produce one or more flows. External adapter 801-3. Execution statistics 801-4 determines the resources and time utilized to execute the flow.

[0060] Output handler 802 provides the output and generates visualizations as the provided response. Output handler 802 can include data formatter 802-1, visualizations

802- 2, data exchange 802-3, and persistence 802-4. Data formatter 802-1 formats the data as processed by analytics core 801 into output data for provision of visualizations. Visualizations 802-2 includes one or more visualizations (e.g., charts, graphs, maps, etc.) associated with executed operators for providing the output data in a visualization. Data exchange 802-3 does. Persistence 802-4 does.

[0061] FIG. 9 illustrates an example flow with execution statistics, in accordance with an example implementation. Each of the flow symbols a, b, c, d, e, and f represent different types of output data from each operator. That is, each symbol a represents similar data of a first type, each symbol b represents similar data of a second type that is different from the first type and so on. In an example from FIG. 12, data type a represents Data_l, b represents Data_2 and so on.

[0062] The flow starts at the start point (S) 900. Suppose the user wants to select wells in a county and then find out which wells look similar in terms of their production behavior, and for the wells in each cluster, forecast their future behavior. In a first selection, the filter operator (Sel) 901 is used to select wells from the country. The filter operator 901 outputs the set of well IDs that are selected to other operators, and outputs meta-data regarding the selected wells to the global context. For the visualization, the filter operator 901 provides the selection visualization on the map.

[0063] In the example of FIG. 9, the production similarity operator (PS) 902 is selected and attached to the filter operator. The production similarity operator clusters well ids according to their production behavior over the selected time period. The production similarity operator 902 outputs the set of well IDs associated with a selected cluster to the next operator. For the global context 904, the production similarity operator 902 outputs meta-data about the selected wells i.e. the well ID with the corresponding cluster ID, how many wells in each cluster, and so on depending on the desired implementation. For the visualization 905, the production similarity operator 902 provides information on the chart.

[0064] Further in the example of FIG. 9, the production forecast operator (PF) 903 is selected and attached to the production similarity operator. The production forecast operator 903 forecasts future production behavior of well IDs according to their production behavior over the selected time period, and outputs the set of well IDs to the other output operators. For the global context 904, the production forecast operator 903 provides meta data about the selected wells i.e. the well ID with the corresponding predicted value over the forecast horizon and the confidence level. Production forecast operator 903 can provide the production forecast in chart form for visualization 905. Global Context (GC) 904 at each step combines the context of the flow until that step. Visualization (Viz) 905 reads from GC to display the charts and maps. The flow ends at the finish point (F) 906.

[0065] The example flow above can be represented in form of a non-finite automaton (NFA) as described below. The NFA can involve states (corresponding to the analytical operators) and alphabets for transition (corresponding to output from each operator) including ε, a special alphabet for transitions that require no output passing. The NFA can be converted to deterministic finite automaton (DFA) using subset construction algorithm shown below. The states of DFA are denoted by SdFA. 8-Closure(A) is the set of states covered by ε transitions from A including A. TransitionNFA (S\ alphabet) is the set of transitions possible from S' in NFA. TransitionDFA (S', alphabet) is the corresponding transition set in DFA. Provided below is an example of the pseudo code for the transition.

1. Initialize SDFA = { }

2. SDFA= SDFA U ε -Closure(S*) // S* is start state of NFA

3. Uncheck SDFA

4. While SDFA has an unchecked state do

• Let S' be that unchecked state

• Check S'

• for each alphabet in the list of alphabets do

S" = TransitiondFA (S\ alphabet) =ε- closure(TransitionNFA(S ' , alphabet))

if S" is not in SDFA already then

SDFA= SDFA U S"

Uncheck S"

end If

Set TransitionDFA(S',alphabet) to S"

endFor

endWhile

5. for each State S in SDFA do

if any s ε S is a final state in the NFA then

Check S an a final state in the DFA

endlf

endFor

[0066] The DFA can then be converted to regular expression using different methods including Brzozowski Algebraic Method. Conversion to regular expressions leads to efficient storage of the flows and enables comparison between flows.

[0067] FIG. 10 illustrates a flow ID table, in accordance with an example implementation. The operator of the management server may create one or more flows for visualization, which can be saved and loaded later. Flow ID table manages the storage of such flows, and associates an identifier for each created flow. Each flow may involve one or more sequences of operators. When the user is operating the management server and is working on a sequence of operators, the present sequence may be provided on the visualization pane for creating operators.

[0068] FIG. 11 illustrates an operator table, in accordance with an example implementation. The operator table provides an index of operators that are selectable by the user in constructing the flows. Operators may be standard operators in the domain, or can involve custom operators depending on the desired implementation. Operator table may include the operator identifier and the information passed to the global context from the execution of the operator. Each operator can belong to an upstream process such as exploration, drilling, completions and production. The purpose of the operator is to perform a specific job related to the corresponding process. In example implementations, the user is allowed to choose the operator based on the desired hypothesis to be tested.

[0069] FIG. 12 illustrates flow information, in accordance with an example implementation. Flow information is an illustration of an expansion of a flow from flow ID table in FIG. 10. In the example of FIG. 12, flow information includes a sequence of one or more operators, organized by operator ID. Flow information can also include previous operator information to identify the prior operator in the sequence to the operator ID, as well as the data sent to the global context. In the example illustrated in FIG. 12, two operators (clustering and similarity) are appended to the first operator, which is the selection operator. In example implementations, it is possible to rollback the flow to a desired operator in the sequence, and then append another operator to the rollback operator. In the example of FIG. 12, the end operator is the production forecasting operator. Suppose the user traverses the sequence back to the selection operator. In this example, the visualization pane of FIG. 6 will revert back to the visualization as presented during when the selection operator was the end operator. This is made possible by the global context information, which can be parsed to retrieve all the output data up to the end operator (Data_l) and update the visualization from the data. Now, suppose the user selects the similarity operator during the visualization for the selection operator. The end operator is set to the similarity operator, and the output data (data_4) is sent to the global context information for generating the visualization. In this example implementation, the context of both flows is maintained, allowing the user can revert to any of the operators in the sequence as desired. Thus in example implementations, flows can be forked and processed inline while preserving the original flows as illustrated in FIG. 12. An example illustration of the resulting flow is provided in FIG. 14.

[0070] FIG. 13 illustrates an example flow diagram for inline operator construction, in accordance with an example implementation. At 1301, the inline operator process waits for a selection of a domain operator. At 1302, once a selection is received, the operator is processed which can involve appending the selected operator to the end operator of the present sequence in the user interface, and updating the flow accordingly as illustrated in FIG. 6. At 1303, information regarding the subject analysis of the selected domain operator is provided to the selected operator for processing and inline execution. At 1304, the domain operator is executed inline. At 1305, output from the executed operator is provided to the general context in accordance with the table information of FIG. 11. At 1306, data is stored in the general context for later use should the user decide to roll back the sequence of flows to the operator. At 1307, based on the end operator (e.g., the selected operator appended to the end operator), the data in the general context is sent to the visualization for providing an associated visualization. At 1308, a determination is made as to whether the user is done with the flow. If so (N), the flow ends, otherwise (Y), the flow proceeds back to 1301 to wait for the next domain operator.

[0071] FIG. 15 illustrates an example flow and data sent to the global context in accordance with an example implementation. In the example flow of FIG. 15, there is a well selection operator, a production clustering operator, and an appended production forecasting operator. The well selection operator has an operator ID of 1 and provides data of well IDs to the global context information. The production cluster operator has an operator ID of 2 and provides data of well IDs, selected clusters of wells, and production values for each cluster to the global context information. The production forecast operator has an operator ID of 3 and provides data of well IDs, selected clusters and forecasted production values for each cluster to the global context information.

[0072] FIG. 16(a) and 16(b) illustrate an example transition of the visualization, in accordance with an example implementation. In FIG. 16(a), the visualization is provided by the production cluster operator, which clusters the provided wells into three clusters. The operator is executed to determine the production values for each of the cluster of wells, which is provided as the visualization in FIG. 16(a). Upon appending the production forecasting operator to the flow as illustrated in FIG. 6, the visualization is updated based on the information in the global context information, and the forecasted production values of each of the clusters is provided in the visualization.

[0073] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.

[0074] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing," "computing," "calculating," "determining," "displaying," or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.

[0075] Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

[0076] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers. [0077] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.

[0078] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.