“Mr. Dahl, do you have a moment?” Matt, a young engineer, stood outside my office door.

“Sure, what do you have?” I asked, waving him in.

“Some questions on the model,” he replied, clearing his voice. Although Matt was just two years out of school, young and inexperienced, we had him working on a study of a rural water system –  learning on the job is the best way.

I knew the system he was studying like the back of my hand; my predecessor, Bob, designed it in the seventies and then helped with its operation until his retirement twenty years later. That is when I became their engineer, helping them expand and reinforce. Today, they are a large system with thousands of customers. They purchase water in one county and distribute it southward throughout a second county.

As you might expect, a lot has changed in forty years. Driven by new subdivisions, hundreds of homes, turkey barns, and a new interstate, water usage has grown dramatically.  During dry weather, the old system maxes out, so the Board knew they needed to make improvements. Matt was helping me determine what those should be. His first task was to prepare a computer model of their water system.

Now, I’m an old slide rule engineer. In fact, I helped Bob design this system, using that old slide rule. Every calculation was by hand, using a repetitive, circular calculation process called the Hardy Cross Method – a time-honored procedure taught to all us old engineers. Yep, I’m an old slide rule engineer. However, I knew that the new fangled computers would speed the process, so I wrote our company’s first water modeling program, in BASIC. The program automated the Hardy Cross method based upon a program developed by the University of Kentucky called KYPipes. Although slow and clunky by today’s standards, at the time it was like lightning.

Shortly after, the personal computer took off, with dozens of software vendors publishing engineering modeling programs of all sort – water networks, stream flow, flood routing, earthwork, storm sewers, and especially structural design. Ever better water network applications were published, nearly all derived from the KYPipes engine. Today we use a beautiful model, fast, powerful with lots of bells and whistles. A long cry from the old program I put together. It was this latest, greatest software that Matt was using to model the water system.

When Matt walked into my office, I could see concern plastered his face. “Something’s not right with the water system; the model shows low pressure in the north part of the system, that can’t be.”

“Why? We know they have low pressure there, that’s why we’re doing the report.” I tried to keep a straight face.

“B-but they have negative 100 psi in the north section!” Matt explained.

“No, they don’t,” I replied. “It’s low, but not negative 100 psi.”

“The model shows they have negative 100 psi!” Matt argued.

“Matt, what would happen to the plastic pipe if they had negative 100 psi?” I’m afraid I was getting a bit snappish.

“I don’t know, I suppose they wouldn’t get any water.” Matt dropped his eyes avoiding mine.

Perhaps I should pause and explain a bit of the engineering. A negative pressure is a suction, so a negative 100 psi is a suction of 100 psi, however, in a water pipe as the pressure decreases, liquid water becomes vapor. Even with perfect conditions, you cannot suck water higher than 34 feet, which is 14.7 psi or one atmosphere.  To put it in full perspective, a negative 100 psi pressure can’t be generated in a water system.

“Matt, even if you could generate a negative 100 psi, the pipe would be flat, and they’d have leaks everywhere, but they don’t.”

I was beginning to see his problem. It was sadly familiar – Matt’s input parameters did not reflect the actual system.

“Do you have the actual pressures in that area of the system?” I asked; although I knew the answer. Matt shuffled through his files and checked his notes. Not finding what he wanted he made a trip to his office and returned a few minutes later.

“The operator said that sometimes the pressure drops a bit below 20 psi.” Matt furrowed his brow in thought. “But that can’t be right; the model shows negative 100 psi.”

“Then the model can’t be correct.” I snapped. “First, you can never actually generate a negative 100 psi pressure, the pipes would fail. Second, we know that their pressure is actually a little less than 20 psi –  a plus 20, not a negative 100.” Matt was still not sold.

“I used the factors Derrick gave me,” Matt gestured; Derrick was another engineer in the office.

“The model’s wrong,” I repeated. “What was the total daily flow you used in the model?”

“I don’t know. I used Derrick’s factors.” Matt replied sheepishly.

“Your model has to reproduce actual conditions,” I replied, shaking my head. “I suspect it’s using a much larger daily flow. Check it out.”

Matt went away, still muttering about negative pressures. In time, he returned to report that his model generated a flow three times greater than what the actual flow was. Eventually, Matt adjusted the input parameters to match the existing conditions. Once he did, the model worked fine.

My point of this story is simply to illustrate a long held problem with computers, and by extension computer models:

“Garbage in, = Garbage out.”

Sadly, I’ve seen this scene play out too many times, water, stream flow, sewer, and even structural design models. More alarmingly, I’ve also noticed a growing trend among young engineers, one that should frighten us.

More and more, they exhibit a BLIND FAITH in what the computer model says. Too many of them lack the ability, or the inclination, to critically question their results.  At times it seems that common sense has left the building.

Let me be clear, I have no problem with computers and computer models. They are powerful tools that enable experienced users to accomplish great things. But they are still, just tools. In our world, we place greater and greater reliance on computer models. We use them for everything from soup to nuts; weather forecasting, political polling, climate change, control of building temperature, energy usage, medical diagnosis, medical procedures, weapons control, and especially the design of engineering structures great and small.

Unfortunately, with this increased reliance, we assign increasingly less experienced individuals to program, calibrate and use the software. It may be the pressure of losing experienced engineers to retirement, or perhaps a general belief in society that software can take over the mundane work. In fact, I have even seen serious journal articles advocating licensing of the software, rather than of the technician using it. It is a sad state of affairs when we value the tool more than the craftsman using it.

I fear that our future includes a catastrophic failure. One that will be caused by unquestioning reliance on “what the computer said.”

But what do I know, I’m just an old slide rule engineer.

 David L Dahl.

Leave me a comment, follow me on Twitter @buggasbooks, or like me on Facebook.

Read more about Olivia’s Story here – http://www.buggasbooks.com/book/olivias-story/

Read about my other books here- http://www.buggasbooks.com/other-works/

Save

Save

Save