by Josh Taylor
My prior blog posts have been product-centric: Bentley, RAM, BIM, etc. This post is product agnostic and deals with a much discussed topic and one continually growing in importance: proper use of structural analysis and design software.
Over the years I have had the opportunity to interact with hundreds of structural software users and dozens of members of our technical support teams (who have supported thousands of users) across ten nations and four continents. In processing their product questions, concerns, and requests, I have observed a spectrum of approaches to and philosophies on analysis and design software. In this post, I emphasize what I have found to be effective practices for managing the complexity software use can present, and arriving at accurate design information in confidence and reasonable time.
This specific context of the post is structural analysis and design software for building structures.
Importance of understanding the code provisions
Lots of structural analysis software packages have post-processors that do some of the design tasks according to a specified design code (ACI 318 or EC2 for example). It is very important not to trust the software's interpretation and implementation of the code provisions on blind faith. The software is not smarter than the engineer using it. If you, as a practicing engineer with just a pencil and paper, have difficulties deciphering how a code requirement applies to a condition within a structure, the software will likely have problems also. We, the writers of the software, have pondered the same questions you have and have made our best judgments within the source code.
The better the grasp an engineer has on the code provisions, better yet the intent of the code provisions, the better he/she will be able to validate and troubleshoot the software output. Always test simple conditions first to gain confidence in the software before applying widely to the project. Even then, always put the most critical areas of the structure under the microscope.
Take care with automation
Structural engineering software today can do lots of tasks for us very quickly with the press of a button: auto-design, auto load generators, auto layout of reinforcing and post-tensioning, quantity takeoffs, etc. As a rule, it's a good idea to use the manual version of a feature before using the automated version (most automated features are simply a packaging of an existing capability). One of the more important examples of this is designing an element by specifying and checking, rather than letting the program solve for the requirement. If the specify and check yields different results than the auto design, it's time to call technical support. Going further, if avoiding the automated capabilities altogether gives you a critical sense of comfort, this more than offsets the time lost by reverting to a little more manual work.
Subtle settings that make all the difference
How many times have you or a colleague found a far-reaching setting within a completed analysis model you prepared that was set incorrectly and needed to be changed? Maybe self-weight was double counted somehow, live load reduction was not considered, the shoring condition was set incorrectly, material properties needed changing, etc. The subsequent rerun then changed the analysis or design results dramatically from the prior run. Depending on at what stage the project is, this could be anywhere from a minor nuisance to a major dilemma. One common reason this happens is because the setting was located in a not-so-obvious place in the software interface.
If you are not already in this habit, here's a simple suggestion to help avoid this problem. Somewhere in the software product (most products anyway) it is possible to view a summary report of all the possible settings within the application. In some products it's a text report, while others can draw all the actual interface dialogs in a summary form. Print this document out and comb over it before the project starts. This brings all the settings that otherwise might be difficult to find right onto your desk. Then it's a fairly simple matter of finding where to change the settings within the application. I do emphasize that this should be done prior to each project. Software changes over time and so do the settings. Also, the possibility of using different codes and standards on a each project means different criteria will be exposed.
Design Forces, design forces, design forces!
The internal forces in the structural elements are everything. Ultimately they are the basis of the design. Whether you are designing the elements manually using the forces from the structural analysis, or using the post-processing capabilities of the software, the design is only as good as the forces and deformations in the elements that came from the analysis.
Unfortunately, analysis results tend to appear as little more than a jumble of numbers or diagrams on screen. It's too easy to simply take the values and run with the design with a false sense of confidence stemming from reasonable deflected shapes, moment contours, and displacements. This is exacerbated in concrete structures, where the inherent continuity of the system, as well as factors like pattern loading, slenderness effects, and stiffness multipliers muddy the waters even further. Somehow a conceptual understanding of the numbers needs to prevail.
A suggestion I make at seminars and when speaking with clients is to isolate one element within the structure (most likely a critical element). Pull out a piece of paper and redraw the element with the loading diagrams resulting from each unique load case (dead, live, wind, seismic, soil, temperature). Now write a small textual summary of the analytical factors involved in the numerical value of force in the element for each load case. For example, suppose there is an axial live load of 600 kips in an interior concrete gravity column. Our 'audit' of this member may look like this:
Similar summaries can be written for other types of response, and other load cases. They will all have unique factors and documenting them will help tremendously. Refer to this sheet of paper any time the numbers are called into question by management, peer reviewers, building authorities, etc. Instead of presenting a response envelope, from which little meaningful information can be deciphered, you will have specifics ready to present. Of course, this will be done for only one or a few members to serve as a quick reference as to what was entailed in the analysis. It helps to put context to what is otherwise a sea of numbers.
Excellent post, Josh. One additional thing that has been useful for my firm is what we call a "Recovered Loads" worksheet that displays the "big picture" analysis results on a one-page printout both in absolute terms and in load per area (psf) for the entire structure. The sheet also contains the results from the previous analysis so that changes (intentional or otherwise) are obvious. This one-page report is always my starting point when reviewing another engineer's model.
Comments and follow up discussion are welcomed. I always look forward to learning from users of our and other vendors' software.