FEA for Managers and Reviewers

Editor's Note: Tony Abbey, in conjunction with NAFEMS and Desktop Engineering, will discuss this article's points in a free, Q&A-style webinar on March 7. For more information and to register, visit nafems.org/asktony.

Finite element analysis (FEA) tools are now widely available and relatively cheap. This means an increasing need for analysis resource across the industry, as well as a growth in consultancy firms.

Overall view of a road tanker used in an FEA analysis.

The cost of investing in people increases, and "career" analyst numbers are falling. The result is a shortage of engineers familiar with FEA in industry, and increased outsourcing. There are fewer staff to manage effective initial task assessment and resource allocation, or to carry out the analysis review.

The whole question of process management and quality assurance (QA) with FEA is a big topic, so in this article we'll focus on two themes: startup and review.

• Managers: Let's discuss the need to buy time up front to focus on the key questions, so that the team can start work effectively. We need to know the scope, objectives and the deliverables.
• Reviewers: How do you sign off an analysis report? You will need evidence of good basic checking, demonstration of good practice, and confidence in the analysis and its results.

Planning the Project

We need to understand the stages involved in an analysis project. A common assumption is that analysis starts with the meshing, with the analyst quickly jumping to the computer. It is an overwhelming temptation--comforting for managers to see engineers busy, and engineers to be seen as being busy! But we need to avoid this, and buy time to plan properly.

Internal details of a road tanker.

The first stage is the problem definition. We scope the physical problem and the client's expectations, to decide on the simulation approach we take. All these are the high-level decisions.

On the NAFEMS Introductory FEA courses, we build a process sheet interactively. Over the years, many useful ideas have evolved, and some are presented below.

Preparations and Actions before an Analysis

1. Define your objective. Determine whether this is forensic analysis, a fresh design or a redesign.

• If it's a new product, with no previous analysis or test history to compare against, we have to assess assumptions and methodology carefully. We may liaise with design and manufacture, and stage through preliminary and final design.
• Analysis of a failed component requires as much data as possible on the failure. A surprising amount of physical data and anecdotal evidence is lost that could have underpinned analysis assumptions and conclusions.
• If we're certifying a product, we need to know the standard and where to source it.
• If we're determining what safety level factors are required, keep in mind that man-rated or mission-critical will need higher safety factors for design and more rigorous analysis.
• If the analysis is to support a scrap or re-use decision, we need to understand the cost implications.

2. Get familiar with the structure to be analyzed and its purpose. We need to look at the background of the structure, to understand the failure mode, in-service conditions and associated tests.

3. Consider the scope of the analysis. We should understand loading applied to a structure and internal load. This takes skill to establish free-body diagrams, etc., and use initial hand calculations to check feasibility. If the team doesn't have these skills, its a good idea to plan to develop them. This is vital: We can't treat the structure and its analysis as a black box solution in FEA. A reviewer looks to see whether you understand the structural behavior, in the report and in any presentation.

4. Consider how to represent real-world loading within available analysis simulation tools. Avoid point loading inputs; they don't exist in the real world and will cause analysis problems. Pressure on available geometry faces may be too approximate. Augment the geometry to map the real footprint.

5. Consider the constraints. Simulation includes fully built-in and simply supported methods. In reality, neither exists--so we introduce boundary conditions in other ways. Testing and documenting of assumptions should be clear in the report and to the reviewer.

6. Source and check geometry data. CAD data source and format should be defined. Product lifecycle management (PLM) may handle this, or we may need to get coherent data from the client. Keep in mind that we need time to assess the stability, applicability and accuracy of data. This is a key step for which we should be prepared.

7. Source material data and design standards. We need to make sure we source early with authoritative values. If we standardize on data sources so they are readily available on-site via PLM or other systems, then so much the better. If we're involved in a design or redesign, we need to have a good understanding of acceptable materials, section types, gauges, approved welds, bolts, etc.

8. Define the resources available for the analysis. This includes available manpower, associated skills and range of experience. It includes resources we can tap into for advice and guidance--within the company, trade organization or software hotline. Available computing resource is important. You may be competing, so check with other departments. This includes computing power, storage, etc. Tuning analyses against computer resources, to give good predictions on feasible size and scope of FEA models, is essential.

9. Know to what you are entitled. What is your available software, including appropriate modules and licenses? Calling a software vendor last minute is not going to enable much discount. Budget, time scale, and priority are huge factors. Sadly, this gets overlooked on most courses.

Modeling Methods

There are many modeling method choices, including analysis type, linear, nonlinear, dynamics, fatigue, etc. An assessment of the physics involved in the real structure and how we simulate it is required. The reasoning must be reflected in the report, and clearly understood by a reviewer. This builds confidence--and any false steps or revisions can be more easily and constructively addressed.

Overall internal stresses in tanks and frames.

Different idealization levels have been covered in previous articles, including 1D, 2D or 3D simulation and choosing mesh refinement. In summary, though, we want sufficient elements to represent the structure well. Too many elements imply performance and resource issues. Again, assumptions and validation model details should be in the report.

Defining the Deliverables

This could be a detailed report that needs an overview for reviewers to quickly grasp what we have done and how.

When reviewing, I recommend requesting a copy of the analysis files to check the validity of the method and results. I have occasionally been surprised when certification bodies have resisted this idea, as they cannot rerun the analysis. There are two points: the original model creator doesn't know that, and the analysis run can be subcontracted out if required.

Another argument is that the model is intellectual property of the originator. The contract should indicate that independent check runs are valid and legal QA.

I have supplied analyses to major aerospace companies who demand copies, and it really sharpened my game. I have seen reports that make me question what model could produce them. It is something for both sides of the process to think about.

The Single Model Syndrome

Things to Avoid with FEA What follows is a short list of things that should not get through to review stage: Stress averaging switched on in plots. They may hide real peaks, poor mesh and be un-conservative. von Mises stresses only in global views. We want to know what is happening throughout the structure, and at key points what the stress state is (tension, compression, shear, bending, axial, etc.). This takes more than a single plot. No overall load balance summary--what went in, what came out. No summary of checks carried out on element quality, numerical solution accuracy, etc. No detailed breakdown of components, materials or properties with clear diagrammatic roadmaps. No detailed set of mesh plots. No clear definition of assumptions and modeling techniques. No clear statement of analysis objectives and whether they were met. --T. Abbey

Several models can be used to support different aspects of the project, such as an assembly global model, and local models of important details with finer mesh or plane strain 2D simplification. Many analysts build a single model, but we don't need to be thus constrained.

I like having an "under-the-table" model. In my early days, project budgets only allowed a single model. This was an all-embracing model, which occasionally wasn't ready for the design review. Sitting in a design review without results can be career limiting.

A simpler model was often developed in parallel, representing the basic structural behavior. It was a lifesaver to present the results from this.

Report Format

Let's review the format and content of the report, from the manager and reviewer perspective. Your FEA program may produce an automatic report, which is a starting point.

• Consider the audience. Whether you go with an informal or formal report depends on the recipient. Is it your peers, the management, the prime contractor, the certification authority? The level of detail and the structure reflect the audience and intent. A detailed report for formal review should include extensive results, tables, assumptions, etc. To avoid overwhelming the reviewer, provide an executive summary with conclusions and key results.
• Show, don't tell. Don't write a report like a magic show, with the climax in the last act. Do the opposite: Show the rabbit in the executive summary, and then explain it. Put the detail and the majority of the results into Appendices.
• Support your work. There must be clear supporting evidence for the analysis methods and the conclusions. Hopefully you will be confident about the analysis, and want to convince the reviewer. A prior internal peer review is useful--and not just by experts. If a manager knows the basic ideas of good and bad practice, he or she can assess the validity of, and confidence in, the work.
• Build the report as you go. If you don't record details, you may forget. Meld them into the final report. The worst-case scenario is leaving "dummy" material or other data in an analysis. If not updated until report time, results change and a rewrite is needed.

Whether your role is manager, reviewer or analyst, there is a lot to consider in an FEA project. We want to be able to use this powerful technique safely and effectively. I hope this very brief overview has given you some food for thought. For more, attend my March 7 webinar on this subject by registering at nafems.org/asktony.

Tony Abbey is a consultant analyst with his own company, FETraining. He also works as training manager for NAFEMS, responsible for developing and implementing training classes, including a wide range of e-learning classes. Send e-mail about this article to [email protected].

MORE INFO

FETraining

NAFEMS