Dangers of using Softwares in Engineering

Picture the scenario, you’ve been tasked with the design of a complex large stadium roof and interestingly you’ve just received your new state of the art structural analysis software package. It’s exciting and going to be a perfect chance to demonstrate what can be accomplished if 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 a number of members of the public complain that your structure appears to be excessively deflecting. So 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.

You’re probably protesting at this point, reading this post, that you wouldn’t do that. You’d probably say that you’d pay attention to the alerts, that you’d update the software model, and that you’d get to the bottom of why there was such a gap between the anticipated and the actual results. You’re definitely not going to brush off repeated questions. In fact, you’re probably wondering why we’re discussing such a far-fetched hypothetical scenario in the first place. But just because it’s far-fetched, doesn’t mean it’s hypothetical.

A Personal Experience

As an intern with one of the leading construction companies in the F.C.T in Nigeria, I was involved in the construction of a civic centre building. The building had 5 levels including a basement level, consisting of classrooms, halls and offices, and residential areas. Due to the layout of the building and the strict architectural requirements, columns and beams had to be spaced on a grid of (7.5m x 9m) to support 200mm solid slabs.

Coincidentally, the client on this particular project was a chief structural engineer, but he had outsourced the structural design of this building due to his very busy work schedules. As I gained more confidence in structural design concepts, I started to carry out independent checks on the structural elements of this project. Eventually, I was tasked to carry out a check on the internal columns as there was a new requirement to have a service slab on the roof. The design engineer had specified a 400mm2 column reinforced with 10-Y20mm at the ground floor and 8-Y16mm subsequently up to the roof, to support a grid of (7.5m x9m classroom) and (7.5mx1.5m walkway).

From my findings, I discovered that the internal columns were grossly inadequate to sustain the design load not even considering the additional loads from the service slab. The column should’ve been reinforced with 12-25mm dia bars at the ground and first floor and 10-20mm bars subsequently. This piece of information was swiftly passed across to the principal structural engineer, who promised to check with his design engineer. When he did eventually, he was shocked to find out that the columns were indeed undersized, sadly we, were already at the roof. Apparently, the design engineer used a design package that most likely considered the columns to be pin-jointed and did not carry out any hand calculations to interrogate the software results.

This structure did not collapse, nor showed any signs of distress during construction. The lay man might easily conclude that the building was safe aferall. However, aside the partial factor of safety which are quite generous to ensure variation in expected and actual performance are not detrimental, buildings carry only about 60-65% of their design loads at the time of construction.

To ensure safety, the building had to be retrofitted. This was done by breaking up the 7.5m span by inserting beams at 3.75m centres, thereby transferring 30% of the design loads on the internal columns to the perimeter columns. However, this led to an upsurge in the cost of construction, a decrease in the physical aesthetic of the building and delay in the project completion. Something that could’ve been definitely avoided by getting the analysis and design right from the outset.

Dangers of using Software

Most of us need to be warned about the risks of over-reliance on software packages – something that most seasoned engineers are worried about, and it’s drummed into any young engineer using these packages. (Simple, fast, hand calculations to test the results of the model are still key to combating over-reliance.

Despite the protest that engineers should not blindly keep faith in their analysis result, but maintain a healthy scepticism. It is not uncommon to 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 inception of computer programs.

However, software packages add a further layer of complication to this issue. Firstly, engineers spend considerable time and effort on learning the use of such packages – time that is often not spent on learning, developing and perfecting the use of first principles and hand calculations. Many seasoned engineers hold the view that this generation of engineers are more of computer programmers., and it is indeed clear that, in the age of advanced analysis, misunderstanding of fundamental structural behaviour remains one of our primary causes of failure.

Secondly, these packages can result in engineers who may not have the necessary expertise in doing more complex analysis simply because the program enables them to do so. What is then lacking, of course, is the knowledge and skills to test such an analysis.

Thirdly, the complexity of modern software packages will allow one to examine things at a very comprehensive level, thereby stripping our designs of conservatism and, sadly, possibly resulting in ‘less safe’ designs as compared to simpler but cruder hand calculations.

Finally, and perhaps most subtly, sophisticated software can lead to overconfidence. We may begin to assume that the more sophisticated the program, the more accurate it is – because humans prefer to balance system complexity with system precision, given the opaqueness that it brings. If a designer actually bought a software package to produce fast and more accurate result, why should he then doubt outputs obtained from such package?. To do so is tantamount to questioning the very essence of purchasing the software in the first instance.

Analysis methodologies and computer software are tools in our field, but if the training of an engineer is governed by these tools, they are married to them and are likely to encounter difficulty in dropping them, regardless of what the real structure tells them. These tools can become part of the identity of the engineer. As a result, questioning them is like challenging one’s own identity

Software packages have made a huge contribution to our profession, have eliminated many of our more tedious tasks and, where necessary, have allowed us to examine increasingly complex behaviours, but they are only as good as the engineer who drives them.