FIG. 3. Alternatively, where it is determined that the well report is already in an electronic format (block 204), it is converted into the interim electronic format (block 230). This conversion may be done, for example, using the method discussed below in relation to FIG. 4.

Information from the converted well report that corresponds to fields in the defined well report format is extracted from the interim electronic format (block 232). This extracted information is assembled to yield a well report in the defined well report format. A time and date of the well report from the historical archive is included in the well report. As mentioned above, in some embodiments, the defined well report format is an Excel™ spreadsheet, and thus the well report is an Excel™ spreadsheet. Based upon the disclosure provided herein, one of ordinary skill in the art will recognize other defined electronic formats that may be used in relation to different embodiments. This well report is stored to a current database (block 236). The current database is accessible to one or more other processing resources and/or processes, and as more fully discussed below can be used along with thousands of other well reports to generate, among other things, a well property.

It is determined whether there are other well reports in the historical archive that remain to be processed (block 238). Where one or more well reports remain to be processed (block 238), the processes of blocks 222-236 are repeated for the next well report.

Turning to FIG. 2C and following flow diagram 249, it is determined whether the real-time report flag has been set (block 250). Where it is set (block 250), the real-time report flag is unset in preparation for the next real-time well report being loaded by the logging system into the current database (block 252). Any new well reports corresponding to the well being analyzed are merged into a PVT property profile for the well (block 254). This process results in a combining of data from recently generated well reports into a continuing PVT property profile. As such, a PVT property profile includes an increasing amount of data over time. An analysis of the PVT property profile to the well is accessed from the current database is performed (block 256). For a well that has been in existence for a long time the PVT property profile may represent data gathered from the well which was included in tens, hundreds, thousands, or even tens of thousands of times. Thus, the analysis includes not only a recently received well report, but potentially thousands of well reports that were in part accessed from the historical archive. By performing the analysis upon setting of the real-time report flag, well properties generated by the analysis can be generated in real-time as each well report is received from a logging system. Accordingly, some embodiments provide an ability to generate a well property based upon thousands of well reports in real-time. One embodiment showing an analysis process is discussed below in relation to FIG. 7.

In addition, it is determined whether an analysis has been requested (block 258). An analysis may be requested, for example, by a user operating well property prediction system 180. Upon receiving a request to perform an analysis (block 258), any new well reports corresponding to the well being analyzed are merged into the PVT property profile for the well (block 254). Analysis of the PVT property profile from the current database is performed (block 256). This analysis may include well reports stored to current database 170 by logging system 160 and well reports stored to current database 170 by archive conversion system 174. Again, the well reports stored to current database 170 by archive conversion system 174 may be generated from thousands of well reports maintained in historical archive 172.

Turning to FIG. 3, a flow diagram 300 shows a method for converting a well report accessed from a historical archive to an electronic format in accordance with one or more embodiments. In one or more embodiments, one or more of the blocks shown in FIG. 3 may be omitted, repeated, and/or performed in a different order than the order shown in FIG. 3. Accordingly, the scope of the invention should not be considered limited to the specific arrangement of blocks shown in FIG. 3 Following flow diagram 300, each page of a well report accessed from the historical archive is scanned to yield an image (block 302). Each page of the well report may be converted at a desired resolution based on the quality of the well report. In some embodiment, the resolution is, for example, 96 dpi. In other embodiments, the resolution is 300 dpi or greater to enhance the accuracy of OCR processes. Based upon the disclosure provided herein, one of ordinary skill in the art will recognize a variety of resolutions that may be used in relation to different embodiments.

Image processing is applied to the image in portrait orientation to remove noise and artifacts (block 308). Such image processing may include one or more processes including, but not limited to, erosion and dilation.

It is determined whether the image is in an upright portrait (block 304). If the orientation is determined not to be an upright portrait (e.g., the image is upside down or in landscape orientation) (block 304), the image is rotated to portrait orientation (block 306).

Text data from the image is extracted (block 310). In some embodiments, extraction of the text data is done using OCR. OCR may be achieved using standard tools such as Tesseract. The OCR may produce a data frame which consists of both the text data as well as coordinate information of the text data on a page, in blocks, paragraphs, lines, and sentences. These can be further parsed, following the coordinate information, to produce a structured text file or a spreadsheet. Additionally, OCR may be machine learning based.

Page layout analysis is applied on the image to convert the text boxes extracted from the original document into tables (block 312). Such page layout analysis may be a part of text/data post-processing to replace spurious OCR results such as strange symbols, and incorrectly converted numeric values and letters. Context analysis is applied to the tables to correct any errors that occurred in the extraction process (block 314). The context analysis may include any process known in the art for considering text in its context to identify incongruities which may be errors. As an example, the text may be compared with words around it to determine, when there is some ambiguity, that there are other similar words in the context that were recognized without ambiguity. Based upon the disclosure provided herein, one of ordinary skill in the art will recognize a variety of context analysis that may be used in relation to different embodiments to correct errors.

Using the method described in FIG. 3, an accurate data set is provided for OCR using machine learning. Such machine learning algorithms or models may include, but are not limited to, generalized linear models, Bayesian regression, random forests, and deep models such as neural networks, convolutional neural networks, and recurrent neural networks. Machine-learned model types, whether they are considered deep or not, are usually associated with additional “hyperparameters,” which further describe the model. For example, hyperparameters providing further detail about a neural network may include, but are not limited to, the number of layers in the neural network, choice of activation functions, inclusion of batch normalization layers, and regularization strength. Commonly, in the literature, the selection of hyperparameters surrounding a model is referred to as selecting the model “architecture.”

FIG. 4 is a flow diagram 400 showing a method for converting a well report in an electronic format accessed from a historical archive to a defined electronic format in accordance with one or more embodiments. Of note, in some embodiments where the well report is in an electronic format such as, for example, PDF format that already includes text information including the position and the content of each word, there is no need to convert the page into an image as discussed in relation to FIG. 4, but rather the OCR process can be skipped and the table extracted directly from the text information in the electronic document. Flow diagram 400 is substantially the same as flow diagram 300 discussed above in relation to FIG. 3, except that block 402 includes converting the accessed well report into an image. The remaining processes are the same as those discussed in relation to FIG. 3 and result in the extracted text data in the same defined electronic format.

Turning to FIG. 5, a block diagram 500 depicts an example workflow in accordance with some embodiments for performing analysis based at least in part on well reports available in a historical archive in paper form. As shown in block diagram (500) well reports are accessed from a historical archive (502). The well reports include PVT data. The pages of the accessed well reports are scanned (504) to yield one image of each page of the well reports (506).

Parsing and extraction processes are applied to the images by a parsing/extraction engine (508) to yield raw OCR outputs. The raw OCR outputs from the parsing/extraction engine (508) are converted to three different formats: (1) text documents (510) that may be formatted as *.txt files, (2) annotated images (520) that may include recognized text annotated on the images in green boxes, and (3) tables (512) that may be formatted as as *.xls files. All of these three types of files are stored to a current database (514). In some embodiments, a PVT property profile may include a combination of the three types of files for a given well. he stored PVT property profile may be used for individual well PVT property profile visualization (516), PVT data analysis (522), and data management processes (518). Such data management processes may include, but are not limited to, modifying data in the current database (514), deleting data from current database (514), and/or filtering data in the current database (514). As one of many examples, data management may create different subsets of the database for different purposes, including clustering, training inference models, or predicting unknown PVT property profiles.

In one or more embodiments, PVT property profiles (516) may be individual or multiple PVT property profiles. In addition, PVT property profiles (516) may be in a compressed file format such as a ZIP file. Further, scanned documents (504) may be portable document file (PDF). The images (506) may be in, but not limited to, BMP, JPEG, TIFF, GIF.

PVT property profile visualization (516) may provide PVT property data anomaly detection, PVT sample clustering/comparison, PVT sample classification, and/or PVT property prediction. For example, PVT properties of multiple wells may be plotted in multiple curves on the same pressure or temperature range, and be overlayed on top of each other for visual comparison and anomaly identification. In some embodiments, PVT data analysis (522) may be run at times other than after PVT property profile visualization (516). Such analysis may include, but is not limited to, machine learning training and testing. PVT data analysis (522) may provide PVT property data anomaly detection, PVT sample clustering/comparison, PVT sample classification, and/or PVT property prediction. For example, PVT properties of multiple wells may be plotted in multiple curves on the same pressure or temperature range, and be overlayed on top of each other for visual comparison and anomaly identification.

Further, PVT data may be interpolated and extrapolated along pressure and temperature axes within which the PVT properties are measured for unsupervised analysis including PVT sample clustering, and for supervised learning for PVT property prediction on missing data or offset wells, based on data from measured wells. The PVT sample clustering provides a score showing how much clusters are separated. The PVT sample clustering also provides multiples metrics not limited to the R-squire value and the contribution scores of input data.

The PVT property prediction may be used to determine: (1) characterization of specific reservoir/well's fluid behavior under certain conditions, such as bubble point; (2) the differential as well as the flash liberation process where gas is separated from liquid sample; (3) the reservoir/well to surface volume relations; (4) oil/gas formation volume factor—the ratio of oil/gas volume at the reservoir pressure and temperature condition versus those at the surface; and/or (5) the composition of the oil/gas extracted from the reservoir/well.

In one or more embodiments, a user may customize which data from the tables in the current database to use as inputs or outputs for PVT data analysis according to a specific needs.

Turning to FIG. 6, a block diagram 600 shows functions of the parsing and extraction engine processes of the workflow of FIG. 5. As shown, parsing/extraction engine (508) includes functions of: orientation (602), image processing (604), image annotation (610), text/data extraction (606), text/data pre-processing (612), tabular data extraction (614). text/data post-processing (608), and export (616).

As mentioned above, some embodiments may incorporate workflow-based parallelism to accelerate the tasks performed as part of the workflow. Such parallelism is shown in FIG. 6 where one or more of orientation (602), image processing (604), image annotation (610), text/data extraction (606), text/data pre-processing (612), tabular data extraction (614). text/data post-processing (608), and/or export (616) are performed in parallel independent of one or more of the other processes. The processes may be deployed in one or both of multithreading and multiprocessing architectures. Various embodiments provide reports which, if workflow-based parallelism is ignored, the processing of such reports may be divided into the following steps:

- 1. FileRead, used for scheduling the tasks of page parsing.
- 2. Preprocessing, including image enhancement and annotations.
- 3. OCR, including the text information extraction. No tabular data is provided in this step.
- 4. TableExtraction, including the text correction and the tabular data extraction based on the layout analysis.
  
  An example of such flow was discussed above relation to FIG. 4.

In some embodiments, for each kind of task, several workers 650 (i.e., a worker 650a, a worker 650b, a worker 650c, and/or a worker 650d) are allocated. For example, if multiprocessing is used, there may be ten (10) processes waiting for preprocessing tasks and twenty (20) tasks waiting for optical character recognition (OCR) tasks. In this way, different steps can be run simultaneously. Suppose that the first page of the first report has been preprocessed just now. Then, there should be one worker working on OCR of the same page, while the preprocessing worker will be processing the next page now. As just one of many benefits, embodiments provide for splitting of the computation and I/O. For all tasks, saving the results is always scheduled at the end of the task. Before saving the file, the data processed by the current task will be delivered to another task working for the next step. In this way, the I/O and the computation may be allowed to run simultaneously. This provides balance between the processing and the I/O.

Image processing (604) removes noise and artifacts from an image to make the image clearer. Orientation (602) determines a page orientation of an image, and rotates the page orientation image to portrait mode if the image is not in portrait mode. Image annotation is applied (610) which may include, for example, highlighting all text extracted using OCR with colored boxes.

Text/data extraction (606) provides layout analysis and text/table extraction via machine learning based OCR. For example, OCR may be trained with customized models to process specialized PVT reports. In the text/data extraction (606), texts from an image are extracted via OCR as a raw OCR file. The OCR recognizes the word position, size, and key phrase used in well reports. The resulting text files may be arranged as *.txt files.

Text/data pre-processing (612) is performed which operates to correct any errors (e.g., typographical errors) in the recovered text on a word-by-word basis (i.e., without using context to correct errors). Tablular data extraction (614) is applied to the text are tabulated in a correct table format The table is not necessarily pre-defined. In some embodiments, the table definition is inferred from the position of text (information included with the raw OCR) in the original document image. In some cases, one or more table layouts are detected from the raw OCR file by estimating each table column's horizontal location. Then, the texts are tabulated in a correct table format.

Tabular data post-processing (608) provides filtering and sorting of the extracted tables, and correcting text recognition errors. For example, for each extracted table, the possibility of whether this table belongs to a required table type is evaluated by scoring. If the score is lower than a predetermined threshold, the table will be dropped from the extracted tables. If there are multiple tables belonging to the same type, all the tables will be preserved and sorted in the descending order of their corresponding scores.

Further, if any recognized text via OCR matches one or more errors in a correction rule, the corresponding correction will be automatically applied. In some embodiments, a user may provide a customized configuration file that contains the correction rule. The correction rule may be categorized to: (1) regular expression rules that may allow users to replace some text matching the given regular expressions for removing or correcting wrong punctuation; and (2) fuzzy text matching rules that may allow users to replace phrases with the correct ones if there are any missing, extra, or incorrect characters in whole or a part of the phrase. In one or more embodiments, a user may be allowed manual correction by downloading, modifying, and re-uploading the extracted one or more tables, if any table data is incorrectly recognized and extracted.

Additionally, if recognized data via OCR is incomplete or outliers, the incomplete or outlier data will be removed. In some cases, these low-quality data are preserved in the extracted tables, and a user may be allowed to correct them manually.

In one or more embodiments, the preserved low-quality data may be filtered out during a machine learning process. Additionally, parallel computing techniques may be used to improve computing resource utilization by simultaneously processing different pages of the same or different reports.

Export (610) stores corrected extracted text/data to one or more text documents (510), to one or more tables (512) in table form (e.g., a spreadsheet format), and/or to one or more annotated images (520) (e.g., a PDF format or a JPG format).

Turning to FIG. 7, a flow diagram 700 shows a method for automated well property prediction based upon a plurality of individual well reports in accordance with some embodiments. More specifically, flow diagram 700 includes a method for performing PVT data analysis including training a machine learning model based upon PVT data from wells. In one or more embodiments, one or more of the blocks or steps shown in FIG. 7 may be omitted, repeated, and/or performed in a different order than the order shown in FIG. 7. Accordingly, the scope of the invention should not be considered limited to the specific arrangement of blocks or steps shown in FIG. 7.

Following flow diagram 700, a plurality of well reports are accessed or obtained from a current database (block 702). This may include, for example, accessing a historical archive to access a number of well reports corresponding to a plurality of different wells. In some cases, these well reports may already be in an electronic format and in other cases they are in paper form. Where they are in paper form, the obtaining includes scanning the paper documents to render the well report in electronic form. The plurality of PVT reports may be obtained by a user uploading individual, multiple or zipped PVT reports into a report management system.

PVT data is automatically extracted from the plurality of well reports that were obtained (block 704). The PVT data may be extracted either individually or in batch mode. Embodiments of methods including obtaining well reports and extracting PVT data therefrom are discussed above in relation to FIGS. 3-4

The extracted PVT data is automatically incorporated into a plurality of tables for each of the respective well reports (block 706). In some embodiments, this may include exporting the extracted PVT data to a spreadsheet such as an Excel™ file with each sheet of the Excel™ file capturing a PVT table including PVT data. The original page images, layout annotated page images, and text files for each page of a well report may be exported, and made available for a user to review.

The plurality of tables corresponding to each well are automatically merged into a PVT property profile for each of the respective wells included in a current database (block 708). The current database includes a PVT property profile for each of the wells that is updated each time additional PVT data becomes available for the respective well. In some embodiments, the current database is a relational database management system such as Oracle or other database system.

A PVT property profile for a selected well is selected from the current database (block 710). In some embodiments, the PVT property profile includes a PVT table derived from multiple well reports corresponding to the selected well and accessed from a historical archive, and/or well data from the selected well provided directly from a logging system.