A few months ago, I published a LinkedIn article titled A Tale of Python and PVT, sharing how I went about learning the language, some thoughts, and code applying Python to solve pressure/volume/temperature (PVT)-related examples. Flatteringly, it seemed to strike a chord in the community as TWA asked if I could write a bit more on the topic. What follows are some additional musings focussing more on the reasons why I like using the tool, and some challenges for leveraging it inside organizations.
Full disclosure: I’m not a classically trained programmer, nor do I claim to be anything more than a “hack” of a coder. I do, however, have some experience in petroleum engineering and very much appreciate simple(r) solutions to complex problems.
Why Should You Care About Python?
With the expansive libraries available, Python can be considered a Swiss Army knife for a practicing professional—need to read 100s of legacy daily PDF reports and extract certain tables? Can do. Need to bypass OFM software and read production test tables directly from the db file? No problems. Need to open and manipulate that ValNav CSV export with more columns than Excel can handle? Simple. These are all real examples where I have applied Python in the last 3 months to make me and my team more efficient.
Now, to be sure, it is not as if the Python community has templates for all of the above ready for eager petroleum professionals to simply apply, but, with some thought and Googling, one can generally find freely available libraries and code examples which can be adapted to address many of our challenges quite easily.
To the “gray-hairs” among us, though, none of this is ground-breaking. The petroleum community has a long history of custom programming and scripting to simplify our work. Python is simply another tool that can be used to that end. Bash scripts, Fortran code, Excel VBA, Java, even programs for the venerable HP-41 are just some examples of those.
What Makes Python Interesting for Me?
1. The vast libraries available. Machine learning, advanced math and integrals, reading Adobe Acrobat files, reading/writing to Excel, even parsing ECLIPSE files—if you are trying to accomplish or access something even close to mainstream, the chances are that someone has made a library available that you can leverage and significantly reduce the amount of code you need to write.
What doesn’t exist (to my knowledge) is a library of PVT correlations, inflow and outflow equations, and the like, but, if you are like me, you’ll have your own stash squirreled away in Excel VBA and such that you can quite easily translate. This would be an area ripe for some virtuous young engineers to put together an open petroleum engineering library and could be a great point of difference for someone seeking employment to showcase their skills and character. (If that sounds like you, I’d love to be involved!)
2. Jupyter notebooks. It is a great way to prototype new code or disseminate code in a transparent way. Think of coding in a browser, where you can intersperse raw code with results and plots as well as comments. When you're done, a single file can be stored/sent that contains all the code and results. You can see examples of these in my GitHub repository.
3. Flexibility. As touched on, in just a few months, I have used the tool to scrape real-estate listings from web pages to analyze trends for personal interest, parse 100s of PDF files to extract tabular data, teach myself PVT equation-of-state fundamentals, extract 100s of well profiles and curve fit to create creaming curve forecasts by area, and extract OFM data directly from the DB file. There is a definite attraction to having a single tool, with a single learning curve that can do so much, so easily.
The Challenges Facing Organizations
For a standalone engineer working nonstandard work flows or projects, a tool such as Python can be indispensable. For multinational organizations, striving to standardize and streamline everything as much as possible, the very thought of so many engineers creating their own custom work flows with unknown levels of assurance would send a shiver down their spines.
Between the two extremes of (a) a Luddite-like aversion to new ways to doing things and (b) bespoke unvalidated solutions to each and every problem, there should exist a pathway for organizations to test the waters and allow their engineers to learn and leverage these tools without sacrificing standards and assurance. Indeed, as our industry moves more into the machine learning space, Python-conversant petroleum domain specialists will, I'm sure, prove to be increasingly valuable to organizations.
So I’d like to sign off with the request that on a personal level we all keep learning—whether it be Python or something else—while, on an industry level, we find ways to allow our engineers to learn new tools and approaches that may on first inspection have no direct application to your current projects. After all, how can we expect our engineers to become comfortable with driving innovation when they're rarely allowed to explore off the beaten path?
Footnote: Since writing A Tale of Python and PVT, I’ve also uploaded the first half of the worked Phase Behavior Monograph Appendix C example to GitHub—the larger problem of developing a fluid characterization for a gas-condensate fluid, including splitting of C7+ into five fractions with a Gaussian Quadrature method, determining volume-translation coefficients for the C7+ fractions, and estimating methane through C7+ binary interaction parameters. I have not taken it beyond testing that I can replicate the initially calculated dew point, but it is there for everyone on GitHub, so perhaps someone can take it further and do the regression.
