Structural DeSign design issues for structural engineers
T
he intent of this 3-part series is to expand the engineer’s understanding of the realities and opportunities in fatigue and fracture design. After reading this segment, the reader may have more questions than answers. This is not because the reader will not learn anything, but because they will better know the questions they should be asking.
Have Crack? What’s Next? Have you ever had a crack in a structure or been called on to evaluate one? It can be rather unsettling. Cracks like the one in Figure 1 are pretty easy. We replace the segment of pipe. However, what if you have a crack like the one in Figure 2? Alternatively, the UT inspector tells you there is a crack inside a key portion of your structure that you cannot even see. Under these circumstances, the solutions become less obvious and more difficult. Complicating matters is the fact that there is nothing in the codes that guides the engineer in evaluating cracks, leaving a big hole in the engineer’s ability to assess them and provide recommendations for repair. Fortunately, there are ways to evaluate these challenges, which will be discussed in the next two articles in this series.
Figure 1. Rupture in a gas pipeline.
General Principles of Fatigue and Fracture Part 1 By Paul W. McMullin, S.E., Ph.D.
It’s Complicated – and that’s OK
Paul McMullin is a founding partner at Ingenium Design in Salt Lake City. He is an Adjunct professor and the lead editor of the Architect’s Guidebooks to Structures series. Paul can be reached at Paulm@ingeniumdesign.us.
Embrace the complicated nature of cracks. The variables that influence fatigue and fracture behavior are truly legion. Figure 3 shows numerous inputs into fatigue and fracture design. It is certainly not complete, but it is a good start.
Figure 3. Inputs into fatigue and fracture design.
10 August 2016
Figure 2. Crack in a steel truss.
Fantasy vs. Reality The greatest disservice we can do in our approach to fatigue and fracture design is to oversimplify things. Crack design is full of oversimplifications. Why? It makes the design easier – initially. Who would not like that? In the real world, the problem and solution are much more complex. Oversimplifying the problem results in the engineer missing important variables that affect performance.
