What I might have done in a recent hackathon
and why domain expertise matters in machine learning
Recently, my colleague Prof. Michael Pyrcz (@GeostatsGuy) and myself hosted a data science hackathon open to students at The University of Texas at Austin with support from The Hildebrand Department of Petroleum and Geosystems Engineering. Given the COVID pandemic, we hosted the event virtually over two weekends in April 2021. The first weekend consisted of a workshop followed by an explanation of the problem dataset, then the students broke into teams and worked on their solutions that were ultimately submitted for scoring, code review, and presentation judging by a panel of industry experts the following weekend.
This was a really fun experience for me personally and the feedback has been incredible from all involved. Given that I have been teaching data science skills and challenging students in my classes with difficult coding exercises for years, it was great to see them showcase their capabilities.
I’d encourage you to take a look at the detailed problem statement and datasets linked to above, but briefly, the challenge was: given petrophysical data from well logs and spatial maps interpreted from seismic on 73 oil wells that have been in production for some time, predict the cumulative 3 year production for 10 new wells recently drilled, and having well log data, but not yet put into production. In addition to their “best estimate” the students where asked to provide 100 additional realizations such that an uncertainty model could be evaluated. The objective scoring consisted of comparisons of the mean squared error with respect to their “best estimate” and the true 3 year production (which we know, but was withheld from the students) as well as a scoring of their uncertainty model with a “goodness measure” proposed by Deutsch (1996).
I thought it would be a fun exercise to consider what I might have done to complete this challenge myself. In the spirit of the hackathon, I’ll limit my time working on the project to what I can accomplish in a single day. Of course, since I am already familiar with the dataset, I have a head start over the teams in the competition who generally spent a few hours just investigating the data the first day. But given my short timeline, I won’t be training any complicated neural network architectures or really any complicated machine learning models at all. I want to see how I can use my domain expertise to engineer meaningful features to get an answer quickly. I also have a surprise in store with respect to how I handled the uncertainty model. So let’s get started…
Feature Imputation
First, like all work in Python, I’ll start with the module imports used during this work.
And I’ll read in the well log datasets from both the wells that have been in production as well as what we call the preproduction wells, i.e. those we are trying to predict the cumulative production for after 3 years.
Now we’ll combine those two dataframes into a single dataframe.
And inspect some overall statistics on the dataset.
We can see that there is quite a bit of missing data. Of particular concern is the large amount of missing permeabilities as this will be one of the strongest indicators of production. So our first task is going to be to impute the missing features, especially working toward a good model for permeability. To start, let’s plot some of the provided map data. Here we are showing the spatial distributions of percentage facies in the reservoir. There is a fault in the reservoir which we only know the location of, but no other information. The white circles represent wells we have production for, the red circles are wells we are trying to predict production. The fault is indicated by the red line. While I’m trying to present as much code as possible, the matplotlib plotting commands are somewhat verbose, so I will suppress the inputs and only show the plots.
It doesn’t look like the fault produces any offset or discontinuity in the spatial facies information, that’s good news, so we’ll proceed with imputing the missing facies information using spatial location information. First, we’ll subset the dataframe and replace the string labels for facies with numerical ones, so 0 will indicated Sandstone, 1 will indicate Sandy shale, and so on…
Now we’ll build a k-nearest neighbors classifier, do a little hyperparameter tuning with scikit-learn’s builtin GridSearchCV.
{'n_neighbors': 4, 'weights': 'distance'}Using the hyperparameter settings above, we can now predict (and impute) the missing facies values.
Given that we’d expect rocks of the same facies to have a similar density and acoustic impedance, we’ll impute those missing features with the averages from each facies.
Now we’ll subset the dataframe and use the features shown to impute the missing porosity values using polynomial regression.
We’ll setup a pipeline and use GridSearchCV again to find the best hyperparameters.
{'pca__n_components': 5, 'poly__degree': 2, 'scaler': MinMaxScaler()}The best parameters are shown above. Now we’ll use this model to impute the missing porosity.
Below we’ll plot the imputed and given porosities. Nothing looks too strange here, none of the imputed values are outliers with respect to the ranges of the given data.
We can also look at the distribution of the imputed porosities and compare to the given values. The imputation preserves the bimodal distribution of the original data.
Now we’ll add this imputed data to our wells_df.
To impute the missing permeabilities, we’ll use some knowledge of petrophysics to do a little feature engineering. There is a widely used correlation between porosity and permeability called the Kozeny-Carmen relationship which models permeability as
where κ is the permeability and ϕ is the porosity. We can quickly take a look at this relationship using seaborn’s builtin function, i.e.
While not the best model, we can use this data to condition our more complex prediction to come. First we find the slope and intercept of the blue line above.
Now we’ll use the model to create a feature we’ll call 'KC permeability, mD'.
Using the data show above, we’ll build a model to impute the missing permeabilities. Again, using GridSearchCV to hyperparameter tune, we have
{'pca__n_components': 4, 'poly__degree': 2, 'scaler': RobustScaler()}With these parameters, we can predict the missing permeabilities.
Visualizing the results of the prediction against the given data, this model appears to perform well. Again, I am suppressing the verbose plotting commands
The 'KC permeability, mD' is redundant now, so we'll drop it from the dataframe.
Feature engineering
Since the fault runs right through both the produced wells and the wells we are trying to predict production for, let’s engineer a few features related to the fault. First we’ll engineer a feature we’ll call 'Distance to fault' which computes the perpendicular distance to the fault. Also, we don't know if the fault compartmentalizes the reservoir in any way, so we'll also create a feature called 'left/right fault' to indicate which side of the fault a well lies.
Because all of the prediction wells are “near” the fault, we’ll create another boolean feature that gives some importance to wells near the fault. We’ll define “near” as any well that is closer than the mean preproducion (i.e. prediction) well distance from the fault.
Given that we anticipate wells that are “similar” to have “similar” production, we’ll use KMeans clustering to find similar wells in our dataframe
{'cluster__n_clusters': 14, 'scaler': MaxAbsScaler()}And use the model to predict which cluster the preproduction wells would fall into.
Now we’ll read in the production histories and merge them with our working dataframe.
Now we’ll compute the average 1, 2, and 3 year productions for each cluster and assign a new feature with this average value as the expected average production at each well location.
Merging these averaged production values into our working dataframe, we have the final dataframe which we’ll use to make predictions with.
Predictions
In order to hyperparameter tune our forthcoming models, we’re going to use the “goodness” measure of Deutsch, 1996, i.e.
in addition to the mean_absolute_percentage_error from scikit-learn to score our models. The idea will be to use the BaggingRegressor to create an ensemble of models that we average over to create our "best estimate" as well using each individual estimator as a realization for our uncertainty model. We'll score our model over each fold in the cross-validation using GridSearchCV. Credit goes to Honggeun Jo for creating the original version of this function which I only slightly modified here.
Separating our predictor and response features labels.
Since there are several data samples from each well, but we are only asked to report our prediction for the entire well, there are several options on how to proceed. This simplest is just to average all the samples over each well, we’ll use this approach in the interest of time.
Getting a boolean indexer for our training wells (the wells that have been in production).
Now we’ll set up a pipeline and pass that to GridSearchCV for hyperparameter tuning. I iterated this a few times to narrow down the final set of parameters to search, so that the final notebook/solution runs in a timely manner. Here I'm using 7 folds in the k-fold cross-validation because that leaves about 10 wells in the test set, similar to the number we need to predict.
0.8432431728379238{'bag__base_estimator': LinearRegression(),
'bag__bootstrap': True,
'bag__max_features': 0.75,
'bag__max_samples': 0.75,
'pca__n_components': 9,
'poly__degree': 1,
'scaler': MaxAbsScaler()}
The “best score” and final set of hyperparameters are shown above. Now we’ll write our best estimate and realizations to the solution file.
Submitting the solution file for scoring, we can generate the following plots. First we have the accuracy plot which compares the predictions to the actual 3 yr. production for the 10 wells.
MSE: 24697.56
Below the uncertainty models are shown along with the true values.
And finally the goodness plot. The goodness measure we used in our scorer function above is related to the integral of the black dashed line with respect to the diagonal red line where the area below above the red line is weighted twice the area below.
Goodness: 0.856
Finally, my rank in the competition among the other teams (note, this is only for the objective part of the scoring, in the actual Hackathon, there we had additional columns for code quality and presentations, therefore the final rankings of the other teams in this table does not reflect the actual final outcome of the competition). Not bad for a days work!
The final message here is that domain expertise, which leads to good imputation and feature engineering strategies is far more useful than fancy machine learning models. Additionally, understanding exactly the quantities of interest you are looking for so that you evaluate (i.e. score) your models well. In the end, I “won” the competition with a linear regression model.
Originally published at https://johnfoster.pge.utexas.edu/blog/posts/hackathon/.
