Harnessing the Power of Software Without Losing Sight of Fundamentals

To view the figures and tables associated with this article, please refer to the flipbook above.

In Structural Engineering, structural analytical modeling software provides unparalleled efficiency. These software programs are celebrated for their ability to streamline calculations, craft intricate structural models, and expedite the design process. They empower engineers to tackle challenges with precision and creativity, embodying the transformative potential of technological advancement in the field.

Designed to be user-friendly, modeling programs often provide answers with ease, generating loads and auto-sizing complete structural skeletons in minutes. Their speed with calculations can be an allure to overburdened engineers facing tight deadlines. Their perceived power and accuracy can lull the most experienced into complacency. Without an impetus to question either the validity or suitability of the results, they often rely on default settings without reviewing documentation on what these settings are and how to change them. There’s a software term called “garbage in, garbage out.” If the inputs to the model are wrong, incomplete, or inaccurate, the output, no matter how favorable, is also useless. Thus, while software offers unprecedented capabilities, it is imperative for engineers to exercise caution and maintain a balance between technological convenience and thoughtful, rigorous engineering practice.

With a little extra care and attention, engineers can develop structural modeling skills and managers can incorporate QA/QC practices that enable firms to successfully leverage the power of analytical modeling software.

The first, and likely largest, problem is that new software users often lack critical understanding of their objective. Often these users are new engineers, accustomed to solving well-defined textbook problem statements. While these simple scenarios are ideal for mastering individual concepts, they fail to develop big picture thinking required for our real-world tasks.

Structural Engineers are required not only to execute a collection of individual design actions, but also generate and apply loadings, identify limit states and code requirements, and consider how multiple conditions influence one another. This big picture understanding of how to apply the tools from our college education to real-world problems is a giant gaping hole in our current education system.

Armed with software that enables you to design to a specific iteration of the building code, it can be tempting to input your geometry and press “go.” Over my career, I’ve observed a multitude of errors in analytical models, some of which are listed in Table 1. These errors are largely a result of three main things: not being aware of software limitations, not understanding processes, and not performing “sanity checks.”

Structural analytical models are good at “plugging and chugging,” performing repetitive calculations or multi-part problems that rely on the output from one part as the input to the next. Software is designed to execute pre-written processes based on provided input, much like a calculator can perform specific operations following order of operations rules, but doesn’t know when you meant to type a negative sign instead of a “minus.”

A few examples of such operations and sample processes for Structural Analytical Modeling Software are:

Software is not good at making decisions. While you might select a building code to design to in the software input screen, Too often, Structural Engineers assume their analytical modeling software does all of this for them. After all, if you tell the program to design based on the IBC 2021, it’s an easy leap of faith to assume the program is going to identify and apply all provisions and referenced standards from the IBC 2021. What you’re telling the program is just which versions of equations to use in its limited pre-defined workflows.

By blindly assuming the default settings are appropriate and that all required checks are being performed by the software, you are devaluing yourself, your skills, and abdicating the control and responsibility our profession is charged with. It is imperative that engineers make an explicit effort to maintain “responsible charge” of their software and treat it as something that requires specific instructions and oversight, rather than something that already knows it all/knows better than you.

Before asking software to do something for you, it’s essential to grasp how the task would be performed manually. This step is often the key part of effective software use training, yet it’s frequently overlooked. I’m not advocating for a return to the days of mastering moment distribution or performing finite element analysis by hand. Instead, the emphasis lies in understanding the pertinent code requirements for your design and identifying which limit states are likely to govern your approach. What decisions must you make, or what information must you possess to navigate through these code requirements?

Consider sizing a steel column. You’d require both the demand and capacity for all relevant limit states. Begin by referencing the building code to determine the applicable limit states. To establish the demands, you’d need details such as the tributary area, applied loads, connections to other members, and load combinations. On the other side, determining the capacity requires factors like overall height and bracing conditions. These elements serve as your inputs. The code or specification guides you towards the desired outputs. Understanding this input-to-output transformation grants you insight into what should transpire within the “black box.” This enables you to focus on providing the correct inputs, and understanding how any generalizations or assumptions in those inputs might affect your output.

Next, you need to understand how the software is approaching the problem. This is frequently excluded from Quick Start tutorials, which focus more on the clicks and menu options to go through in order to provide the program with input, not on how the program uses that input. However, developers do frequently provide documentation on the assumptions, limitations, and processes inherent in their products through Help file documentation, online forums, and Wikis. Without knowing that effective length is important to column design, you might not think to ask how the program calculates a column’s effective length, or look into whether you can model a single column through multiple stories and expect the program “knows” it’s braced at each level or should consider its full node to node length.

If you don’t have an idea of what the “right” answer should be, you are putting too much trust in the computer. Too often, engineers fall into the trap of blindly running models until they yield a passing result, relinquishing their role to the software.

The computer is not smarter than you. Many times we rely on “experience” from PMs/PICs, but taking ownership for your own model can help develop that experience ahead of time. Human beings learn from experience. We train ourselves to expect certain results based on previous experience, so, for newer engineers, without experience, it can be easy to abdicate responsibility, saying there’s no way for them to know what to expect. That’s not accurate.

In lieu of experience, we can leverage critical thought about what controls what. It doesn’t take ten years to understand that you don’t need to compute snow drifts if there’s no way for them to govern over your roof live load, nor do you need to ask your 30-year veteran boss if an HSS4x4 column makes sense for your 10-story building when you can perform your own load take down by hand for its 30×30 tributary area and check it against the AISC table. Thinking through how you could do some things by hand, and doing them, will help build that frame of reference for what a reasonable design might be, as can looking at past designs for similar projects. When in doubt, ask someone else how they would “back of the envelope” check something.

Regardless of the software used, engineers bear the ultimate responsibility for ensuring code compliance and accuracy in their designs. Dependence on others to complete tasks undermines this responsibility and can lead to errors. Taking charge of our work is not only professional but essential for ensuring the integrity and safety of structural designs.

It sounds so basic, but one of the best things we can do for our staff is to point them towards actual sections of the code and ensure they understand what the legal drivers for our work and the acceptance criteria are.

As an individual, the best way to determine your objectives is simply to read through the building code itself. Familiarize yourself with the different triggers and clauses that govern design and might add additional criteria. We bear the responsibility for their accurate execution. Defining the scope is paramount, particularly for newer engineers. Throughout my career, I’ve found that most errors come from lack of awareness. This underscores the importance of recognizing that no software program can cover every aspect of our work comprehensively. Acknowledging code requirements and project objectives enables us to understand where specific software capabilities can take up some of the load while maintaining control of the big picture ourselves.

Structural Engineers need to have an intuitive understanding of how structures behave and respond under various conditions. At its core, our primary role is to ensure the stability and load path of a structure. It’s fascinating to note that even preschoolers grasp basic physics concepts intuitively, recognizing that a cereal box will tip when loaded at the top, but slide when loaded near the bottom. To foster this innate understanding, structural engineers can utilize hands-on manipulatives like Play-Doh, paper, or spring models as tools in our training and practice. Everything we do in structural engineering is rooted in intuition, but complexity arises when we’re juggling multiple factors for different load conditions simultaneously. Cultivating this intuitive sense of structural behavior, and leveraging it during design, is not only essential but also enriching.

In the realm of structural engineering, the importance of verifying the accuracy of models cannot be overstated. Attempting to verify a large and complex model without having first mastered a simple one is a recipe for potential errors and oversights. Engineers must adopt a methodical approach, especially when learning new software programs. In Software Engineering, there’s a concept known as “unit tests.” Unit tests are small tests designed to verify the correctness of individual units of code, such as functions or methods. They are written and executed by developers to ensure that each component of the software behaves as expected under various conditions and serve as a vital part of the QA/QC and provide documentation on how different parts of the software function.

Structural Engineers can mimic this technique by starting with a straightforward model that can be fully analyzed and verified by hand. Simple models offer the perfect opportunity to explore how the software distributes loads, generates wind and seismic loads, asserts fixity and boundary conditions, chooses unbraced lengths, applies load combinations to load cases, and presents results or reactions. By thoroughly understanding these fundamental aspects and being able to confidently and efficiently verify how the software is using input and generating output, engineers can confidently tackle more complex models, ensuring their accuracy and reliability in structural analysis and design.

Recommendation:

The role of supervisors and managers in the development of their staff cannot be overstated. While acknowledging the challenges they face—often ill-equipped to teach, with their focus squarely on deadlines and deliverables—it remains imperative for them to take an active role in cultivating the next generation of engineers. This responsibility falls on those who are “in responsible charge.” Without adequate mentoring, staff members are set up for potential failure. Supervisors must go beyond drawing reviews that merely check for reasonable sizes; they must hold their staff accountable for their methods and approaches. It’s crucial to understand that getting the right answer through the wrong means is still incorrect. Engineers should feel a sense of ownership and responsibility for their designs, driven by the understanding that they are ultimately accountable for their work. Employers can support this by providing self-check tools, implementing robust QA/QC procedures and encouraging hand calculations. Most importantly, they should refrain from placing staff in situations where they feel compelled to rely on models before they’re fully prepared. This proactive approach ensures not only the professional growth of staff but also the integrity and quality of the work produced.

Recommendations:

Structural Modeling can be an incredibly useful tool in our toolbox, but requires an intentional approach from engineers as employees and employers. It’s critical for us to use these tools of responsibility rather than defer decisions and design to software, killing our value as a profession before any Artificial Intelligence program even has to fight us to do it. Fortunately, each of us has the ability to learn and fix this. As Spiderman’s Uncle Ben (who actually quoted Voltaire) aptly noted, “With great power, comes great responsibility,” a sentiment that underscores the immense capabilities and impact of modern structural engineering software that already exists, and all that is to come as we move into the age of Artificial Intelligence.

About the Author

Angelina V. Stasulis, PE, SE started college as an Education major, intending to become a high school teacher. While she eventually changed majors and has been a consulting Structural Engineer since 2009, her love for teaching continues to drive everything she does. As a member of NCSEA’s Board of Directors, Senior Structural Engineer for Shear Structural in Atlanta, GA, and parent, she constantly seeks out ways to leverage her passion for education.