James Finkel
Engineering Manager
B.E. Wallace Products
Frazer, Pa.

Nonetheless, this is a current problem because the complexity of any design software can turn nasty, especially when the model appears simple.

Several years ago I was on the road demonstrating FE software to a rather diverse audience. One of the audience members was an older engineer who had been designing railroad bridges for years. Schooled in the use of handbooks and proprietary formulas, he could quickly generate an answer based on his set of assumptions. Curious to see the software in action, he asked that I use it to solve a simple bridge problem of his choosing.

My boss at the time, who also happened to be in the audience, understood a bridge is made of beams and that beams were a feature of the software that allowed a design to be sketched out with just a few lines. What she failed to realize was that even simple geometry has some fancy math behind it. And here the problems begin.

For each line, you need to know the beam type. This information lets you determine moments of inertia, cross-sectional area, flange distance from the centerline, beam weight per foot, beam orientation, and a few other parameters. Each parameter must be entered and attached to the geometry in the proper sequence. Making the situation just that much more amusing, the lines had to be drawn in the correct sequence to ensure the orientations were compatible. I have purposely avoided discussions of boundary conditions and joint types because these just add to the impossibility of getting "the right answer."

Of course, I did not have the data available to generate the required parameters for the several different beams used in the bridge. Even making the bridge with just one type of beam would have been impossible to do on the spot. Had the correct data been available, the order of the parameters would have taken far too long to show in the minutes allotted for the demonstration. The worst part: The bridge engineer already knew the right answer.

So without hesitation and with a straight face I refused to run the customer's "trick" problem, much to the utter dismay of my boss. How do you frame this discussion in terms that a technically naive boss could comprehend? There are intuitive leaps from simple geometry to complex math to differing assumption sets. It would take days to explain just one of the issues, so when do you just punt? The boss failed to understand what the product could do. Worse, she did not know when to walk away from a no-win situation.

Before joining industrial-crane maker B.E. Wallace, Mr. Finkel worked for Ansys, Ansoft, Bentley Systems, Structural Research and Analysis, and Marconi (formerly FORE Systems).