All Models are wrong, some are useful

Published: 15 Nov 2022
6 mins read

“All models are wrong, some are useful” - George Box

I’ve heard of this aphorism many times from my college professors. While I’ve always known it to be true, its brilliant insight did not register until I started working.

In any discipline, there is usually a gap between academia and industry. But within the context of structural engineering, this gap becomes galactic in size. The reason should be easy to understand. Economic pressure forces engineering firms to deliver their service as efficiently as possible. To put it another way, how “wrong” can we be while still ensuring public safety and code-compliance. It’s quite unfortunate how many engineering disciplines have become commodities. Being “too” correct is bad for business. (although being wrong is worse)

In short, researchers value rigor; practicing engineers value efficiency.

Ignorance is Bliss

The assertion that all models are wrong brings up many interesting and provocative discussions related to our Epistemology. Moreover, it has become a modus operandi (MO) for me as someone who suffers greatly from analysis paralysis.

I’m the type of person who loves jumping head first into technical rabbit hole. Unfortunately for me and many others like me, there are rabbit holes everywhere! What you thought were the firm grounds of structural engineering is in actuality full of holes; it’s like Swiss cheese!

In some ways, ignorance is bliss. The less you know, the more confident you can be!

A Concrete Example

To give a concrete example (pardon the pun). Say you have a concrete column and you want to find its axial capacity:

\[P_n = 0.8(0.85f'_c A_g + f_y A_{st})\]

We can use the above expression to get to a fairly good approximation and It’s very easy to understand too! The first term is contribution from concrete, the second term is contribution from reinforcing bars, and there are some fudge factors for conservatism. At this point, we can either say “good enough” and ignorantly press on, or we can start introducing complexity.

  • Concrete strength (f’c) is dependent on degree of confinement. Therefore, the cover and the column core will have different f’c
  • Column cover is known to spall off at high strain
  • Concrete Strength (f’c) is dependent on strain rate, with different behavior in monotonic vs. cyclic loading
  • Degree of confinement is dependent on the column tie spacing, so the axial capacity should be a function of transverse ties too
  • Axial load is never concentric. There will always be some eccentricity (moment demands). Axial and flexure should be evaluated in tandem. In fact, we should theoretically determine the full stress state (P + M + V + T) and pick the failure theory most appropriate for concrete.
  • Will the concrete be fully cured when it’s loaded?
  • Area of steel should be subtracted from concrete area to avoid double counting
  • If the concrete column is slender, we need to take into account stability and p-delta. In which case we need to determine what value to use for Young’s Modulus (E)
  • Youngs modulus (E) is nonlinear for concrete. We can take a secant stiffness but what modifier should we use? Modifier depends on degree of cracking. Furthermore, elastic modulus (E) and f’c are both experimentally determined and has coefficient of variation of at least 0.1 or greater

After you’ve taken into account confinement, rate of strain, eccentricities, p-delta, stability, area reductions, and spoke with the contractors about loading stage and curing procedures, after you’ve calculated two separate capacities (one for monotonic and one for cyclic), you are finally ready to move on to the other 200 columns in the building for the 200 other load combinations.

I don’t want to belabor the point here. The main takeaway is that you’ve spent 10x the time/effort to be marginally more “correct” than the building code interpretation. While complexity is unquestionably good for a researcher, making a research project out of every building design is an act of financial suicide.

We live in a world of infinite, yet our mind can only grasp the finite. The fact that we can’t know anything for certain should not be discouraging, nor should it be a carte blanche to do anything we want! Despite the uncertainties, and the dubiously high coefficient of variations in concrete design, we still built the Burj Khalifa!

“For such a model there is no need to ask the question “is the model true?” . If “truth” is to be the “whole truth” the answer must be “No”. The only question of interest is “Is the model illuminating and useful?”

The Purpose of Analysis is Insight

The most important realization for a practicing engineer is that “the purpose of analysis is insight”. You can always build a better, more accurate model. But that doesn’t mean you should!

As with many things in life, there is a decreasing marginal return on insights gained vs. effort. We should strive for the Goldilocks zone where you can spend 20% of effort to achieve 80% of the insights. There is no sense in getting lost in a complicated maze you’ve built for yourself full of mathematical intricacies that somehow takes into account all edge cases.

The MO for practicing engineers should be to build “sufficiently correct” models to make sense of this messy world of ours.

The MO for researchers should be to dig deep! Venture into the abyss of unknowns and devise enlightening yet concise models of our world. To quote George Box again: “Just as the ability to devise simple but evocative models is the signature of the great scientist so overelaboration and overparameterization is often the mark of mediocrity”

The best advice I was ever given from a senior engineer was to start with a sensible design first (with minimal, if any, mathematical calculations). Then as a second step, use math to draw insight and inform your design. Notice the sequence there! Any design should first and foremost make sense.

The Essence of Design is to Subtract

“If you wish to make an apple pie from scratch, you must first invent the universe” - Carl Sagan

If you want to model the seismic behavior of a building, you should first model a couple hundred feet of soil beneath it.

In my daily work, I’m heavily involved with workflow standardization and automation. Over the years, I’ve grown to appreciate well-designed products and services, as well as the wisdom behind Occam’s Razor. System design is hard! Picking the right level of abstraction is hard! To add is expected, to subtract is design.

This article is getting too long. I’ll end with one of my favorite quotes of all time.

“What is simple is always wrong. What is not is unusable” - Paul Valery

tags:

comments