The document discusses using machine learning models to determine well production state (on vs off) from sensor data. It presents an existing data architecture and issues with data quality. A supervised learning model is proposed using a decision tree trained on labeled rod pump production data. The modeling workflow includes data preprocessing, feature engineering, hyperparameter tuning and grid search. Decision trees are chosen for their interpretability but the document notes larger models may perform better. Overall production state modeling could help optimize operations and outperform existing controllers.

2. Is This Thing On?
A Well State Model for the People
Tristan Arbus
Data Scientist, Devon Energy Corporation
tristan.arbus@dvn.com

3. - Frank Chimero, designer
“People ignore design
that ignores people.”

4. Agenda
Production
What is production, where does it fit into the
lifecycle of a well, and why do we care about it?
Well State
What are we trying to solve and how can we do so
while promoting adoption?
Pros, Cons, and the Future
What’s good? What’s not? How can we make
improvements?

5. What is your goal?

6. Field Lifecycle Timeline
Where production fits in to the overall life of a well

7. Rod Pumps
Just one of many
different forms of
artificial lift

8. Looking at the Data
A quick look at production parameters and identifying well state by eye

9. Well State
Are we on or are we off?
On OnOff Off
0
100
200

10. Whiteboarding

11. Existing Data Architecture
How we obtain and use production data from the field

12. Supervised Learning
The rod pump run status controller provides a supervised learning dataset not readily available with
other forms of production
A proof of concept with rod pump production would motivate the manual creation of a supervised
learning dataset for other lift types

13. Data Quality Issues
The data isn’t always as nice as we want it to be
Problem
▪ “Ratty” data
▪ Missing data
▪ Variable data frequency
▪ Issues exist on a parameter-by-
parameter and well-by-well level
Solution
▪ Smoothing
▪ Data quality filters
▪ Interpolation
▪ One model for each parameter

14. PI System Explorer
Data quality
Statistics and
calculations
Output as new attributes

15. DATA

16. Final Architecture
Decision trees can be easily understood and implemented

17. Pi to Seeq to Databricks

18. Modeling Workflow

19. Manual Train Test Split
Allows engineers to select a group of wells that represent the entire field.
“If the model is accurate on this set of wells, it will be accurate everywhere.”
Wells
chosen by
engineers

20. Synthetic Minority Over-sampling Technique
(SMOTE)
Uses support vectors found using an SVM algorithm to create new samples

21. Hyperparameter Tuning
While keeping all but one parameter constant, you can both determine good starting points for a grid
search and prevent potential overfitting
Differential Pressure Total Gas Rate

22. Grid Search
Performed a brute force, manual grid
search tracking the performance of each
parameter combination.

23. Small, Understandable Decision Tree

24. Converting Decision Trees to Code

25. Bigger, Less Palatable Tree

26. Imported Back Into PI

27. Models in Production

28. At Scale

29. Models Can Outperform the Controller

30. Room to Get Better
Data Quality
▪ Training would benefit from improvements in data collection
Feature Engineering
▪ While basic statistics were used, perhaps features could be
engineered to be more descriptive
Model Type
▪ Gradient boosting and other model types can outperform
decision trees, but would require additional architecture and
buy-in
Model Longevity, Maintenance, and Tracking
▪ Don’t worry, I’m well aware that deploying a decision tree as
if/then statements won’t be the best long term option

31. Thank you!

32. Feedback
Your feedback is important to us.
Don’t forget to rate and
review the sessions.