### Accuracy vs. Simplicity in Engineering

#### by briancpotter

Once you move beyond basic statically determinate cases, engineering problems rapidly become very difficult to solve (leading to some creative solutions in the days before computers). An exact solution often requires the aid of either expensive software packages or extensive calculus training. However, while it might be difficult to, say, calculate the exact bending moment in a beam, it’s often easier to put an upper bound on it’s value. And sometimes, a reasonable upper bound is all you really need.

Here’s a real life example I faced recently. A single-story building has a room dedicated to file storage. In this case, the files are stored in large shelves that can be moved along tracks mounted to the floor. I had to design the concrete slab to support the weight of the files.

This actually is a fairly complex problem to model with any accuracy. First, there’s the edge restraints – two sides of the slab are fixed to the foundation, one side of the slab gets thicker at the edge of the file storage room, and one gets thinner at the edge of the file storage room. Next, there’s the distribution of load. The files don’t sit in one spot, but can be slid anywhere along the track. And the load won’t spread out into the soil evenly, but will concentrate under the track locations. Finding the maximum bending in the slab might take a few days worth of modeling and calculation.

Since I don’t have that kind of time, I change the problem around a bit. First, instead of checking various file rack locations, I can just use the maximum the track is rated for, 1000 pounds per foot. I toss out all the edge supports, and assume all the load gets distributed into the soil[1]. Since the slab is a rectangle with longitudinal loads on it, a one-foot section of it will reasonably approximate the actual conditions. Finally, I assume an even distribution of soil load.

In each case I’m either using “worst-case” load locations, or removing supports that could reduce the stresses in the slab. The actual bending in the slab can’t help but be less than what I get from my simplified model. And these changes transform the problem to one that can be solved in about 2 minutes with pencil and paper.

This gets you a quick answer for estimating concrete volumes, calculating uplift requirements, and doing any other calculations that require slab thickness information. And in this case, I actually used the result as the final slab design. The file storage slab ended up being 6 inches thick, as compared to 4 inches in the rest of the building. Since there wasn’t much savings to be gleaned from refining those numbers, I opted not to.

Engineering design often proceeds like this. Start with a quick approximation, and refine it as needed. Sometimes it’s out of necessity (for instance, designing a beam requires knowing what the beam’s own weight will be), sometimes it’s due to time constraints, and sometimes it’s because a good enough answer is good enough.

It’s for this reason that I’m often less than enthusiastic about the proliferation of FEA software. A FEA solution, while highly accurate if done correctly requires no thinking, no understanding of how the material will behave. You can simply recreate the exact loading and support conditions on the member, and have the computer crank through a few hundred equations and spit out the answer. One of the hallmarks of a good engineer, I think, is the ability to accurately approximate a problem, so simplify it in a way that makes it easy to solve but still mimics the real world conditions. It’s hard to build this ability while leaning on software as a crutch.

**Notes:**

[1] – it’s important to note that this assumption will change portions of the beam from positive to negative moment. In this case, the slab simply had one layer of steel in the exact center, and so had the same capacity in both positive and negative bending – another simplifying design decision.

**Sources:**

Experience, yo.