Creating a mathematical model from a CAD model requires first defining the geometry, loads, and restraints along with a type of analysis, such as linear static or transient thermal.

**Paul M. KurowskiPresidentDesign Generator Inc.London, Ontario, Canada**

**Edited by Paul Dvorak**

Doing so brings simplifying assumptions that cause modeling errors to the math model.

A correctly formulated mathematical model captures the characteristics of an object needed to make design decisions. For example, analysis of a compliant link under static load requires nonlinear FEA to handle expected large displacements. A cooling simulation requires a thermal analysis (steady state or transient), while a drop test would call for a nonlinear dynamic analysis. So the software must fit the problem.

The mathematical model must be discretized into finite elements. We commonly call this discretization process meshing. While a meshed model is easy to illustrate, it may be confusing because it implies a mesh is just imposed on model geometry. Nodes connected by lines show finite elements, but in fact, nothing of the CAD model remains. Continuous geometry is replaced by nodes and interactions between nodes is defined by elements connecting the nodes.

Meshing converts a mathematical model (geometry, loads, and restraints) into an FEA model. That act ion compounds errors, and these are called discretization errors. For instance, an inappropriate element may be incapable of capturing a real stress distribution. Results such as displacements and stress distribution may provide useless or insightful information depending on how well elements are used.

After creating an FEA model, its solution is a matter of solving a large number of linear equations. The solution introduces numerical errors, although they are usually low. Finally, results are analyzed to make design decisions.

Each step takes us further from reality, which is where we started. Errors are introduced at each step, some of them unavoidable, while others amount to FEA malpractice. Hence, it makes sense to verify models and validate results.

Although verification and validation sound similar, there is a difference FEA users should know. **Verification** determines the mathematical model, as submitted for solution with FEA, has been solved correctly.

**Validation**, on the other hand, determines whether or not FEA results correctly represents reality from the perspective of the intended use of the model. It checks that results correctly describe real-life behavior of the object. The chart *Verification and validation *further highlights the difference between the two.

But things can also go wrong when validating and verifying models. For instance, verification fails when meshing is incorrect. Models with meshing errors, such as using one layer of first-order solid elements in a bending beam, or using a mesh too coarse to capture a pattern, would not pass verification tests. Models with incorrectly defined loads would pass a verification test because verification only tests for correctness of the finiteelement solution, not that the mathematical model is correct.

Establishing that a solution correctly predicts a real object’s behavior is the task of validation, which should follow verification. Validation fails when a model cannot provide needed data. The two-link model from the June *FE Update* cannot find or report on its stiffness. And the square rod in the rubber block, also from the previous column, cannot be used to find the deformed shape of the rubber block.

FEA errors may be due to verification, validation, or both. FEA software is not at fault in any of the cases discussed. Place blame for the errors on not understanding the modeling process and fundamental FEA assumptions which let us attribute properties of real objects to FEA models. Only proper training in FEA fundamentals prevents errors.