Structural Modeling Best Practices: Common Mistakes That Compound Through a Project
November 7, 2026
No Comments
Every structural analysis package, Robot Structural Analysis included, runs a set of automated design checks once your model and loads are in place — member capacity ratios, deflection limits, code-specific safety factors, and more. For someone new to this, it’s easy to assume the software is “checking your design” the way spellcheck checks a document. It’s worth being precise about what’s actually happening, because the gap between what automated checks verify and what a licensed structural engineer is actually responsible for is exactly where real project risk lives.
When you run a design check in Robot Structural Analysis (or any comparable package) on a steel beam, for example, the software is comparing your applied loads and resulting internal forces against the capacity equations defined in whichever design code you’ve selected — say, AISC 360 for steel. It calculates ratios: actual demand versus allowable capacity for bending, shear, axial load, and combinations of these, plus serviceability checks like deflection limits. A ratio under 1.0 generally means the member passes that specific check under that specific code’s rules.
What it is not doing is verifying that your structural idealization of the real building is itself correct — that your load assumptions are realistic, that your boundary conditions genuinely reflect how the structure will actually behave, or that you haven’t mismodeled a connection in a way that understates real stress concentrations. The software is rigorously checking math against a rule set; it has no way of independently knowing whether the problem you handed it accurately represents the real building.
This is more layered than a single national building code, because the UAE’s structural engineering practice draws on a genuine mix of international codes depending on jurisdiction, client, and the engineer’s own training background.
For Dubai specifically, Administrative Resolution No. (37) of 2021 sets out several concrete, binding requirements: structural designs must be prepared by a licensed structural engineer; the minimum design wind load for buildings and steel structures must not be less than 1 kN/m²; and steel structures must be designed to the latest editions of American, European, or British standard codes — explicitly naming AISC 360 and AISC 341 for steel design, alongside the AWS D1.1 welding code.
Dubai’s free-zone authority, Trakhees, separately publishes its own Building Regulations & Design Guidelines for structural work, with dedicated sections addressing steel structures and applicable design codes. Abu Dhabi’s plan-review process for concrete buildings, by comparison, references ACI 318 for reinforcement design and ASCE 7 for load and seismic requirements — a different but overlapping code family.
| Authority / Jurisdiction | Key Referenced Codes | Notable Requirement |
|---|---|---|
| Dubai Municipality (Admin. Resolution 37/2021) | AISC 360, AISC 341, AWS D1.1 (steel); latest American/European/British editions allowed | Minimum design wind load of 1 kN/m²; licensed structural engineer required |
| Trakhees (Dubai free zones) | Own Building Regulations & Design Guidelines — Structural (first issued 2011) | Dedicated steel structure and design code sections |
| Abu Dhabi | ACI 318 (reinforced concrete), ASCE 7 (loads/seismic) | Plan-review checklist references specific code clauses directly |
Academic reviews of UAE practice — including a British University in Dubai dissertation comparing ACI 318-14, BS 8110-97, and Eurocode 2 for reinforced concrete — make an important observation worth internalizing: engineers practicing in the UAE come from a genuinely wide range of countries and training backgrounds, and in practice apply a correspondingly wide range of regional codes depending on where they trained and which code a given client or consultancy has standardized on. This is part of why UAE structural practice isn’t a single-code environment the way some countries are — it’s a multi-code environment by design, and knowing which code applies to your specific project and authority matters as much as knowing the code itself.
Practically, this means one of the first real decisions on any UAE structural project is confirming which code library the analysis software should be set to check against — and that this isn’t always a single, simple choice. A project might need steel checked against AISC while concrete is checked against a different code family depending on client preference, consultancy standard, or jurisdiction. Getting this wrong at the outset doesn’t just produce an inconvenience; it means every automated check the software runs afterward is validating your design against the wrong rule set entirely, which is a far more serious error than any individual failed check within the correct code.
A software-generated “pass” on every member doesn’t mean the structure is actually sound if the underlying model has a real error the software has no way to detect — an unrealistic support condition, a missing load case, an idealization that doesn’t match how the structure will genuinely behave under real conditions. This is precisely why Dubai’s own regulation requires a licensed structural engineer to prepare the design, not simply to run software and submit its output. The software’s job is to check a very large number of calculations accurately and quickly; the engineer’s job is to decide what those calculations should actually be checking in the first place, and to catch the kinds of errors no automated check can see.
In practice, structural submissions to Dubai Municipality or other reviewing authorities are typically supported by software-generated calculation reports — Robot Structural Analysis, ETABS, and SAFE can all produce these — but the submission itself still requires the licensed engineer’s stamp and sign-off, along with, depending on the project and consultancy, an internal peer review. One engineering firm’s own description of its process is a useful, concrete example: designing reinforced concrete and steel to BS/Eurocode and UAE codes, then peer-reviewing the work in-house before it goes to Dubai Municipality attestation and DDA review. The software output supports that process; it doesn’t substitute for it.
It’s worth separating two categories of design check that software runs, because they answer genuinely different engineering questions. Strength (or ultimate limit state) checks ask whether a member can safely carry its design loads without failing — the bending, shear, and axial capacity ratios most people picture when they think of a “design check.” Serviceability checks ask a different question: whether the structure performs acceptably under normal, everyday use, even though it isn’t close to failing — deflection limits are the clearest example, since a floor that sags visibly or vibrates noticeably under footfall can be a real serviceability problem long before it’s anywhere near a strength failure. A structure can pass every strength check and still fail a serviceability check, or vice versa in less common cases, which is exactly why both categories need to be run and reviewed, not just the strength checks that feel more obviously “safety-related.”
Every design check is only as meaningful as the load combinations feeding into it. A design code doesn’t just specify how to check a member against a single load case — it specifies how different load types (dead load, live load, wind, seismic, where relevant) must be combined, with specific load factors, to represent realistic worst-case scenarios the structure might actually experience. Setting up these combinations correctly, matching the specific code’s required factors and combination rules, is a foundational step that happens before any individual member check becomes meaningful. A perfectly executed member check run against an incorrectly defined load combination produces a confidently wrong answer — which is precisely the kind of software-assisted error that engineering review is meant to catch.
A failed design check (a ratio over 1.0) isn’t necessarily a sign of a fundamentally unsafe design — it’s frequently a normal, expected part of the iterative design process, flagging that a specific member needs to be resized, reinforced differently, or that its governing load combination needs a second look. Treating every failed check as an emergency, or conversely treating every passed check as final proof of safety, both miss the point: design checks are a tool for iterating toward a genuinely sound design, not a one-shot pass/fail verdict on the engineer’s competence. Experienced engineers expect a meaningful number of initial checks to fail on a first analysis pass, and build revision into their process accordingly rather than treating it as unusual.
No. Software checks calculations against a chosen code’s rules; a licensed structural engineer is required to prepare, review, and take professional responsibility for the design under Dubai’s regulations, and most UAE authorities require a stamped submission, not just a software report.
Administrative Resolution No. (37) of 2021 sets a minimum of 1 kN/m² for buildings and steel structures in Dubai. Always confirm this and any updates against the current official resolution rather than relying on a secondhand summary.
Because UAE structural practice draws on a genuinely international mix of training backgrounds and client/consultancy standards, with Dubai Municipality, Trakhees, and Abu Dhabi authorities each referencing somewhat different (though overlapping) code families, and individual clients sometimes specifying a preferred code set.
It confirms the members you modeled satisfy the specific code checks you ran, given the loads and boundary conditions you defined. It does not independently verify that those loads, boundary conditions, or modeling assumptions themselves correctly represent the real structure — that judgment remains the engineer’s responsibility.
Orbit’s Robot Structural Analysis course covers running design checks against relevant code libraries as part of a realistic UAE project workflow, rather than treating code selection as an afterthought.
A strength check verifies a member won’t fail under its design loads; a serviceability check verifies the structure performs acceptably under everyday use, such as not deflecting or vibrating excessively, even when it’s nowhere near actual failure. Both categories need to be checked, since a structure can pass one and fail the other.
The licensed structural engineer who stamped and submitted the design, not the software vendor. This is precisely why Dubai’s regulations require a licensed engineer’s sign-off rather than accepting a software-generated report as sufficient on its own — professional accountability sits with the person certifying the design, regardless of which tool produced the supporting calculations.
Yes, and it happens regularly in UAE practice — a project might check steel members against AISC provisions while checking concrete members against a different code family, depending on client preference, consultancy standard, or the specific authority reviewing the submission. The important discipline is making that choice deliberately and documenting it clearly, not leaving it ambiguous or inconsistent across the design team.
It’s worth walking through what “attestation” actually involves in practice, since the term gets used often without much explanation. After a structural design is complete and internally checked, the consultancy typically assembles a submission package that includes the structural drawings, the design calculations (often software-generated, as described above), and supporting documentation demonstrating code compliance. This package goes to Dubai Municipality (or the relevant authority, such as Trakhees in a free zone, or Abu Dhabi’s equivalent process) for review and formal attestation — essentially, the authority’s own check that the submission meets its requirements before construction can proceed on that basis. A licensed structural engineer’s stamp on the submission is what makes the consultancy, and that individual engineer, professionally and legally accountable for the design — which is precisely why no amount of software-generated reporting can substitute for that sign-off. Processing timelines and specific document requirements can vary and change, so project teams should always confirm current requirements directly with the relevant authority rather than relying on a general description like this one.
Occasionally, a structural engineer runs into a situation where the software’s default interpretation of a code clause doesn’t quite match how they understand the clause should apply to an unusual real-world condition — an irregular geometry, an unusual load path, a unique connection detail the code’s standard provisions don’t cleanly address. This is exactly the kind of situation where engineering judgment, not software default behavior, needs to govern the final decision. Most serious analysis packages, Robot Structural Analysis included, allow an engineer to override specific default assumptions or apply manual calculations alongside the automated check for exactly this reason — the software is a powerful calculation tool operating within the rules it’s been given, not an independent authority on how those rules should apply to every unusual real-world edge case. Recognizing when a situation calls for that kind of manual judgment, rather than trusting a default software output uncritically, is itself a mark of real engineering maturity, not a sign the software has failed.
Automated structural design checks are a genuinely powerful, necessary part of modern structural engineering practice — but they check a model against a code’s math, not reality against your engineering judgment. In a multi-code environment like the UAE, knowing which codes actually apply to your specific project and authority, and treating software output as a support tool for professional judgment rather than a replacement for it, is the difference between a compliant design on paper and one that’s actually sound.