Patent Description:
Due to operational restrictions and limitations in the number of multi-physical measurements that can be carried out downhole at any one logging run, multiple logging 'passes' are typically carried out with the measurement string made of separate devices at each run at the exception of a few key measurements such the gamma ray (GR). GR measurements are used in each logging pass with the objective to provide formation responses that can be used to match or synchronize the logs from the various logging passes. The synchronization between the various measurement logs is critical for identifying correlation between dissimilar measurements and help support the integrated inversion of multiple physical data to provide a consistent common formation model.

As mentioned above, due to differing environmental perturbations and tool sticking arising at each pass from irregular borehole shape or high well curvature, the GR logs from the separate passes may not match each other due to inaccurate measurement on depth. Their synchronization is not trivial especially when the formation exhibits thin laminations such as the case for the unconventional formations known to be present in the Permian or Marcellus basin. The difficulty in the synchronization of GR logs led many well log interpretation algorithms to ignore the mismatch and assume the logs to be aligned; this leads to sub-optimal interpretation at best and completely useless results at worst particularly for thinly-laminated formations.

Gamma-ray log depth matching has remained a long-standing challenge within the industry albeit it has been widely studied. Indeed, most of the synchronization techniques suffer from the following difficulties: difference in signal magnitude; different resolutions and sampling rates; distorted signals from tool sticking effects; occasional time-lapse changes due to mud invasion or borehole wall deformation between passes; and hardware and environmental noises. All these effects may lead to unreliable well log interpretation, particularly for thinly-laminated formations where small shifts may completely misalign the correlation between different logs, which impacts the interpretation quality significantly.

<NPL>, describes a technique for well-log correlation using a back-propagation neural network with an input layer in the form of a tapped delay line which is trained on well logs to recognize a particular geographical marker, Subsequently, the neural network proposes locations for this marker in other wells. A second neural network determines secondary markers using well logs and a depth reference to the first marker.

In a first aspect, the present invention resides in a computer-implemented method for well log depth matching as defined in claim <NUM>. The method addresses the above-noted depth matching problem using a machine learning based approach. To allow automated data interpretation, the well log depth matching method of the present invention includes a robust and fully automatic algorithm for depth matching gamma-ray logs, which is used as a proxy to match the depth of well logs measured in multiple logging passes. This is realized by training a neural network (NN). The well log depth matching method uses data augmentation, which permits the process to obtain, from very limited data labeled manually, a sufficiently large dataset for training. To push the performance at a fully automated level, the well log depth matching method may employ different stacking and filtering methods, leading to nearly perfectly synchronized signals. In addition to training the neural network on real measured data, the neural network may be trained using synthetic gamma-ray logs, or realistic synthetic gamma-ray logs refined using Generative Adversarial Networks (GANs), or combinations of different data sources.

Embodiments included here are configured to match the reference depth of different well logs (e.g., using gamma-ray logs). Well logging is the process of recording various physical, chemical, electrical, or other properties of the rock/fluid mixtures penetrated by drilling a borehole into the earth's crust. Here, a gamma-ray log is a record of gamma-ray signals that refer to the depth along the well trajectory. Depth is a reference coordinate for the recorded signals along the well trajectory. As a reference, the depth may be recorded using special devices, which may include, but are not limited to wireline, logging while drilling "LWD", other specialized devices, etc. Once these devices have obtained the necessary information it may be provided to various computing devices such as those shown in <FIG> and as will be discussed in greater detail below.

In one or more preferred embodiments the following features may be included. At least one point in the at least one well log may be defined. A first window may be generated around the at least one point in the at least one well log. At least one corresponding point in the at least one other well log may be identified. A second window may be generated around the at least one corresponding point in the at least one other well log. Defining the at least one point in the at least one well log may include receiving a set of manually picked points of interest. Defining the at least one point in the at least one well log may include automatically generating a set of points of interest. According to the invention, determining the depth shift between the at least one well log and the at least one other well log includes performing one or more data augmentation transformations on at least one well log to generate training data for the neural network.

In one or more preferred embodiments one or more of field data, synthetic data, realistic synthetic data refined by augmentation-enabling networks and Generative Adversarial Networks (GANs), may be used for training the neural network. Matching the plurality of well logs with one another may include aligning the plurality of well logs based upon, at least in part, a plurality of anchor points. Aligning the plurality of well logs may include sampling at least one of the plurality of well logs between the plurality of anchor points.

In another aspect, the present invention resides in a computing system as defined in claim <NUM>.

This summary is not intended to identify 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.

Embodiments of the present disclosure are described with reference to the following figures.

Like reference symbols in the various drawings may indicate like elements.

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 invention. The first object or step, and the second object or step, are both objects or steps, respectively, but they are not to be considered a same object or step.

Moreover, as disclosed herein, the term "storage medium" may represent one or more devices for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information. The term "computer-readable medium" includes, but is not limited to portable or fixed storage devices, optical storage devices, wireless channels and various other mediums capable of storing, containing or carrying instruction(s) and/or data.

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine readable medium such as storage medium. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc. It is to be understood that the following disclosure provides many different embodiments, or examples, for implementing different features of various embodiments. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. Moreover, the formation of a first feature over or on a second feature in the description that follows may include embodiments in which the first and second features are formed in direct contact, and may also include embodiments in which additional features may be formed interposing the first and second features, such that the first and second features may not be in direct contact.

Referring to <FIG>, there is shown well log depth matching process <NUM>. For the following discussion, it is intended to be understood that well log depth matching process <NUM> may be implemented in a variety of ways. For example, well log depth matching process <NUM> may be implemented as a server-side process, a client-side process, or a server-side / client-side process.

For example, well log depth matching process <NUM> may be implemented as a purely server-side process via well log depth matching process <NUM>. Alternatively, well log depth matching process <NUM> may be implemented as a purely client-side process via one or more of client-side application 10c1, client-side application 10c2, client-side application 10c3, and client-side application 10c4. Alternatively still, well log depth matching process <NUM> may be implemented as a server-side / client-side process via server-side well log depth matching process <NUM> in combination with one or more of client-side application 10c1, client-side application 10c2, client-side application 10c3, client-side application 10c4, and client-side application 10c5. In such an example, at least a portion of the functionality of well log depth matching process <NUM> may be performed by well log depth matching process <NUM> and at least a portion of the functionality of well log depth matching process <NUM> may be performed by one or more of client-side application 10c1, 10c2, 10c3, 10c4, and 10c5.

Accordingly, well log depth matching process <NUM> as used in this disclosure may include any combination of well log depth matching process <NUM>, client-side application 10c1, client-side application 10c2, client-side application 10c3, client-side application 10c4, and client-side application 10c5.

Well log depth matching process <NUM> may be a server application and may reside on and may be executed by computing device <NUM>, which may be connected to network <NUM> (e.g., the Internet or a local area network). Examples of computing device <NUM> may include, but are not limited to: a personal computer, a server computer, a series of server computers, a mini computer, a mainframe computer, or a dedicated network device.

The instruction sets and subroutines of well log depth matching process <NUM>, which may be stored on storage device <NUM> coupled to computing device <NUM>, may be executed by one or more processors (not shown) and one or more memory architectures (not shown) included within computing device <NUM>. Examples of storage device <NUM> may include but are not limited to: a hard disk drive; a tape drive; an optical drive; a RAID device; an NAS device, a Storage Area Network, a random access memory (RAM); a read-only memory (ROM); and all forms of flash memory storage devices.

Network <NUM> may be connected to one or more secondary networks (e.g., network <NUM>), examples of which may include but are not limited to: a local area network; a wide area network; or an intranet, for example.

The instruction sets and subroutines of client-side application 10c1, 10c2, 10c3, 10c4, 10c5 which may be stored on storage devices <NUM>, <NUM>, <NUM>, <NUM>, <NUM> (respectively) coupled to client electronic devices <NUM>, <NUM>, <NUM>, <NUM>, <NUM> (respectively), may be executed by one or more processors (not shown) and one or more memory architectures (not shown) incorporated into client electronic devices <NUM>, <NUM>, <NUM>, <NUM>, <NUM> (respectively). Examples of storage devices <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may include but are not limited to: hard disk drives; tape drives; optical drives; RAID devices; random access memories (RAM); read-only memories (ROM), and all forms of flash memory storage devices.

Examples of client electronic devices <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may include, but are not limited to, personal computer <NUM>, <NUM>, laptop computer <NUM>, mobile computing device <NUM>, notebook computer <NUM>, a netbook computer (not shown), a server computer (not shown), a gaming console (not shown), a data-enabled television console (not shown), and a dedicated network device (not shown). Client electronic devices <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may each execute an operating system.

Users <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may access well log depth matching process <NUM> directly through network <NUM> or through secondary network <NUM>. Further, well log depth matching process <NUM> may be accessed through secondary network <NUM> via link line <NUM>.

The various client electronic devices (e.g., client electronic devices <NUM>, <NUM>, <NUM>, <NUM>) may be directly or indirectly coupled to network <NUM> (or network <NUM>). For example, personal computer <NUM> is shown directly coupled to network <NUM>. Further, laptop computer <NUM> is shown wirelessly coupled to network <NUM> via wireless communication channels <NUM> established between laptop computer <NUM> and wireless access point (WAP) <NUM>. Similarly, mobile computing device <NUM> is shown wirelessly coupled to network <NUM> via wireless communication channel <NUM> established between mobile computing device <NUM> and cellular network / bridge <NUM>, which is shown directly coupled to network <NUM>. WAP <NUM> may be, for example, an IEEE <NUM>. 11a, <NUM>. 11b, <NUM>, <NUM>. 11n, Wi-Fi, and/or Bluetooth device that is capable of establishing wireless communication channel <NUM> between laptop computer <NUM> and WAP <NUM>. Additionally, personal computer <NUM> is shown directly coupled to network <NUM> via a hardwired network connection.

In some implementations, a client electronic device (e.g., client electronic device <NUM>) may be electronically coupled to at least one recording device <NUM> (e.g. gamma-ray too, wireline, LWD, etc.). As will be discussed in greater detail below, device <NUM> may be configured to be deployed into, or adjacent, a well (e.g., well <NUM>) or other structure.

In some embodiments, well log depth matching process <NUM> may communicate with, interact with, and/or include a component or module of a well log application (e.g., well log application <NUM>).

In an embodiment, the instruction sets and subroutines of well log application <NUM> may be stored, e.g., on storage device <NUM> associated with server computer <NUM>, which executes well log application <NUM>, and/or another suitable storage device. Further, users (e.g., one or more of users <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) may access well log application <NUM> in order to access well logs and other data received from device <NUM> or other mechanisms. The users may access well log application <NUM> via one or more suitable applications, such as client side applications 10c1-10c5 (e.g., which may include a web browser, a client electronic meeting application, or another application) and/or via a different application (not shown). Additionally, while some users are depicted as being connected with server computer <NUM> (and therefore with electronic well log application <NUM>) via network <NUM>, which may include the Internet, in other embodiments, one or more users may be directed connected to server computer <NUM> and/or connected with server computer <NUM> via, e.g., a local area network and/or similar connection.

As generally discussed above, a portion and/or all of the functionality of well log depth matching process <NUM> may be provided by one or more of client side applications 10c1-10c5. For example, in some embodiments well log depth matching process <NUM> (and/or client-side functionality of well log depth matching process <NUM>) may be included within and/or interactive with client-side applications 10c1-10c5, which may include client side electronic well log applications, web browsers, or another application. Various additional / alternative configurations may be equally utilized.

As discussed above and referring also at least to <FIG>, well log depth matching process <NUM> may receive <NUM> a plurality of well logs. A depth shift between at least one well log of the plurality of well logs and at least one other well log may be determined <NUM> based upon, at least in part, processing the plurality of well logs with a neural network. The plurality of well logs may be matched <NUM> with one another based upon, at least in part, the depth shift between the at least one well log and the at least one other well log.

In some implementations, well log depth matching process <NUM> may receive <NUM> a plurality of well logs. For example and in some implementations, well log depth matching process <NUM> may receive <NUM> a plurality of well logs from a plurality of sources. For example, a gamma-ray tool may be configured to record naturally occurring gamma rays in formations adjacent to a wellbore. In some implementations, the gamma-ray tool may comprise at least a portion of a recording device (e.g., recording device <NUM>) deployed into, or adjacent, a well (e.g., well <NUM>) or other structure. In some implementations, a log of the gamma-rays may be recorded and used for e.g., correlation between wells. For example, a well log of the total natural radioactivity may be measured. The measurement can be made in both openhole and through casing. The depth of investigation may be a few inches, so that the log normally measures the flushed zone. Shales and clays are responsible for most natural radioactivity, so the gamma ray log often is a good indicator of such rocks. However, other rocks are also radioactive, notably some carbonates and feldspar-rich rocks. The log is also used for correlation between wells, for depth correlation between open and cased hole, and for depth correlation between logging runs.

As discussed above, due to operational restrictions and limitations in the number of multi-physical measurements that can be carried out downhole at any one logging run, multiple logging 'passes' are typically carried out with the measurement string made of separate devices at each run at the exception of a few key measurements such the gamma ray (GR). GR measurements are used in each logging pass with the objective to provide formation responses that can be used to match or synchronize the logs from the various logging passes. As such, the synchronization between the various measurement logs may be critical for identifying correlation between dissimilar measurements and help support the integrated inversion of multiple physical data to provide a consistent common formation model.

As mentioned above, due to differing environmental perturbations and tool sticking arising at each pass from irregular borehole shape or high well curvature, the GR logs from the separate passes may not match each other due to inaccurate measurement on depth. Their synchronization is not trivial especially when the formation exhibits thin laminations such as the case for the unconventional formations known to be present in the Permian or Marcellus basin. The difficulty in the synchronization of GR logs led many conventional well log interpretation algorithms to ignore the mismatch and assume the logs to be aligned; this leads to sub-optimal interpretation at best and completely useless results at worst particularly for thinly-laminated formations. In some implementations, the plurality of well logs may be acquired during the same pass through a well. In some implementations, the plurality of well logs may be acquired during different passes through a well. In some implementations, the received <NUM> well logs may be associated with the same well. For example and as will be discussed in greater detail below, well log depth matching process <NUM> may correlate different well logs based upon, at least in part, a depth shift between at least two well logs.

As will be discussed in greater detail below and in some implementations of the present disclosure, well log depth matching process <NUM> may be hypothesized on a worst-case scenario based on empirical evidences, to yield a maximum shift between well logs. As an example, assume a maximum depth shifting of e.g., <NUM> inches. To take advantage of that assumed maximum depth shifting, consider the highest sampling rate of the gamma-ray logs to be at e.g., <NUM> inch between samples. In some implementations, given a point of interest in a reference gamma-ray (GR) signal, it may be expected that well log depth matching process <NUM> finds the corresponding point in a desynchronized GR within e.g., ±<NUM> data points. This may be a very liberal assumption in that the mismatch is expected to be much less than the extreme of <NUM> depth points - for a typical logging sampling of e.g., ½ foot, <NUM> depth points may correspond to <NUM> feet which is well above the mismatch levels typically encountered even in highly-laminated formations with irregular boreholes.

In some implementations, well log depth matching process <NUM> may determine <NUM> a depth shift between at least one well log of the plurality of well logs and at least one other well log based upon, at least in part, processing the plurality of well logs with a neural network. For example and in some implementations, well log depth matching process <NUM> may utilize machine learning (e.g., at least one neural network). For example, the machine learning problem of well log depth matching process <NUM> may be rephrased as follows: given a point of interest in a reference signal Sref, find the corresponding point in a desynchronized signal Sdesync, where the point of interest is pre-proposed by some algorithm, such as simply representing the peaks in the signals. It should be noted that in some cases, the reference signal may correspond to a small section of the reference log around a reference point, which may be defined by a window size, e.g., in some examples included herein a window of <NUM> points is used.

In some implementations and as will be discussed in greater detail below, well log depth matching process <NUM> may include a fully connected neural network, as conceptually depicted in <FIG>, with Parametric Rectified Linear Unit (PReLU) activation functions or other activation functions, as known in the art. The number of hidden layers and neurons of the network may be determined with hyper-parameter optimization (HyperOpt), during which an optimum network performance may be sought.

In some implementations, determining <NUM> the depth shift between at least one well log of the plurality of well logs and at least one other well log based upon, at least in part, processing the plurality of well logs with a neural network may generally include interpolating a reference signal (Sref) and a desynchronized signal (Sdesync) to match their sampling rates.

In some implementations, determining <NUM> the depth shift between at least one well log of the plurality of well logs and at least one other well log may include defining at least one point in the at least one well log and identifying at least one corresponding point in the at least one other well log. For example, defining at least one point may include defining <NUM> a point of interest. In some implementations, well depth log matching process <NUM> may define <NUM> one or more points of change in the at least one well log (e.g., a peak in the reference signal (Sref)). It will be appreciated that any portion of the reference signal may be used as a point of interest. For example, local minima, a local maxima, a high contrast sharp transition, etc. may be defined <NUM> as the point of interest.

In some implementations, determining <NUM> the depth shift between at least one well log of the plurality of well logs and at least one other well log may include creating a window a point of interest in the reference signal (Sref). In some implementations, well log depth matching process <NUM> may generate <NUM> a first window of e.g., <NUM> points (a center point ± <NUM> points in each direction) around the defined point of interest. For example, and as shown in <FIG>, well log depth matching process <NUM> may generate a first window of size e.g., <NUM> (e.g., window <NUM>) around center point (e.g., defined point of interest <NUM>) of a least one well log (e.g., reference signal (Sref)).

In some implementations, defining <NUM> a point of interest in the at least one well log may include receiving <NUM> a set of manually picked points of interest. For example and in some implementations, a user (e.g., an expert) may define certain points (e.g., peaks) in the at least one well log (e.g., reference signal (Sref)). In some implementations, defining <NUM> a point of interest in the at least one well log may include automatically generating <NUM> a set of points of interest. For example, it may be clear that matched signals (e.g., reference signal (Sref) and desynchronized signal (Sdesync)) are of the same type as the training ones, e.g., mainly peaks as used by human annotators. By doing so, the following may not be considered problematic: which points a user labels as good features vs. which points would maximize the accuracy/performance of the model. Namely, some non-peak points might maximize the accuracy better than the peaks. For example, defining only peaks as points of interest, in this example, as a human annotator may so choose, may not always allow the depth shift to be determined as accurately. In some implementation, the automatic generation <NUM> of points may generally be referred to as a point proposal technique. In some implementations, incorporating the point proposal technique within the machine learning model of well log depth matching process <NUM> may improve the performance, since the model could potentially then choose to fallback to selecting peaks if that is what maximizes the accuracy.

This technique could be summed up by the term "end-to-end back-propagation", both the point proposal and shift prediction training together towards a unified optimization. In some implementations, well log depth matching process <NUM> may employ a machine learning framework that includes both point proposal and shift prediction in the training loop of the neural network.

In some implementations, well depth log matching process <NUM> may identify <NUM> at least one corresponding point in the at least one other well log (e.g., desynchronized signal (Sdesync)). For example, well depth log matching process <NUM> may generate <NUM> a window around the same depth (e.g., where the corresponding point should be) in the desynchronized signal (Sdesync). In some implementations, well depth log matching process <NUM> may create or generate a second window of e.g., <NUM> points (a center point ± <NUM> points in each direction) around the defined point of interest. Referring again to the example of <FIG>, well log depth matching process <NUM> may generate <NUM> a second window of size e.g., <NUM> (e.g., window <NUM>) of a least one other well log (e.g., desynchronized signal (Sdesync)). In some implementations, the desired output of well log depth matching process <NUM> may be the cell index corresponding to the center of Sref. The problem may then become a problem of classification with <NUM> target classes. In this manner, well depth log matching process <NUM> may identify <NUM> at least one corresponding point in the at least one other well log (e.g., desynchronized signal (Sdesync)). For example, well depth log matching process <NUM> may determine <NUM> the depth shift by classifying each point or portion of the second window (e.g., window <NUM>) with at least the point of interest (e.g., defined point of interest <NUM>) to determine the depth shift between matching points between the first window (e.g., window <NUM>) and the second window (e.g., window <NUM>) relative to the point of interest (e.g., defined point of interest <NUM>).

In some implementations, well log depth matching process <NUM> may label e.g., <NUM> pairs from e.g., <NUM> different wells to form a dataset. In some implementations, the e.g., <NUM> pairs from the <NUM> different wells may be manually labeled. Well log depth matching process <NUM> may create one output per class for each pair of points, by sliding a window of size e.g., <NUM>. In some implementations, this may result in <NUM>*<NUM> = <NUM>,<NUM> sequences of size <NUM> x <NUM>. The creation procedure of well log depth matching process <NUM> may have at least one advantage: the resulting dataset is fully balanced. For example, because each target class has the same number of examples, well log depth matching process <NUM> may not have to re-weight the loss function and/or resample the dataset during the training phase. In some implementations, the examples of <FIG> show two of <NUM> possible outputs. As will be discussed in greater detail below, at least a portion of the dataset (e.g., <NUM>,<NUM> sequences of size <NUM> x <NUM>) may be fed or otherwise provided to well log depth matching process <NUM> to train a neural network that can be used to determine <NUM> a depth shift between at least one well log of the plurality of well logs and at least one other well log.

For example, <FIG> demonstrate an input X (e.g., window <NUM> and window <NUM> compared about point of interest <NUM>) where the correct output y will be "<NUM>" when point <NUM> is shifted as shown in <FIG> and <FIG> and an output y that will be "<NUM>" when point <NUM>' of second window <NUM>' is shifted as shown in <FIG>. For example, in <FIG>, the peak (corresponding to the peak in the reference log) in the desynchronized log (i.e., the peak in the desynchronized log) is located in the grid cell with index #<NUM> (index starting from <NUM>). In <FIG>, the peak in the desynchronized log is located in the grid cell #<NUM> (index starting from <NUM>). It will be appreciated that while <FIG> show only <NUM> grid cells (for the sake of easy visualization), there may be any number of grid cells. In some implementations, these outputs of y may be generally referred to as "labels". In some implementations, these labels or outputs of y may be used by well log depth matching process <NUM> to determine the depth shift between the well logs.

As discussed above and in some implementations, well log depth matching process <NUM> may determine <NUM> a depth shift between at least one well log of the plurality of well logs and at least one other well log based upon, at least in part, processing the plurality of well logs with a neural network. To feed inputs to the fully connected network (as shown in <FIG>), well log depth matching process <NUM> may concatenate the inputs horizontally and model the architecture to output a probability over the possible shifts: <MAT> <MAT>.

In some implementations, the retained shift has the highest probability: <MAT>.

Accordingly, well log depth matching process <NUM> may determine <NUM> the depth shift with the highest probability from a plurality of possible shifts from the neural network. Embodiments of the present disclosure may improve the accuracy of the depth shift and accordingly the correlation between a plurality of well logs. For example and as will be discussed in greater detail below, the correlation between well logs may be dependent upon determining the depth shift between well logs. In this manner, well log depth matching process <NUM> may improve the accuracy of the determined depth shift by improved training of the neural network as discussed below.

In order to create a more robust machine learning system, determining <NUM> the depth shift between at least one well log of the plurality of well logs and at least one other well log includes performing <NUM> one or more data augmentation transformations on at least one well log to generate training data for the neural network. For example, the one or more data augmentation transformations on the at least one well log may permit well log depth matching process <NUM> to cover unexplored input space, improve the generalization capacities, and prevent over-fitting. For example, well log depth matching process <NUM> may need label-preserving transformations and therefore prior knowledge about the invariant properties of the data against X or Y transformations. In some implementations of data augmentation, during the training phase, well log depth matching process <NUM> may pull M samples from the sequences (e.g., as discussed above) and randomly apply one or more of the following data augmentation transformations:.

In some implementations, this new group of M samples, processed and non-processed, may form a training batch for one gradient update. In some implementations, "one gradient update" may generally refer to one training step, or one iteration during the training process. In some implementations, well log depth matching process <NUM> may train uses a gradient-based optimization method.

To train, optimize, and test the neural network, well log depth matching process <NUM> may split the samples into three subsets: e.g., <NUM>% for training, <NUM>% for validation and <NUM>% for testing. Well log depth matching process <NUM> may then train the network with an Adamax optimizer and a starting learning rate of e.g., <NUM>. Well log depth matching process <NUM> may also utilize a scheduler with a patience of e.g., <NUM> to monitor the validation loss, and decrease the learning rate by a factor of <NUM> when the patience is reached. The objective function may be a standard multi class cross-entropy loss.

In some implementations, determining <NUM> the depth shift between at least one well log of the plurality of well logs and at least one other well log may include training <NUM> the neural network based upon, at least in part, an accuracy metric. In some implementations, the training and hyper-optimization phase may be monitored by well log depth matching process <NUM> with an additional metric (e.g., an ε-accuracy) on top of the conventional validation loss and accuracy. For example, due to the ambiguity of some labels, the "ground-truth" might not always be completely accurate and the use of the ε-accuracy may compensate for such cases: <MAT> <MAT>.

This accuracy metric (e.g., ε-accuracy) may prevent the training from an early stop because the exact accuracy stops increasing, but rather monitors on the convergence of predictions towards the solutions' neighborhood. For example, conventional training systems for neural networks may cease training a neural network when the conventional accuracy stops increasing as can be seen in <FIG> to prevent overfitting. As discussed above and in some implementations, due to the ambiguity of some labels, the conventional accuracy metric may not allow a neural network to be properly trained. However, by utilizing the ε-accuracy metric, well log depth matching process <NUM> may extend the training <NUM> of the neural network beyond that of conventional training of neural networks. In this manner, well log depth matching process <NUM> may enable a more robust and efficient training to the neural network by accounting for ambiguities in the labeling of training data. In some implementations, the validation set may be used to fine-tune one or more hyper-parameters (e.g., with HyperOpt) to avoid exhaustively searching in the whole space: <MAT> <MAT> <MAT> <MAT>.

In some implementations, the computation time employed for training may be about <NUM> hours with use of tree-structured Parzen Estimators (TPE). In some implementations, well log depth matching process <NUM> may obtain the following exemplary best-scoring combination: <MAT> <MAT> <MAT> <MAT>.

In some implementations, well log depth matching process <NUM> may apply dropouts between hidden layers of the neural network. A dropout may generally include a value discarded from the neural network. As known in the art, dropout generally may reduce the possibility of overfitting. In some implementations, applying dropouts between hidden layers of the neural network may be very different than the conventional dropout technique of applying a dropout directly on the input. For example, dropping between hidden layers as opposed to at the input may lead to better performance because of the fact that well log depth matching process <NUM> may deeply relate to the signals' values and shape details, like a much more robust and adaptive correlation technique. Therefore, discarding information directly from the input might cause non-unique solutions in many cases, whereas information after hidden layers is already synthesized and abstract. The training performance may be shown in <FIG>.

In some implementations, <FIG> may show the training loss with respect to the number of epochs. An epoch may generally include one full training cycle on the training set. Once every sample in the set is seen, a second epoch may begin. <FIG> may show the validation loss with respect to the number of epochs. <FIG> may show the accuracy with respect to the number of epochs. In some implementations, <FIG> may show the ε-accuracy with respect to the number of epochs. The aforementioned training procedure on the architecture as shown in <FIG> was trained with an early-stopping on both the accuracy and ε-accuracy with a patience of e.g., <NUM> epochs.

It may be observed that both validation accuracies keep increasing while the loss has passed its minimum point and starts to slightly increase. While this behavior is not common, this may be explained by the meaning of the cross-entropy loss for a multi-target classification problem. Explicitly, this loss may represent the confidence of the decision taken by the neural network. Hence, the accuracy may still improve and the certainty decreases for very difficult problems, where the probabilities are spread on neighboring points of the solution.

From the training, well log depth matching process <NUM> may keep the optimal point of ε-accuracy as the final model and obtain the following confusion matrices, on the validation and the testing set, as shown in <FIG> and <FIG>. Altematively, in numbers, well log depth matching process <NUM> may determine:.

In the above example, <NUM> pairs were manually labeled. In some implementations, the validation numbers may be more representative of the true performance from the empirical tests conducted on the inferences. In some implementations, the greatest errors are consistent as can be seen on the confusion matrices, the differences between the true shifts and the predicted ones are constant, hence the error lines parallel to the diagonal.

Now that well log depth matching process <NUM> has generated an appreciable <NUM>% ε-accuracy, well log depth matching process <NUM> may use that model to conceive a fully automated framework. When considering the typical precision-recall trade-off for determining a depth shift between well logs, i.e., getting all correct shifts versus getting only correct shifts, it is easy to settle for a very high precision, at the cost of discarding some shifts which were correctly predicted. In some implementations, well log depth matching process <NUM> may not afford wrong matching pairs, and may want retained ones to be correct. Nonetheless, well log depth matching process <NUM> may need to counterbalance this and afford discarding many points, thus well log depth matching process <NUM> may take a very loose sampling strategy for the point of interests. Namely, well log depth matching process <NUM> may take all the local minima and maxima, which typically constitutes about <NUM>% of all the points for high-resolution signals.

In some implementations, determining <NUM> the depth shift between at least one well log of the plurality of well logs and at least one other well log may include performing <NUM> one or more equality tests on the at least one well log of the plurality of well logs and at least one other well log of the plurality of well logs. For example, for each proposed point of interest, well log depth matching process <NUM> may do inference through the trained model (e.g., the neural network) and get a predicted shift by taking the maximal probability. From there, well log depth matching process <NUM> may align the windows based on, at least in part, this shift: S̃ref and S̃desync. In response to aligning the windows, well log depth matching process <NUM> may input different compositions of these two shifted signals in the model, and perform one or more of the following equality tests with the output: <MAT> <MAT> <MAT> <MAT>.

Where fliplr may stand for a vertical symmetry (left-right flip) of the signal. However, it will be appreciated that other symmetries may be used within the scope of the present disclosure.

As shown in the above equations, ideally, all should agree and output <NUM>, i.e. no shift since the signals S̃ref and S̃desync are aligned and of size <NUM>. While an output of <NUM> has been discussed, it will be appreciated that any output (e.g., based on the number of points) may be used within the scope of the present disclosure. In some implementations utilizing all four of the above equality tests and upon passing each of the equality tests, well log depth matching process <NUM> may only assess the validity of the original predicted shift. This technique is called stacking and may be a critical element allowing a fully automated framework, discarding more than <NUM>% of the unreliable predictions.

In some implementations, the plurality of well logs may be matched <NUM> with one another based upon, at least in part, the depth shift between the at least one well log and the at least one other well log. As discussed above and in some implementations, well log depth matching process <NUM> may determine <NUM> a depth shift between at least one well log of the plurality of well logs and at least one other well log. For example, well log depth matching process <NUM> may output (e.g., via the neural network) a depth shift with the highest probability.

In some implementations, matching <NUM> the plurality of well logs with one another includes aligning <NUM> the plurality of well logs based upon, at least in part, a plurality of anchor points. The following experiments were conducted on a totally unseen well during the training phase. As shown in <FIG> it may be observed that the high-resolution nature of the reference signal Sref (e.g., column <NUM>) renders the problem rather difficult even for a human. The first column, e.g., column <NUM>, may represent the desynchronized signal Sdesync, which is a low-resolution one. Nonetheless, it could also happen to be a high-resolution signal. Here, performance may be observed from well log depth matching process <NUM> even in the presence of resolution discrepancies. In some implementations, the third column (e.g., column <NUM>) may show the resulting alignment with respect to a plurality of anchor points (red lines here) of the two signals.

In some implementations, aligning <NUM> the plurality of well logs includes sampling <NUM> at least one of the plurality of well logs between the plurality of anchor points. For example, well log depth matching process <NUM> may remove redundant anchor pairs from the filtered set by simply discarding the ones which are surrounded by similar shifts gradients. In some implementations, such pairs of anchor points may be useless and may not impact the final alignment process. With this final set of matching anchor points, well log depth matching process <NUM> may resample <NUM> (e.g., linearly or nonlinearly) between the anchor points to align the signals. Referring again to <FIG> and in some implementations, the absolute shift experienced by the desynchronized signal's cable may be shown in the fourth column (e.g., column <NUM>). In at least this example, the desynchronized signal may be linearly resampled <NUM> between anchor points. In this manner, it may be observed that well log depth matching process <NUM> makes very few mistakes and would out-perform the matching capacities of a human on non-straightforward pairs.

In some implementations, embodiments of the present disclosure may cope with the issue of limited training data by receiving <NUM> well logs from a wide variety of wells, processing them with well log depth matching process <NUM> (e.g., determining <NUM> the depth shift and/or matching <NUM> the well logs based upon, at least in part, the depth shift) to automatically get anchor points and then manually assess correct ones, which can then be fed back into the learning process. In this way, well log depth matching process <NUM> may continuously improve in performance, robustness, and confidence, which will lead to a high recall even in the presence of filtering tests.

In some implementations, well log depth matching process <NUM> may be general enough to work on different signals with the appropriate training set (i.e., it is not limited to the matching of gamma ray logs). For example, thin layers where gamma-ray logs alignment may not provide enough precision, dielectric signals or other high-resolution signals may be synchronized. For example, well log depth matching process <NUM> may label dielectric signals from a single well. This is important given the implications of thin-layers alignment for the industry.

As discussed above, embodiments of well log depth matching process <NUM> may describe a viable automated workflow to the problem of depth matching through gamma-ray of logs from multiple passes. Well log depth matching process <NUM> may employ data formation to alleviate the problem's difficulty and a stacking technique to take advantage of the accuracy and reduce human intervention to essentially none.

In some implementations, well log depth matching process may address target areas of the well where shifts are expected to occur with resulting depth mismatch between various by using the cable tension and acceleration information of the at least one recording device (e.g., device <NUM>). For example, the cable tension and/or acceleration information may provide valuable information to prevent vainly trying to correct non-existing shifts, at the risk of introducing false-positives in these zones.

In some implementations, well log depth matching process <NUM> may include using field data, synthetic data, or realistic synthetic data refined by augmentation-enabling networks such as Generative Adversarial Networks (GANs), or any combinations of these for the model training.

Referring also to <FIG>, there is shown a diagrammatic view of client electronic device <NUM>. While client electronic device <NUM> is shown in this figure, this is for illustrative purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible. For example, any computing device capable of executing, in whole or in part, webpage component replication process <NUM> may be substituted for client electronic device <NUM> within <FIG>, examples of which may include but are not limited to computing device <NUM> and/or client electronic devices <NUM>, <NUM>, <NUM>.

Client electronic device <NUM> may include a processor and/or microprocessor (e.g., microprocessor <NUM>) configured to, e.g., process data and execute the above-noted code / instruction sets and subroutines. Microprocessor <NUM> may be coupled via a storage adaptor (not shown) to the above-noted storage device(s) (e.g., storage device <NUM>). An I/O controller (e.g., I/O controller <NUM>) may be configured to couple microprocessor <NUM> with various devices, such as keyboard <NUM>, pointing/selecting device (e.g., mouse <NUM>), custom device, such a microphone (e.g., device <NUM>), USB ports (not shown), and printer ports (not shown). A display adaptor (e.g., display adaptor <NUM>) may be configured to couple display <NUM> (e.g., CRT or LCD monitor(s)) with microprocessor <NUM>, while network controller/adaptor <NUM> (e.g., an Ethernet adaptor) may be configured to couple microprocessor <NUM> to the above-noted network <NUM> (e.g., the Internet or a local area network).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems and methods and according to various embodiments of the present disclosure.

As used in any embodiment described herein, the term "circuitry" may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry. It should be understood at the outset that any of the operations and/or operative components described in any embodiment or embodiment herein may be implemented in software, firmware, hardwired circuitry and/or any combination thereof.

Claim 1:
A computer-implemented method for well log depth matching, comprising:
receiving (<NUM>), on a computing device, a plurality of well logs;
determining (<NUM>) a depth shift between at least one well log of the plurality of well logs and at least one other well log based upon, at least in part, processing the plurality of well logs with a neural network, wherein determining (<NUM>) the depth shift between the at least one well log and the at least one other well log includes randomly applying one or more data augmentation transformations to subsets of samples of data sequences of the at least one well log and the at least one other well log to generate training data used to train for the neural network, the one or more data augmentation transformations comprising up-down and/or right-left flipping of the subsets of the samples of the data sequences, or applying additive Gaussian, Cauchy and/or Poisson noise to the subsets of the samples of the data sequences;
employing a stacking technique to the training data by performing (<NUM>) one or more equality tests on the at least one well log of the plurality of well logs and at least one other well log of the plurality of well logs; and
matching (<NUM>) the plurality of well logs with one another based upon, at least in part, the depth shift between the at least one well log and the at least one other well log.