How well do you trust the results of your structural analysis software?  Relying on software can save hours of design time, but using an inaccurate model can have devastating results.  Even the most experienced engineer can stand to be reminded of potential inaccuracies when using structural software, especially with the many changes made to building codes and in structural software updates.

In the November 2017 SE University session, Matt Brown, SE, from Newport Structural Design, Inc., presented Validating Software Results which covered a variety of pitfalls to avoid and rules of thumb to use when employing structural software programs.  Matt gave great examples of how small changes or oversights during the input can result in inaccurate and potentially catastrophic output.

First, Matt reviewed how designers need to be consistent in their use of ASD or LRFD loads and load combinations with the appropriate safety factors.  For instance, the use of ASD loads with LRFD safety factors would result in an unconservative software results.  Similarly, being consistent with ASCE7 wind speeds and load combinations and ensuring the correct code years.  If a designer uses the 2005 wind speeds with 2010 load factors, the results would be unconservative.  When multiple parties may be involved in the design, it is important for all parties to be aware of the applicable code year and be consistent throughout the design.

A second pitfall in using structural software analysis can be found in properly modeling the intended load path.  Often times, the load path is incorrectly modeled with boundary conditions that may not be accurate.  Being aware of how you would expect the building to transfer the loads down to the foundation before you solve the model will help to avoid unintended boundary conditions that would be inaccurate and drastically affect the analysis results.

Another common oversight in building models tends to result from the use of rigid diaphragms. When using collector beams to transfer lateral loads from the rigid diaphragm to the braced frame, the collector beam in the model will have zero axial load due to the strain compatibility of the idealized infinitely rigid floor compared to the less stiff steel beam.  However, in reality, the steel beam will have an axial load that will need to be checked by hand in addition to the flexural bending obtained from the software results.

Also, notional loads could help prevent unconservative designs and should be included in any software input.  This is especially important when using the Direct Analysis Method since the effective length factor K =1.0.  Without any notional nodes on a simple gravity analysis, there is no deflection that will create a P-delta effect to include in the analysis.  Thus, the frame will not be able to withstand any lateral load, even though the model shows the gravity analysis to be acceptable.

Knowing the capabilities of the software before employing its use can be invaluable to the design engineer.  Though software does sometimes have bugs that can cause issues during design, typically errors result from a lack of foresight on what results should be expected from the model.  To avoid future mistakes with your structural software analysis, be sure to watch out for these common pitfalls, and consider your expectations before you hit solve to be sure you have consistent results.