What Is Structural Analysis

So You Want to Know What Structural Analysis Actually Is

Structural analysis is the process of determining how physical structures behave when forces are applied to them. That's the boring definition. The practical one is: you're trying to figure out whether something will hold up, deform too much, or just fall apart, and you're doing it before you actually build it or load it in real life. I've been doing this since before most people learning it were born. The tools change. The math doesn't really.

What Is Structural Analysis in Practice

Let me skip the academic definition and talk about what happens when you open up a finite element analysis (FEA) program or even pull out hand calculations for a simple beam. You've got a structure — a steel frame, a concrete slab, a bracket welded onto a support column. You need to know the stresses, deflections, and safety margins under whatever loads you're expecting: dead load from the structure itself, live load from people or equipment, wind, seismic, thermal expansion, the whole list. The core question is always: does the model I'm running represent reality well enough that I can trust it? Here's where I ran into trouble recently. I was analyzing a steel moment frame for a mid-rise building. The initial run came back clean — everything under 60% of yield capacity, deflections within L/360. I was about to sign off when I noticed the connection designations in the model didn't match the actual shop drawings. The beams were modeled as fully rigid connections but the detailed plans showed pinned connections with shear tabs. That changed the redistribution of moments significantly, pushing some member stresses up into the 85% range and shifting the drift calculations entirely. It took about two hours to fix the model, but it would have been a catastrophic oversight if I'd just signed off without checking the connection types against the actual drawings. This happens more often than you'd think. Modelers tend to default to rigid connections because they're easier to set up, and they don't always catch when the structural engineer's intent was actually pinned.

The main methods you'll encounter are the force method and the displacement method. The force method, also called the flexibility method, solves for redundant forces first and then works toward displacements. The displacement method — stiffness method, which is what almost every modern software package uses — solves for nodal displacements first and then derives forces from those. For indeterminate structures, the displacement method tends to scale better. That's why SAP2000, ETABS, and the like are built around matrix stiffness formulations.

The Methods Without the Textbook Language

Take a simple determinate beam, say a cantilever with a point load at the end. Hand calculation: stress is M*y/I, deflection is PL³/(3EI). Done. Forty-five seconds. Now take a continuous beam across five spans with varying cross sections and multiple load patterns. Hand calculation becomes a system of simultaneous equations that'll take an hour to set up and another hour to solve by hand, if you're fast. The stiffness method automates that setup. You define the nodes, the elements, the boundary conditions, the material properties, the loads, and the computer assembles the global stiffness matrix, applies the boundary conditions, solves for displacements, and back-calculates member forces. That's it. The software does the linear algebra. Your job is making sure the input model is right. For trusses, the analysis is simpler because members carry only axial load. Each node has two equilibrium equations in 2D, three in 3D. For frames, each node has three degrees of freedom in 2D — horizontal displacement, vertical displacement, and rotation. The DOF count determines the size of your system. A ten-story frame model might have three thousand nodes, meaning nine thousand simultaneous equations in 2D. That's trivial for a modern solver but requires you to understand what each degree of freedom represents. Static analysis assumes loads are applied slowly and remain constant. Dynamic analysis accounts for time-varying loads — earthquakes, wind gusts, machinery vibration. Modal analysis is the first step in dynamic work. You find the natural frequencies and mode shapes. If a harmonic load matches one of those frequencies, you get resonance, and the response can be enormous. I saw this once with a mezzanine floor supporting a rotating compressor. The second natural frequency was 4.2 hertz, and the compressor was running at 252 RPM, which is exactly 4.2 Hz. The floor was vibrating visibly under normal operation. The fix wasn't to add more steel everywhere — it was to add a stiffener in the right place to shift that natural frequency away from the excitation frequency. Targeting the frequency, not just the stress, is the kind of insight that separates people who do structural analysis from people who just run software.

Common Pitfalls That Wreck Models

The biggest source of error isn't the math. It's the modeling assumptions. Here are the ones that get people in trouble: Boundary conditions. You can get completely wrong answers from a perfectly assembled stiffness matrix if your supports aren't realistic. A column base modeled as fixed when it's actually a anchor bolted plate with some rotation will give you unconservatively low moments in the column and unconservatively high moments in the base plate. Conversely, modeling a springy support as rigid will overestimate lateral stiffness and underpredict drift. I spent a week on a project where the soil-structure interaction was the issue. The foundation was on compressible soil, and the initial model with fixed bases predicted drift within limits. Once we added Winkler springs with the correct modulus of subgrade reaction, the drift exceeded limits by forty percent. The redesign involved larger footings and a mat foundation. The lesson: always question your boundary conditions, especially for foundations and supports that aren't monolithic. Mesh density. Finer is better up to a point, but there's diminishing returns. For stress concentration areas — holes, notches, re-entrant corners — you need a refined mesh. The stress there varies rapidly, and a coarse mesh will smooth it out and give you non-conservative results. For overall behavior, a coarse mesh is fine. My rule of thumb: refine the mesh in regions where you care about local stress, keep it coarse elsewhere. This cuts computational time from something like twenty minutes to maybe four minutes on a typical model.

Load paths. If you apply a load to a model and the software returns a solution but the load path doesn't make sense — reactions don't balance, internal forces jump unexpectedly — something is wrong. Always check equilibrium. The sum of external loads should equal the sum of reactions. The bending moment diagram for a continuous beam should be smooth except at point loads. If it's not, you've got a modeling error somewhere. P-Delta effects. For tall or slender structures, second-order effects matter. P-Delta is when lateral displacement causes additional moments because gravity loads act through the displaced shape. A first-order analysis will underpredict drift and member forces. The rule of thumb: if the stability coefficient theta = (P * delta) / (V * h) exceeds 0.1, you need second-order analysis. I've seen engineers skip this on buildings over six stories and come back to fix it after peer review caught it. That costs time and credibility.

When Hand Calculations Still Matter

There's a trend toward relying entirely on software. I disagree with that approach for anything beyond the simplest structures. Hand calculations serve as sanity checks. Before you run a complex model, do a rough estimate. A simply supported beam with uniform load — max moment is wL²/8. If your software output is significantly different from this ballpark number, investigate before trusting the model. This catches input errors, wrong load combinations, and misapplied boundary conditions. A ten-minute hand calc can save you from signing off on a flawed analysis that would require weeks of rework to correct. Also, the code checks. Structural analysis gives you forces. Design codes tell you the allowable capacities. These two don't always align neatly. A member might satisfy strength requirements but fail serviceability limits — deflection, vibration, crack width. I once had a long-span composite slab that was strong enough but deflected six inches under live load. The client was not happy. The fix required increasing the slab thickness and adding a drop panel, which meant reworking the ceiling grid and lighting layout. The initial model had checked the strength but I hadn't flagged the deflection check prominently enough in the output report. Serviceability matters as much as strength, and it's easy to overlook if you're only looking at utilization ratios.

Advanced Topics and Where Things Break Down

Nonlinear analysis handles material nonlinearities — plasticity, cracking, creep — and geometric nonlinearities — large deformations, buckling. This is where structural analysis gets expensive computationally and tricky to interpret. A nonlinear analysis might require hundreds of load increments and iterative solutions at each step. Convergence problems are common. I've had models that wouldn't converge because of contact nonlinearities between overlapping elements or because of tensile stress in concrete without proper cracking models. The workaround was usually to simplify the model — remove unnecessary contacts, use simplified material models, or switch to a different solver strategy. Buckling analysis is another area where software can be misleading. Eigenvalue buckling gives you a critical load factor, but it assumes perfect geometry and linear material behavior. Real structures have imperfections. The practical approach is to run a geometric nonlinear analysis with initial imperfections scaled to code-recommended values — typically L/1000 or L/500 depending on the member type. The difference between eigenvalue and nonlinear buckling analysis can be significant. For a steel column with initial crookedness, the nonlinear analysis might show failure at sixty percent of the eigenvalue prediction. That's not a small difference. Seismic analysis is perhaps the most complex application. Response spectrum analysis is the most common approach in practice. You define the site spectrum based on seismic zone, soil type, and importance factor. You run modal analysis to get the participating masses in each mode. You combine the modal responses using CQC or SRSS. The result is approximate but accepted by codes. Pushover analysis, also called nonlinear static procedure, is used for performance-based design. You push the structure laterally until it reaches a target displacement, tracking the base shear versus top displacement curve. This reveals the ductility demand and potential failure mechanisms. I've used pushover analysis to identify that a soft-story mechanism was developing in a retrofit project. The original structure had a weak first floor with large openings for parking. The pushover curve showed a sharp drop in capacity after yielding at the first floor columns. The retrofit added steel bracing to the first floor, which the pushover analysis confirmed eliminated the soft-story mechanism. This kind of targeted intervention is more effective and economical than a blanket strengthening approach.

Software Choices and Their Limits

SAP2000 and ETABS are workhorses for building structures. ANSYS and Abaqus handle more complex nonlinear and specialized analyses. RISA and STAAD are popular for steel and concrete design integration. Each has its strengths. SAP2000 is fast and reliable for linear static and dynamic analysis. ETABS adds building-specific features like diaphragm modeling and code-checking for concrete and steel. Abaqus excels at nonlinear contact and material behavior but requires more expertise to use correctly. I generally recommend using software that matches the complexity of your problem. Don't use Abaqus for a simple steel frame — it's overkill and increases the chance of modeling errors. Don't use ETABS for a suspension bridge — it's not designed for that. The output format matters too. Make sure your software gives you enough detail. Reaction forces, member end forces, nodal displacements, stress contours. If you're only looking at utilization ratios, you're missing important information. I always request the raw output — member forces at each node, reaction components, displacement vectors. This lets me verify the results independently and spot anomalies that the software's automated checks might miss. Document everything. Version control your models. Record your assumptions, load cases, and design decisions. When someone asks why you chose a particular member size or why a drift limit is satisfied, you need to be able to trace it back to the model input. I've had projects where the original modeler left the company, and the replacement had to rebuild the entire analysis from scratch because there was no documentation. That's a failure of process, not of technical skill, and it's entirely preventable.