From mass definition to rigid-floor assumptions, the quality of your checks depends on the choices the engineer makes on the model, even before the analysis runs. A conscious approach to the FEM model leads to more reliable verifications and a better reading of the structural behaviour.

The model does not lie. But you have to question it.

With the Italian NTC 2018 code and its 2019 explanatory Circular, the finite element model has taken a central role in structural design. It is no longer a tool for checking results at the end. It is the core of the design process: the model is where the seismic response is built, the sections are sized, and the global behaviour of the building is defined.

The phrase I repeat most often is: “simplify, simplify, simplify”.

The FEM model should not be a three-dimensional rendering of the building. It should be a simplified representation of reality, built around the assumptions we make when we set it up.

A useful exercise, before building any model, is to ask: how would I solve this problem by hand? Not because hand calculation is always practical (it is not), but because that reasoning forces us to make the assumptions explicit before handing them to the software. How would I schematise the restraints? Which loads would I include? Which effects would I neglect?

And precisely because it is a simplification, the model is full of assumptions: assumptions that belong to the engineer, not to the software. It is worth recalling how many we make, often without noticing.

The choice between linear and non-linear analysis: linear analyses are acceptable only within certain limits of structural behaviour, just as non-linear equivalent-frame analyses give reliable results only for some structural types.

The plane-sections assumption, central to Euler-Bernoulli beam theory, which works well for slender members but can become a stretch for stocky members or for open sections with significant warping effects.

The idea that second-order effects are negligible (the well-known P-Δ analysis), which in slender structures or under high loads are not negligible at all: ignoring them means systematically underestimating the actions in compressed members.

The assumption of a homogeneous and isotropic material, which is already a simplification for reinforced concrete, and can become a significant stretch for timber walls.

None of these assumptions is wrong in absolute terms. Some are well established and widely validated. But they are all choices made by the engineer, and as such they require awareness.

The same applies to the choice of software. Here too I often use an analogy: structural analysis software is like cars. I would not use a competition off-roader to drive through a historic city centre with narrow streets, and I would not take on the Paris-Dakar with a city car. Each tool is designed for a context, has strengths and limits, and using it outside its optimal field means wasting resources or producing results you cannot rely on. For each project you should identify the most suitable tool: not the most powerful, not the best known, not the cheapest.

The most suitable one.

With this in mind, here are the control questions that help you build a solid model.

Restraints: did I really connect every node?

Restraints are perhaps the most treacherous part of the model, precisely because their effects are often invisible at first sight. An unconnected node, a forgotten release in a beam, a foundation that was not assigned: each of these details can deeply change the stiffness distribution, the natural periods and, as a result, the whole seismic response of the structure.

A recurring example concerns Winkler stiffness assigned only to part of the foundation system. The portion without elastic support tends to “hang” from the rest through the beams, distorting the deformed shape of the foundation plane and therefore the distribution of seismic actions on the columns. In these cases the results look plausible and no error messages appear, but the anomalies become visible by checking the soil pressure map or the amplified deformed shape. A mirror case happens when some roof beams are classified as foundation elements: the structure tends to “hang” from the roof instead of discharging to the ground, with a distribution of vertical actions that the soil pressure check identifies easily.

The opposite effect occurs when the foundation is made too stiff: assigning perfect fixities to very flexible isolated footings can change the fundamental period of the structure, and with it the base shear and the distribution of seismic forces across the floors.

The recommendation is simple but worth repeating: the restraint model must reflect the real support conditions, not the ones that are easiest to enter. When soil-structure interaction is significant (and NTC §7.2.6 clarifies when it is), it must be modelled explicitly.

Rigid diaphragms: is my rigid-floor assumption actually valid?

The assumption of an infinitely rigid diaphragm is one of the most used in structural modelling, and one of the most misunderstood. It is a powerful boundary condition (it reduces the degrees of freedom, simplifies the model, speeds up the calculation) but it is applicable only when the floor has enough in-plane stiffness relative to the vertical structures.

In practice, this condition is not always met. Light roofs with joists and hollow-clay blocks, timber floors with a single board layer, structures with large openings or strongly irregular plans: in all these cases, the rigid diaphragm assumption introduces an artificial stiffening that changes the distribution of seismic actions among the vertical elements. Structural torsion, in particular, is systematically underestimated.

The topic is even more delicate in the existing building stock, where floors are often deformable by construction. A vaulted floor, a hollow-brick-and-concrete slab without adequate connectors, a pitched roof with a timber structure: treating them as rigid diaphragms distorts the seismic response of the building.

In PRO_SAP, for instance, the infinitely rigid floor assumption is never applied automatically and indiscriminately: floors are modelled with membrane finite elements, with customisable material and thickness, coming close to the real behaviour. A key condition, however, is that the floor elements actually touch all the nodes on the perimeter of the structure: only then can the rigid floor perform its role of restraint and redistribution.

Seismic masses: did I include everything that has weight?

Seismic masses are the entry point of the actions into the dynamic model. An inaccuracy in the masses becomes an inaccuracy in the base shear, in the natural periods, in the whole acceleration response.

The situation that comes up most often in technical support concerns floors added at a later stage of the modelling process. You build the frame, you run the first model checks, then you add the floors but you forget to enter the matching load cases. The model runs with no error messages, but the masses are incomplete. A check of the axial forces in the columns (comparing the model values with a rough estimate) brings the anomaly to light.

The weight of the infill walls also deserves attention. In structures with heavy infills (thick clay-brick masonry) their mass contributes decisively to the dynamic response. Neglecting them or representing them with reduced values shows up directly in the natural periods and in the seismic demand.

A model with incorrect masses can return results that look plausible but are physically unreliable. The load check should be systematic: graphically, through the display of the load assignment, and analytically, by verifying that the axial forces in the model are consistent with the manual estimates.

Load combinations: did I regenerate them after the last change?

Modern software generates load combinations automatically, according to the code provisions. This is a valuable help: it reduces manual errors and ensures full coverage of the required cases. But automation needs to be understood in order to be used well.

The sequence to watch is the following: you generate the combinations at the start of the analysis, you add new load cases while working, and you rerun the calculation without regenerating the combinations. The result is that the new actions do not enter the verification combinations, even though they are present in the model. The checks look formally complete but are substantially incomplete.

The operating rule is simple: every time you change the load cases, the combinations must be deleted and regenerated. Not updated, not integrated by hand: deleted and regenerated.

Reading the results: the real work of the engineer

A numerically precise result is not necessarily correct from an engineering point of view. This statement describes one of the main challenges of modern structural design: the software produces a huge amount of data, but the value of that data depends entirely on the engineer’s ability to read it critically.

There are checks that every seismic analysis should include systematically, before moving on to the verification of the structural elements.

The first is the participating mass: for each analysis direction, the modes considered must cover at least 85% of the total mass, otherwise the number of vibration modes must be increased.

The second check concerns the natural periods. A first-attempt estimate of the fundamental period (for example T₁ ≈ C·0.075·H^0.75 for framed buildings) is not a design value, but an order-of-magnitude reference. If the model period differs significantly from this estimate, it is worth understanding why: it may be an expected effect of the geometry, or the sign of a modelling inconsistency.

The third check is the one on the support reactions: the sum of the vertical reactions must balance the applied loads.

There is then a more subtle point, which the support reactions make immediately clear: nodes in elevation (that is, nodes that have nothing to do with the ground) to which external restraints have been assigned. The cause is almost always a conceptual confusion between two entities that carry the same name in structural terminology: the internal hinge, which is a release between adjacent elements and produces no support reactions, and the external hinge, which is a restraint against the ground and does produce a reaction. Same word, radically different meaning.

The practical result is that assigning external restraints to roof nodes makes the structure appear restrained at the roof instead of at the foundation (or in addition to it), with distributions of actions that make no physical sense. The software has no way of knowing that those restraints do not match the design intent: it runs the calculation flawlessly on a structurally inconsistent model. Only the check of the support reactions (verifying that they appear only at the foundation nodes and that their sum matches the applied loads) makes it possible to catch this situation before it spreads to the verifications.

Finally, the consistency of the deformations, and this applies both to the modal shapes and to those under static loads.

Let us start from the deformed shapes under gravity and seismic actions: they must be qualitatively believable. You do not need sophisticated calculations to notice that something is off: abnormal displacements in a beam, excessive vertical settlements on a column (which may not be connected to the mesh of the raft), disproportionate horizontal translations under moderate horizontal actions are all signals to look into. The eye of an experienced engineer should stop on these anomalies even before reading a number.

A check I always recommend, and which costs very little time, is the one on the contact pressures of the foundation elements. An anomalous distribution (isolated peaks, elements with zero pressure, unexpected sign reversals) almost always reveals a property assignment that needs review. The graphical check of the soil pressure map is a step that should never be skipped.

For the modal shapes, the reasoning is similar. The first mode shape of a regular building should look like the deformed shape of a cantilever fixed at the base: zero displacements at the foundation, growing smoothly towards the top, without abnormal discontinuities between floors. A twisted mode shape, with sign reversals between adjacent floors or with nodes moving in the opposite direction to the rest of the structure, almost always signals something to verify: a restraint to review, an inconsistent stiffness, a disconnected element.

The role of the software: control, not just calculation

Modern structural analysis software is no longer (or should no longer be) a simple finite element solver. It should support the engineer along the whole process: from setting up the model to reading the results, including the check of the consistency of the assumptions and the detection of anomalies.

At 2S.I. we have worked on this aspect for years with PRO_SAP, our structural analysis software. Some of the features we find most useful are not about solver power, but about the ability to support the engineer in checking the model: the automatic check that flags overlapping elements, null masses or elements with intermediate nodes; the graphical display of the load assignment, which lets you spot at a glance the elements without load in a complex model; the check of the participating masses; the automatic management of the combinations.

The fact that many of the situations described in this article keep appearing in daily practice suggests that the model-checking stage (distinct from the analysis stage and from the section verification stage) deserves more attention than it usually receives.

Conclusion

The quality of seismic verifications depends more and more on the quality of the structural model. The NTC 2018 code has raised the required standards, but a code can define what to verify, not how to build a reliable model. That remains the engineer’s task.

The number produced by the software is the end point of a chain of decisions: geometry, restraints, materials, loads, combinations, modelling assumptions. Every weak link in this chain shows up in the final result, often in a way that is not immediately visible. Technical competence is not about knowing how to use the software, but about knowing how to read critically what the software produces.

The questions collected in this article are not about inexperience. They are about process, about habit, about the right balance in relying on automation. The method is always the same: ask the right questions, check, verify, compare with engineering judgement.

Eng. Gennj Venturini – venturini@2si.it