25 Things Managers Should Know about FEA

By Derek Pashley

Editor’s note: This article has been adapted from an article that originally appeared in benchmark, a NAFEMS publication. For more information, visit nafems.org.

“NAFEMS is the International Association for the Engineering Analysis Community: the only independent,  international membership body for companies involved in simulation and analysis at every level. With over 950 members worldwide, the organization is a powerful voice in the CAE world, drawing support and membership from industrial users,  software vendors and academic institutions from around the globe. If you work with simulation, you should be part of NAFEMS. Visit www.nafems.org for further information.”

NAFEMS, an independent member organization dedicated to computer modeling and simulation methods, asked engineers what mangers needed to know about finite element analysis (FEA). Selected responses are below. Contributors are mainly stress engineers or engineers from similar disciplines. If your managers need to be educated about FEA, show them a copy of this as a conversation starter.

The Design Process
1. Think about where FEA is placed in your design process. Hand calculations and/or FEA before CAD (for 3D definition)  is smart. There are uses for CAD programs to produce a preliminary design, too. FEA has ramifications beyond computer-aided engineering (CAE). Input data comes from the real world and components are made there too. FEA and simulation aren’t really CAD add-ons or a subset of CAE. It’s about understanding everything you’ve done to date and what you are about to do. People who get this right are those who see FEA as an extension of hand calculation and design by numbers, people who get this wrong think the computer has a hotline to a greater truth beyond our comprehension.

2. Analysis by FEA after CAD, is not design, it’s autopsy (or design fault-finding).
This is an important point: FEA is often used too late to be effective and just flags problems rather than solving them, but customers—internal or external—sometimes have to have their needs met, even though it may diminish the efficacy of the design process.

3. CAD is for making shapes. CAD is no more “design” than Microsoft Word is “Twelfth Night.” In less hype-worthy times,  the D in CAD used to mean “drafting.” Maybe by CAD we mean finalized production definitions and doing the FEA after doing this is almost as daft as doing it after you’ve made stuff. Apologies for being “off subject” of FEA.

4. If you must go around the “draw it,  stress it, change it loop” then at least use CAD, particularly for 3D definition, with FEA in mind in order to help mesh generation. Otherwise you put a lot of time in before the “stress it” bit.

5. Dimensional reduction and feature removal of 3D models is hard and expensive, and probably shows your design process is not very sensible. Instant detail not only costs, but it almost always kills analysis projects before they get going.

6. It is false economy not to insist on proper documentation of an analysis. This applies to documenting programs as well.

7. Using different people for meshing and analysis is asking for trouble. When driving anywhere, keep steering and changing gears in the same department and don’t get your spouse to change gears and the kids to brake. This sounds stupid, but isn’t any more stupid than splitting meshing, solution, and post processing. The reason is that analysis and post-processing often mean feedback to a previous stage to do the job properly.

8. Correlation with physical tests is very useful, if not imperative. Remember that test measurements are approximate too.

9. Sadly, in some people’s experience,  the higher up an organization you go, the more they get into a “simulation means we don’t have to test” mindset. It can mean less testing, however.

10. Analysis is not carried out for the sake of analysis. It can be required to assess and substantiate a design to demonstrate that it meets its functional and safety requirements. Also, an individual analysis can be part of a design optimization task or a robustness assessment.

FEA Outside the Design Process
11. FEA can also be useful in post-mortems/failure investigations. In such cases, data on the root cause may be in short supply, emphasizing caution is needed and collaboration with other parties.

12. What is designed is not what is made, because of material variability, dimensional tolerances, surface finish even, etc.

13. The solution is approximate.

14. Ten element models can provide more design information than 2 million tetrahedra. ‘The object of computing is insight.’  Big tet models may have their place though ... if they cost little to create and analyse, or you can’t get the design information any other way.

Software Programs
15. Graphical displays can be deceptive,  e.g. magnified displacements can mislead when looking at interferences, gaps,  and contacts.

16. Post processing often gives pictures of response smoothed over the mesh; this gives prettier pictures, but unaveraged stresses (or whatever) are more informative.

17. Licences can be expensive ... or too cheap. Meaning cheap and nasty, or cheap and bug-ridden, or cheap and undocumented, or cheap and unsupported, or cheap and people don’t take it seriously, leading to the CAD add on “stress checker =  spell checker” view.

18. Recognize that FEA can cost. Executing programs sometimes needs machine grunt and space. Making do with a kit that is not up to the job is another WOMBAT (waste of money, brains and time).

People Make the Decisions
19. People need education in the technology and maybe training in the use of individual programs. You have to invest in people and it takes time. Training bolted-on to a sales package is rarely enough.

20. Your competition has access to similar tools. It’s how you use them that matters, which really means that the people matter more than the program.

21. If you have a decent education and can use one of the “traditional” codes, you don’t really need expensive training in how to read a user’s guide for the traditional other programs. This doesn’t mean that vendor training is not useful, just be careful where you spend this year’s training budget.

22. Managers and analysts should understand the need for verification and validation.

23. Encourage analysts to work closely with those from other disciplines, such as materials, plant engineering, non-destructive testing, and the customer, even, since this will minimize the risk of missing something important.

24. Your people need to know and work within their limits and get advice if going outside—what Vince Adams calls the “personal problem solving environment”—and learn to widen it.

25. Encourage analysts to go to user group meetings. Personal contact with other users can be useful. Some say that going to user group meetings is essential. See also “personal problem solving environment” above.

References
For more information on FEA, check out the following sources of information:

• Adams V, “How to Manage Finite Element Analysis in the Design Process,” Glasgow; NAFEMS 2006.
• Hamming R, “Numerical methods for Scientists and Engineers,” New York, NY; McGraw Hill 1973.
• Pashley D G, “F.E. Software testing,” Benchmark Magazine, NAFEMS, April 2009.
• Thacker B H, “Why Do – Probabilistic Finite Element Analysis,” Glasgow, NAFEMS, 2008.
• Performance Test Code Committee 60, “Verification and Validation in Computational Solid Mechanics,” ASME V&V 10-2006, www.asme.org.
• Marks L, “Tips and Work Around for CAD generated models,” Glasgow, NAFEMS, Revised and Republished — August 2008.
 

Derek Pashley is a member of NAFEMS Education and Training Working Group (ETWG). Now semi-retired,  he spent about 30 years doing methods development for Rolls-Royce in Derby, UK. This article was produced with help from Laurence Marks, in particular, and the NAFEMS ETWG, specifically Adib Becker, Trevor Hellen, Nawal Prinja. Andy Morris, and Mark Chillery. For more information, visit nafems.org.