Picture the scenario: it is 1971 and you have just received your new, state-of-the-art, structural analysis software package. It is exciting, especially given that it was purchased specifically for the design of a complex, large stadium roof. This will be a fantastic opportunity to demonstrate what can be achieved once you have the right technology. You complete your design but, as construction progresses, concerns are raised. Your roof is deflecting more than you anticipated. Your design is queried. You explain that there is no need to worry because discrepancies between predicted and actual deflections are to be expected – you’re not concerned because you used a state-of-the-art software package. Then you are informed that installation of the roof’s fascia panels is proving problematic due to the level of distortion in the structure. The fascia support brackets do not fit as intended. So, the contractor adjusts the support brackets and again you remain unconcerned by the distortion because your design was completed using a state-of-the-art software package. Then a number of members of the public complain that your structure appears to be excessively deflecting. The client raises these concerns with you and you put them at ease. After all, you remind them, your design relies on a state-of-the-art software package. At this point, reading this article, you are probably protesting that you would do no such thing. [caption id="attachment_28246" align="alignright" width="300"] CLICK TO ENLARGE Fig 1: Space frame module for Hartford Civic Center Stadium[/caption] You might argue that you would heed the warnings, you would revisit your software model and you would get to the bottom of why there was such a difference between predicted and actual performance. You certainly would not brush off repeated concerns. In fact, you are probably wondering why we are discussing such a far-fetched hypothetical scenario in the first place. But just because it is far-fetched does not mean that it is hypothetical.

Hartford Civic Center Stadium

The roof of the Hartford Civic Center Stadium, in Connecticut, USA, was an ambitious design – a 91.4m × 110m space frame suspended 25.3m above a 10,000 seat arena. It would be supported by only four pylons, each offset from the roof's edge, creating a 13.7m wide cantilevered perimeter. It would have 2,300 members, and be comprised of a grid of 6.4m deep, 9.14m × 9.14m modules (Fig 1). These modules had a number of key features. Firstly, the roof panels were not attached directly to the top chords, but instead were connected to posts protruding from these chords at discreet nodes. By using posts of differing heights, a drainage gradient in the panels was achieved, and these posts would also minimise bending moments being transferred from the roof panels into the space frame. Secondly, diagonal members were included to provide lateral support to the top chords, intended to reduce their unbraced length from 9.14m to 4.57m. Thirdly, this lateral support was critical, as the top chords were comprised of four steel angles formed in a cruciform – a cross-section inherently weak in buckling. In order to complete the design, the structural design firm, Fraoli, Blum & Yesselman, did indeed use a state-of-the-art software analysis package (1). In fact, they convinced the city of Hartford to purchase the package, citing construction savings of half a million dollars through its use. Once the design was completed, the Bethlehem Steel Company was awarded the construction contract and an inspection and testing agency, Gulick-Henderson, was engaged to ensure satisfactory completion. Construction began in 1972, with the space frame, along with all services, such as electrical conduits and ventilation ducts, being assembled at ground level, then jacked up into position – a novel approach at the time.

Concerns

However, when the space frame was assembled (and still at ground level), Gulick-Henderson informed the designers that it was deflecting more than the 310mm expected. The issue does not appear to have been addressed, and it was jacked 25.3m up to the top of the pylons. At this point, the maximum sag was measured and found to be not only larger, but twice that expected. Given the news, the designers replied that such discrepancies had to be expected in view of the simplifying assumptions of the theoretical calculations (2). It was then that the contractor installing the fascia panels discovered that the space frame was significantly distorted, with the holes for the fascia support brackets not lining up with the space frame. The designers again expressed no concern, and the project manager reminded the contractor that they were responsible for all delays on the project. The contractor then cut/extended the brackets and welded them into place, essentially working around the distortions. Multiple complaints were indeed received from members of the public – apparently, the roof deflections were so pronounced that they were clearly visible and unsettling. The city of Hartford, concerned, approached the designers, who again defended the adequacy of their design. Fast-forward five years to the night of January 18, 1978, when the Civic Center was subject to its heaviest snow load since construction – heavy, but still only half the design load. At 4.19am that morning, with the arena empty, the 1,270t space frame collapsed in its entirety (Fig 2 - main image). What is truly disturbing, however, was that only six hours earlier, more than 5,000 people had been sitting below it, watching a basketball game.

Cause

The investigation that followed was conducted by Lev Zetlin Associates, Inc (LZA), who would conclude that the structure essentially began failing as soon as it was completed (1). There were a considerable number of design deficiencies, which are discussed comprehensively by a number of other authors. We will focus on the primary issue, the buckling capacity of the top chords, specifically the level of restraint provided by the bracing diagonal. The key problem was an assumption. While the designer – and software package – utilised an unbraced length of 4.57m for the top chords, the investigation would discover that this was far from the case in practice. As the diagonal bracing was in the same inclined plane as the top chords, deflection was only restrained in one plane – the external top chords were essentially free to deform out-of-plane horizontally. Further, the absence of a post at some of these locations removed any potential restraint that the roof panels may have provided (Fig 1). While the software package assumed an unbraced length of 4.57m, in reality the top chords were found to be essentially unbraced, with a length of 9.14m. The issue was further exacerbated by changes in the diagonal-to-top-chord connection details, where the diagonal connection points were not coincident with the top chords (Fig 3). [caption id="attachment_28247" align="alignright" width="300"] CLICK TO ENLARGE Fig 3: As-built and designed connection details[/caption] These issues resulted in a significant overload: the exterior top chords on the north-south face and east-west face were overloaded by 213 per cent and 852 per cent, respectively. Once the top chords buckled, the progressive collapse of the space frame resulted.

Dangers of software

Few of us need to be warned about the dangers of over-reliance on software packages – it is something that most experienced engineers worry about and it is drummed into every young engineer using such packages. Simple, quick, hand calculations to check model results are still the key in combating over-reliance. There is an argument to be made that every analysis package should come with a complimentary copy of The Structural Engineer’s Pocket Book (4) and Roark’s Formulas for Stress and Strain (5). However, despite our protests that we would not have blindly kept faith in our analysis results, but maintained a healthy scepticism, we regularly encounter engineers who insist on the validity of their results, regardless of how a structure may be performing in practice. Such over-reliance is not a new problem, and it goes back further than the birth of computer software. One only has to remember Theodore Cooper and the Phoenix Bridge Company’s over-reliance on analysis techniques when designing the Quebec Bridge in Canada at the beginning of the 20th century. Even when confronted with the partially completed bridge showing clear signs of distress, Cooper and Phoenix refused to believe their analysis methodology was flawed. As a result, 75 construction workers paid the ultimate price (6). Software packages do, however, add a further layer of complication to this issue. Firstly, our industry spends considerable time and effort training engineers in the use of such packages – time that is often not spent learning, developing and perfecting the use of first principles and hand calculations. Many engineers hold the view that we are training a generation of computer programmers instead of engineers, and it is indeed telling that in the age of advanced analysis, misunderstanding fundamental structural behaviour still remains one of our primary causes of failure. Secondly, such packages can result in engineers who may not have the appropriate expertise tackling more complex analysis simply because the software allows them to do so. Of course, what is then missing is the experience and expertise to check such analysis. Thirdly, the sophistication of modern software packages can encourage us to analyse things to a very detailed level, thus stripping conservatism from our designs and, ironically, potentially resulting in ‘less safe’ designs when compared to more simple but crude hand calculations. Just because we can analyse in minute detail, does not mean we should. We should never ignore the fact that, in the hustle and bustle of on-site construction, similar precision may simply not be achievable. Finally, and perhaps most insidiously, sophisticated software can result in overconfidence. We can start to believe that the more advanced the software, the more correct it is. As humans, we tend to equate system complexity with system accuracy, despite the opaqueness it introduces. This is what happened in Hartford: given that the designers specifically argued that they needed the state-of-the-art package to complete the project, why would they then doubt the outputs from that package? To do so was tantamount to doubting the very decision to purchase the software in the first place. Readers of recent articles on being wedded to our tools (7, 8) should not find such behaviour surprising. Analysis methodologies and computer software are tools in our profession, but if an engineer’s training is dominated by such tools, they become wedded to them, and are likely to experience difficulty in dropping them, regardless of what the real structure is telling them. These tools can become part of an engineer’s identity. Thus, questioning them becomes akin to questioning one’s very identity.

New era

Software tools have made an immense contribution to our profession. They have removed many of our more mundane tasks and allowed us – when appropriate – to analyse ever more complex behaviour, but they are only as good as the engineer driving them. As we take our first steps into a new era in the construction industry, what could be called the ‘BIM (building information modelling) era’, we should be excited about the possibilities, the advantages and the efficiencies that computer software, whether it be analysis packages or BIM, can bring. But we must also be vigilant, because their reliability is governed by one important cog in the wheel: ourselves. Hartford teaches us that no matter how state-of-the-art a system is, human error and fallibility have the power to strip away its advantages, sometimes leaving us worse off. As put so succinctly by journalist Mitch Radcliffe: “Computers have enabled people to make more mistakes faster than almost any invention in history, with the possible exception of tequila and handguns." (1) This article first appeared in The Structural Engineer in August 2015. It is reproduced with kind permission from the Institution of Structural Engineers. Sean Brady is the managing director of Brady Heywood, which provides forensic and investigative structural engineering services. Web: www.bradyheywood.com.au; Twitter: @BradyHeywood

References

1) Delatte N. J. (2009) Beyond failure: Forensic case studies for civil engineers, Reston, USA: ASCE Press 2) Levy M. and Salvadori M. G. (1992) Why Buildings Fall Down: How Structures Fail. New York, USA: W. W. Norton 3) Johnson R. G. (2015) Hartford Civic Center [Online] Available at: https://failures.wikispaces. com/Hartford+Civic+Center+(Johnson) (Accessed: July 2015) 4) Cobb F. (2014) Structural Engineer’s Pocket Book (3rd ed.), Boca Raton, USA: CRC Press 5) Young W., Budynas R. G. and Sadegh A. M. (2012) Roark’s Formulas for Stress and Strain (8th ed.), McGraw-Hill 6) Brady S. (2014) ‘The Quebec Bridge collapse: a preventable failure (part 1)’, The Structural Engineer, 92 (11), pp. 20–21 7) Brady S. (2015) ‘Wedded to our tools: why expertise can hold us back (part 1)’, The Structural Engineer, 93 (6), pp. 28–30 8) Brady S. (2015) ‘Wedded to our tools: why expertise can hold us back (part 2)’, The Structural Engineer, 93 (7), pp. 28–30