Finite Element Analysis in Product Design - 
Getting It Right, Not Just Getting It Done
By Vince Adams, Director of Analysis Services
NAFEMS Registered Analyst - Advanced

IMPACT Engineering Solutions, Inc.

 

When the word “standards” is mentioned in an engineering context, plenty of acronyms come to mind such as ISO, ANSI, ASTM, & SAE to name a few.  One acronym that rarely gets associated with standards is FEA (Finite Element Analysis).  Most FEA users in traditional product development environments take for granted that the results calculated by their FEA tool are accurate, or at least the correct solution to the question posed, by means of their choice of boundary conditions, properties, and geometry.  While in most cases, the latter is true, it is important to remember that a successful FEA project requires that at least three complex processes be carried out properly.  First, the user must be capable of and qualified to pose a ‘question’ correctly to the software.  Second, the software must be mathematically robust and accurate enough to provide a good solution.  Finally, the user must again be capable of and qualified to understand the results and assess the performance of the system under study based on these results.  None of these steps should be taken for granted.

The second step in that process, the numerical accuracy of the solver is perhaps the easiest to quantify.  In 1983, an organization called NAFEMS (www.nafems.org) began to develop a set of standards, or benchmarks, with the specific intent of validating FE solutions and technologies.  The solutions to these benchmarks provide vendors and users alike to assess the quality of the FE solution.  Today, NAFEMS has developed benchmarks for statics, dynamics, nonlinear, and contact.  These benchmarks serve a dual purpose, acting as an educational tool as well. 

While NAFEMS has provided a set of standards against which FE vendors can prove to you, the user, that their code is capable of correctly solving a properly formulated ‘question’, the discussion must turn to the other two steps in the process.  How can you or your management be confident that you are capable of formulating that question and qualified to interpret the results.  It is in these areas that most users, rookie or veteran, point to their degree from an accredited engineering university and their certificate of completion from the introductory FE vendor training as evidence of qualification.  Unfortunately, as the proliferation of FE software and the enormous advances in ease-of-use have outpaced FE education, users across the industry must acknowledge that this is no longer good enough.

At the 2001 NAFEMS World Congress in Lake Como, Italy, I presented three brief case studies highlighting typical mistakes in meshing, boundary conditions (loads and constraints), and problem definition.  These mistakes completely invalidated any results calculated by the solver and in each of these cases, the respective analysts would have characterized themselves as experts.  In fact, their companies considered them to be experts!

The important point in all this is that while software vendors have gone to great lengths to make their codes accurate and easy to use, most users aren’t holding up their end of the bargain by learning the techniques, engineering, and discipline required to successfully use these products.  If these ‘experts’ I described previously can’t properly assess their own skill level, what chance do part-time design analysts have to get it right?  On-going support and education in FE basics as well as engineering mechanics and failure theory will go a long way to address this problem.  Organizations like NAFEMS and IMPACT Engineering Solutions have addressed these issues thru the development of code-dependent and independent training classes, seminars and quality control tools.  However, the old saying, “You can lead a horse to water…” applies here too.

As FEA becomes more mainstream in the product design world, control systems and checks/balances are becoming more the exception than the rule.  Unfortunately, putting analysis tools into the hands of rookies or part-timers without some means for control and standardization is a recipe for disaster.  In a dedicated analysis group where the supervisor is a former analyst of similar skill level to his team, all members of the team speak the same "language" and the supervisor knows what to look for and where to look for it when evaluating a project.  This is not the case in most of today's design environments.  Now more than ever, managers in a product development organization that has embraced simulation need tools to quickly and accurately assess the accuracy and effectiveness of their analysis efforts.

Standards and certification of skill level are important in all aspects of engineering, from fasteners to simulation.  Engineering organizations that fail to embrace these standards face huge risks in revenue and product safety.  Whether it is a bolt failing or a weldment buckling due to improper testing or analysis, all design engineers and managers must take responsibility and accept accountability for all the parts, tools and techniques used in their product development process.