Allow me open this article by saying, the excessive use and overreliance on structural engineering software packages might just be one of the modern structural engineer’s vulnerable spot.
Quite often, I come in contact with structural engineering drawings and my first approach is to interrogate the contents, are the assumptions being made justifiable? How did the design engineer arrive at his conclusions, are results what they ought to be? Ladies & Gentlemen! I’m usually perplexed in some cases, even left dumbfounded on how some engineers arrived at their design solutions. The crass lack of engineering “feel’ is almost always evident even from a glance, so strikingly clear that it stares you in the eye. Why is this the case?
In 2020, this writer was invited by an architect to participate in the implementation of a three suspended floor mixed use building. Drawings having being sealed and approved were shown to me. There were quite a number of inaccuracies & imprecisions and so I requested for a soft copy of the complete structural drawing in order to carry out a comprehensive review. During the course of the review, it became clear that there was meant to be a transfer structure towards the extreme right corner of the building. Cantilevering transfer beams picking up the loads from transfer columns, supporting wide slab panels and spanning from the first floor all through to the roof.
I quickly turned to the first-floor beams for the detailing of these beams, only to find out that the design engineer had obnoxiously ignored two of the most critical transfer beams out of the four transfer beams present in this structure. Attempts was made to reach the design engineer on phone to no avail, then a mail requesting for the details of this beam was sent to him. In his defense, this transfer beams failed and his conclusion was for the architect to review the architectural arrangement or consider the possibility of having columns below the proposed cantilever.
For a second, I paused to think about how this drawing could’ve possibly gotten the nod of a registered structural engineer let alone scaled through the building approval stage without anyone noticing this error as consequential enough to halt the approval process. Did everyone suddenly stopped thinking or was it the case that nobody cared to look? The answer to this question is not far fetched but it is a discussion for another day.
The problem wasn’t that, it is impossible to have these transfer beams, a look through the structure’s beam details showed that the design engineer was using (225×450 -225×600) sections, hence could’ve considered the same beam section for these beams. We can at least assume this was the case because even the less onerous transfer beam for which details were provided, used similar sections and was overloaded with bars, yet failed during the review.
We can then draw two very likely conclusions. First, a structural design software package was utilized in delivering this design, this is clear from detailing style enployed. Second, the design engineer inability to generate detail drawings for these beams was as a result of the specified beam section failing to pass the design requirements. To succinctly put it, the fundamental understanding of why these beams would fail was very missing and so the design engineer left it unresolved. The review would go on to specify (300 x 750) beams loaded with 12Y20mm (Top), 3Y20mm (Bttm) and 3-Y12-100 stirrups at the critical section.
If you criticize the competence of the design engineer, you might not be far from the problem. But this isn’t exactly a problem of competence and experience. Research has shown that it’s almost impossible to switch off your knowledge and expertise, it’s use is almost always going to be automatic and it appears to occur subconsciously. Indeed, there are times when we need to drop our tools. Are our tools engineering first principles or are they the systems and processes that delivers engineering services? If it’s the former then you’re in safe hands but if it’s the latter then you should be giving your tools some serious scrutiny. Yet many of us don’t, we simply carry on with the business of applying them. Such is the case of this design engineer who even condemned an entire architectural arrangement on the basis of the fact that his preferred software package couldn’t magic-out a structural solution for him.
These days, the use of software packages in designing structures has become prevalent throughout the engineering community. They provide us with fast analysis of structures, eliminate tedious tasks and might also allow us examine very complex structural behaviours at a very comprehensive level. However, while the use of a software is very essential in the present-day design office, it goes without saying that the role of sketches and hand calculations forever remains an important part of an engineer’s toolbox and is central to the design engineer establishing a “feel” of the structure they are designing.
While many engineers make the very valid argument that software prevent errors and human fallibility, many other engineers including this writer make the equally valid argument that these tools contribute to creating errors. Are these software’s actually aiding us to become better engineers or are they actually replacing us, at least, in cognitive sense, as engineers? Because, regardless of your bias or what you think, a software can be learnt by anyone, including a lay person. The distinction is always lying in the understanding of fundamental structural engineering first principles. Without an inherent understanding of what a structure can and should be doing, which is generally established through several years of training and experience, it is often the case that these design packages would produce serious errors that would go unchecked, which would’ve otherwise been caught by use of common sense and hand calculation.
However, this is not an effort to suggest that we drop our tools across board and revert to first principles. To suggest that is as ridiculous as asking a fire fighter to throw away his Pulaski and fight fire barehanded. But there will always be times when this tool will let us down. Developing an awareness of the tools we use and their limitations and an understanding of when it’s appropriate and inappropriate to drop them should be central for every structural engineer. When we drop them, we’re left with the fundamental principles of engineering and as Karl Weick puts it “to learn to drop one tools is to gain lightness agility and wisdom2”.
Integrating Hand Calculations with Software Outputs
While reviewing this article it became apparent that a little guidance be included on how an engineer should use software packages. For the experienced structural engineer, carefully interrogating the result of software outputs using hand calculation is the best practice towards combating over-reliance in software packages. To this end, this section of the article will aim to provide a best practice summary for young engineers and also serve as a reminder to those with competence and experience.
Conceptual Design
The concept design stage is where the structural designer decides on the structural system to employ, the type of columns, beams and, the floor type (solid, voided or flat or steel plate). This section of design is often carried out using hand calculations and nothing more. A very competent structural engineer should be able to predict or estimate from simple rules of thumb, or approximate hand calculations what loads are acting on a structure, what are the values of internal forces to expect in the various structural elements and what are the likely sizes of structural element that would resist these loads. These would assist in interrogation of the software outputs during the detailed design stage.
Inputs
At the detailed design stage where the use of software becomes very applicable, the first point to note is your inputs. If the data inputted into the software are incorrect in the first instance, the result will be incorrect. Basically: “garbage in – garbage out”.
Your results will identify input errors very quickly – for example a 450mm beam, badly inputted as 0.45mm will fail and deflect excessively no matter the span and loads applied on it! So, ensuring that all inputs made into the computer is correct, the support conditions, nodes, connections, releases are defined correctly is central to obtaining the right results.
The engineer must then consider the loads acting on the structure and ensure that they’re carefully inputted into the model and defined at their correct point of application and direction. How do these load work relative to each other? Are all the load cases identified and defined correctly?
Results
Common Sense Check
Before undertaking any interrogation, the design engineer should look at the numerical output depending on the type of analysis carried out and establish that the results are performing as intended. For example, in the case of a multi-storey steel frame, is the axial forces at the base of the foundation in correct order and magnitude? Is the global deflection of the frame sensible? Are there any odd deflections of beams or columns or excessive sway? All of these should be investigated and corrected.
It’s always a worthwhile exercise to consider the model first under gravity loads and then lateral loads separately before considering the load combinations. Following this, the engineer should consider the transfer of loads throughout the entire structure, find out whether the loads are accumulating in the right places as envisaged in the concept design. A column supporting wide slab panels should not attract a negligible amount of load same way a transfer beam carrying an 8-storey transfer column should be expected to have a large bending moment and shear forces.
A designer should also consider checking the bending moment and shear force diagrams of the entire structure. Are they presented as expected? Are the moment and shear forces acting in the right direction, are the tensile and compression reinforcement provided in the right positions and are moment joints attracting a moment?
Numerical Checks
At the level of numerical checks, the engineer should be either satisfied that the model is performing as intended or unsatisfied. If he’s unsatisfied then he should drop the results of the model and proceed no further. If satisfied or partly satisfied, he should consider undertaking basic numerical checks to ensure the results are not just correct but within the expected order of magnitude. Critical elements along with any issues highlighted by the “common sense” checks should be subjected to basic hand checks. Global checks should be carried out on the structure to ensure that approximate load applied to the structure is similar to that applied on the foundation. This can be quickly estimated by hand calculations using the tributary area method or summing up all loads acting on beams as if they were simply supported.
The extent of check should be determined by a brief risk assessment of the importance of the structure under consideration. What are the critical elements? If the elements are especially critical to the stability of the structure in question or the initial check has identified a problem, more rigorous checks should be examined. In the first instance approximate values of bending moment and shear forces should be made. This should then be followed by span: effective depth values of concrete beams and slabs, stresses in columns and other load bearing members etc. Consideration should then be giving to the minimum area and maximum areas of steel to determine whether rebars are too sparsely or densely distributed. Finally detailing of the structural elements should be looked at to ensure total compliance with code and standards.
Summary
Many experienced and competent Nigerian structural engineers will recognize the advice provided in this article to be normal practice and would’ve already adopted this advice to suit their personal requirements. However, the temptation for some software users is to create their model, insert the data and accept whatever data comes out without any interrogation or basic hand checks. To this category of designers, the software is an idol that can’t be questioned.
On a very light note, it can be argued that the advent of structural engineering software packages has endeared a lot of people towards structural engineering. Rightly so, many civil engineering students who sidestepped their structural engineering classes are now confident “structural engineers”. While we can’t deny the place of personal development, the reason for this is not far-fetched.
Structural engineering software packages remain an excellent and efficient toolbox, however, engineers must remember at every stage of their career that there is absolutely no substitute for the innate knowledge of structural engineering principles accumulated through years of training and experience. Beyond the use of software, as structural engineers, we should always consider how confident we’re in the adequacy of a design we’re proposing to be constructed.
The common sense that we’re so proud of is the most important item in our tool-box!
A. Wright
See: Dangers of using Software in Engineering
Sources & Citation
- Institution of Structural Engineers (2016) Integration of hand calculations with computational outputs – a good practice summary [Online] (Accessed: April 2022)
- 3) Weick K. E. (2007) ‘Drop your Tools: On Reconfiguring Management Education’, J. Manag. Educ., 31 (1), pp. 5–16 (Accessed: March 2022)
Thank You!!!
