5.6. VERIFICATION 81
1. upper and lower bounds of the real solution or
2. the correct solution in only part of the global domain.
When using experimental results for validation, one should consider the following.
1. ey are often considered the harbinger of truth.
2. Boundary constraints more easily realized in the laboratory can sometimes be difficult to
realize in a computational model, for example, machine compliance for a tensile test speci-
men.
3. Boundary constraints more easily realized in discrete analysis can sometimes be more diffi-
cult to achieve in the laboratory.
4. Experiments can be costly and time-consuming.
Numerical analyses should not be trusted without either theoretically or experimentally validat-
ing the solution. Neither should the results of numerical analyses be accepted without proper
examination of insensitivity to the mesh discretization. As in Example 4.2, a proper convergence
study should always be attempted. Correct results can only be obtained in the limit as the results
are no longer sensitive to the use of any finer discretization of the global domain. We term such
convergence mesh insensitivity. When the results fall within a specified insensitivity to the mesh
or element size, one can conclude the numerical analysis has converged. It is important to note
that this is a necessary but not sufficient condition for the computational results to be acceptable
or a correct solution to the problem posed. Recall that the solutions in Example 4.2 eventually
converged, but those assuming plane strain conditions were incorrect, i. e., they solved the wrong
problem.
5.6 VERIFICATION
Extensive tests showed that many software codes widely
used in science and engineering are not as accurate as
we would like to think.
Les Hatton
Oakwood Computing
By verification, we refer to the process of determining that a model implementation accurately
represents the developer’s conceptual description. Verification provides evidence that the numeri-
cal model is solved correctly. It is tacitly assumed that commercial software is completely debugged
before a version is released. Les Hatton at Oakwood Computing has presented interesting find-
ings that indicate errors in software and programming, while small in number, do occur. is
sometimes happens in commercial FEA software. Most instances of which we are aware have
82 5. WISDOM IS DOING IT
been in the post-processing software. While the primary variable solution is most often entirely
correct, sometimes listings and contour plot variables are not stored correctly and are subsequently
improperly displayed. Luckily, these instances are rare and not a primary cause of errors on the
part of the analyst. In any case, they can be caught by prudent use of preliminary analysis.
We believe that the majority of textbooks addressing introductory finite elements primarily
and predominantly emphasize the mathematical foundation and procedural application of the
method. We have emphasized, rather, a practical approach based on recognition that most errors
made in application of the method are in pre- and post-processing and are made mostly in model
development. Further interesting reading regarding issues of practical application of the finite
element method can be found in Dunder and Ridlon [1978], Dvorak [2003], Gokhale et al.
[2008], Morris [2008], and Sastry [2010].
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.