This article reflects on the personal and professional value of performing (at least one) technical calculation by hand before resorting to software. I argue that mastering the fundamental concepts keeps you in control of the outcome instead of placing too much trust in software. Software is an excellent work enabler/multiplier, but there are enormous pitfalls if users lack rudimentary understanding of what "should happen" in order to validate results.
My mission is to enable a philosophy of human-driven analysis vs. software-driven methods driven by "automagic" algorithms that users don't understand/aren't equipped to critically judge the quality of the outputs.
Exercises such as deriving equations, drawing a picture, or printing something out to draw on top of create a sense of personal ownership that is lost when everything becomes a "button click" away. The danger in blindly accepting results (whether black box or of your own creation) is that you can reach amazingly incorrect results.
Why Doings Things by Hand is Essential
As an undergraduate at Penn State University, something I appreciated greatly as a dual-degree student in the geosciences and petroleum and natural gas engineering departments was an insistence that calculations first be performed by hand before resorting to computers.
Computers absolutely have their place (as a reservoir engineer I use them multiple times a day), but there is no better way to cement the concepts than by doing the work yourself (designing gas-lift systems, using well-testing type curves, writing your cubic equation of state code, calculating mud density, picking OWC location graphically/from logs, using fractional-flow theory to understand breakthrough, material balance calculations, etc.). As a geoscientist, the bread-and-butter tasks included making maps, writing outcrop descriptions, balancing cross sections, using a stereonet to figure out plunging folds, and building flow nets for hydrogeological purposes.
Looking back, I realize that all of it was done to make sure that I learned the principles and remained firmly in the driver's seat when I used software to do this same work faster. As a professional engineer, I cannot stress this fact enough. You must always remain in control and not get carried away with the idea that "the simulator didn't terminate, so it must be correct."
Researchers from Princeton and UCLA also back up the claim that handwritten notes are superior to computers for learning retention.
What This Means for the Energy Industry
As my good friend and fellow reservoir engineer Ed Wanat at ExxonMobil likes to say, "Fluid characterization is not just a math problem." It is an art form that relies on adherence to human nuance and technical principles in support of a coherent end product. Math problems optimize according to a user-defined objective function—that's it. So, any shortcomings in the rule-based optimization will result in something less than optimal (or perhaps unphysical).
To those of you reading this who are in industry, I highly encourage you to incorporate paper-based exercises (or simple spreadsheet-based ones) in your training courses. Deriving equations, drawing a picture, or printing something out to draw on top of (seismic cross sections and well-to-well correlations are great for this) create a sense of personal ownership that is lost when everything becomes a "button click" away. The danger in blindly accepting results (whether black box tools or a scheme of your own creation) is that you can come to amazingly incorrect results.
For reservoir engineers, I can't overstate how important the whiteboard is when working on a problem. Material balance analysis, drawing a picture, and thinking through the problem is more valuable than immediately firing up the simulator or a fancy machine-learning (ML) model. When you're in a hurry to complete a job is when you need to be in a hurry to slow down and think things through.
Examples of Software Gone Wrong
Let's consider a few hypothetical examples. Suppose a bright engineer decided to relate subsurface mechanical data to observed production trends using some fancy ML model and the out-of-the-box result was that 0.6 was the optimal Poisson's ratio (PR). This should cause a heart attack for technical individuals since all known materials have a PR between 0 and 0.5. If this engineer/scientist was not in control of the analysis procedure (or general physics of the universe), he/she would not be able to immediately spot the result as a clear error (inputs, analysis, or output).
Or, slightly less sensational, let's say the reservoir simulator comes back with a recovery factor of 40% original oil in place for primary recovery factor in a black-oil reservoir with weak water drive and no gas cap. Using sanity checks, analogs, and experience, we know that this number is too high because the general expectation is closer to 10 to 25%. In our case, maybe the issue was that the engineer used an "infinite aquifer" boundary condition or added a primary gas cap into the model by mistake. However, without thinking critically about our tools, we are vulnerable to making important mistakes.
Parting Thoughts
1) It is okay to keep humans in the loop and do things by hand (at least once).
2) Technology/software should be viewed as an enabler/work multiplier. It should be used to do things at scale/faster than you can do it. However, it should not be a mystery how it works, otherwise you are at the mercy of someone else and at risk of producing unreliable (or even unphysical) work products.
3) These are my opinions, and I invite other schools of thought.
