Python Essentials for Engineers

Every engineering discipline has a working language: a set of terms, conventions, and shorthand that practitioners use to communicate precisely. Drilling engineers talk about WOB, ROP, and BHA. Reservoir engineers talk about Sw, Bo, and OOIP. These terms exist because precision matters. An ambiguous instruction on a rig floor can cost lives.

Python has its own working language: variables, data types, functions, and control flow. These are not abstract computer science concepts. They are the building blocks you use to express engineering calculations in code. This chapter teaches each of them through petroleum problems, so that by the end, you can write Python that reads like engineering and runs like software.

Six months from now you will reopen this code and either understand it instantly or stare at it as if a stranger wrote it. That difference is almost entirely down to how you name things. A variable is just a named container for a value, but the naming convention you adopt is what keeps engineering code readable long after you have forgotten the details.

In this book, we follow one rule: variable names use petroleum terminology with units appended. When you see mud_weight_ppg, you know exactly what it holds: mud weight in pounds per gallon. When you see tvd_ft, you know it is true vertical depth in feet. There is no ambiguity, no guessing.

Notice the distinction between total_depth_ft and tvd_ft. In a vertical well, measured depth and true vertical depth are the same. In a deviated or horizontal well, measured depth is always greater because the wellbore curves. This matters for pressure calculations: hydrostatic pressure depends on vertical depth, not the path the drill took to get there. Getting this wrong is a common and expensive mistake.

Python distinguishes between different kinds of values, and the distinction matters for engineering work.

Why does the type matter? Because certain operations only make sense on certain types. You can multiply porosity thickness_ft to get hydrocarbon pore volume; that is valid arithmetic on two floats. But you cannot multiply well_name reservoir_name; that is meaningless, and Python will tell you so. Type discipline prevents nonsense calculations, which in engineering, prevents nonsense decisions.

Arithmetic in Python works the way you expect, with one important detail: the difference between / (true division) and // (floor division).

These are how you express engineering conditions: thresholds, limits, operating windows.

That final line, meets_porosity and meets_perm and meets_viscosity and meets_saturation, is engineering logic expressed in code. The and operator requires every condition to be true. If you used or, only one condition would need to pass, which is a different (and much less conservative) screening philosophy. The choice between and and or is not a coding decision. It is an engineering decision.

Every engineering workflow has decision points. Control flow is how you encode them.

The order of the elif checks matters. If you checked water_cut_pct > 70 before oil_rate_bopd < 20, a well producing 5 bopd with 75% water cut would be classified as "High water cut" instead of "Marginal." The marginal production rate is the more urgent concern. Order those checks by priority and the right wells surface first; order them carelessly and an urgent well hides behind a less urgent label.

When you need to perform the same calculation on multiple wells, depths, or time periods, you use a loop.

Plotted, the same numbers show the decline at a glance:

This is a dual-axis production plot, one of the most common visualizations in petroleum engineering. The bars show the monthly rate declining from left to right. The line shows cumulative production growing but flattening. The shape of that decline tells a reservoir engineer a great deal about what is happening underground: how fast pressure is dropping, whether the well is in transient or boundary-dominated flow, whether intervention might be needed.

We study decline curve analysis in depth in Chapter 9. For now the point is narrower: a for loop, a list, and a plotting library are enough to turn a column of monthly rates into a decline curve an engineer can actually read.

Some engineering calculations require iteration: you start with a guess, refine it, and repeat until the answer converges. This is where while loops are essential.

Read down the Δf column. The first step takes a big leap; each step after it is far smaller than the one before. Every iteration shrinks the remaining error by a roughly constant factor (linear convergence, the signature of a well-behaved fixed-point iteration). (Newton's method roughly squares the error each step instead, quadratic convergence, but it needs a derivative the Colebrook-White equation does not hand you.) Either way, the whole calculation finishes in a handful of iterations.

The key idea generalizes: some engineering equations cannot be solved directly, so you guess, check, adjust, and repeat. The while loop is the structure that makes this possible.

We will use friction factors extensively in Chapter 15 (Gas Engineering) for pipeline hydraulics and pressure-drop calculations.

Write the hydrostatic-pressure calculation once, correctly, and you should never write it again; every later use becomes a single line that calls it. That is what a function buys you: a named block of code that takes inputs, runs a calculation, and returns a result, turning a one-off into a tool you can trust across projects.

There are several things to notice about how these functions are written:

Type hints (mud_weight_ppg: float) tell the reader what kind of input the function expects. They do not enforce anything at runtime, but they serve as documentation.

Docstrings (the triple-quoted text block) explain what the function does, what it takes, and what it returns. When you or a colleague uses this function six months from now, the docstring is the first thing they read. Write them.

Default parameters (overbalance_psi: float = 200) encode standard engineering practice. A 200 psi overbalance is a common default, but the function lets you override it when conditions require a different margin.

The function name is the calculation name. hydrostatic_pressure is what the function computes. Not calc_p or get_value or func1.

One of the most useful engineering visualizations is a pressure-depth plot. It shows how formation pressure, mud pressure, and fracture pressure vary with depth. The safe operating window for mud weight sits between the formation pressure (below which you get a kick) and the fracture pressure (above which you break the rock).

This plot is a direct product of the hydrostatic_pressure function applied across a range of depths. The red line is the formation trying to push fluid into your wellbore. The blue line is the point at which your mud breaks the rock. Your mud pressure (dashed) must stay between the two at every depth.

In reality, these gradients change with depth and geology; they are not straight lines. We will work with real pore pressure and fracture gradient data in later chapters. The principle, however, is the same: the engineer's job is to stay inside that window.

Every calculation so far has assumed clean inputs. Real field data is not clean. Sensors fail. Manual entries contain typos. Wells shut in unexpectedly. Your code must handle these situations without crashing, because a crashed analysis pipeline at 2 AM does not help the night-shift engineer who needs answers.

Two records failed. The code did not crash. It told you which records failed and why, then processed the rest. That is the difference between a script that works on clean textbook data and one that survives a real morning production dump.

Everything in this chapter (variables, types, operators, control flow, functions, error handling) combines into tools that solve real problems. Here is a complete well screening function that evaluates whether a well is a candidate for a workover.

This chapter covered the core Python constructs through petroleum engineering applications:

• Variables store engineering quantities. Name them with petroleum terminology and units (mud_weight_ppg, tvd_ft, oil_rate_bopd) so the code reads like engineering documentation.
• Data types (int, float, str, bool) map directly to the kinds of values engineers work with: counts, measurements, labels, and conditions.
• Operators express engineering arithmetic and comparisons. The difference between and and or in a screening criterion is an engineering decision, not a syntax choice.
• Control flow (if/elif/else, for, while) encodes decision logic, iterative calculations, and data processing: the same patterns that run inside production surveillance and well planning systems.
• Functions turn one-off calculations into reusable, documented, testable tools. Write docstrings. Use type hints. Name functions after what they compute.
• Error handling (try/except, guard clauses) makes your code robust against the messy, incomplete, sometimes contradictory data that comes from real field operations.

In the next chapter, we move from individual values to collections of data: lists, dictionaries, and the petroleum-specific file formats (CSV, JSON, LAS) that you will encounter in every engineering workflow.