Simulation and Analysis: When Button Clicking Ends in Tears

Oversimplification of analysis decisions can lead us astray in finite element analysis. Sometimes the user interface fails to impart the correct level of importance to the options we select. Below are where menu “quick choices” can lead to trouble.

Fatigue

Setting up data for fatigue analysis can be quite complicated, with many steps along the way. (See “Conduct Fatigue Analysis Using FEA,” for an overview of fatigue.)

Several of the questions posed by a user interface may almost seem like a general user survey. These may include the following:

• Is the material high- or low-strength steel?
• What is the surface finish?
• Is the stress state bending, axial or shear?

In fact, the answers to these questions directly influence the final fatigue life calculation. Initial fatigue life data, described on an S-N or e-N curve, will probably relate to smooth polished axial test specimens as a datum point. To develop a similitude between this “perfect” fatigue life and the actual component you are dealing with, correction factors are applied. For example, the first two are interlinked and a typical fatigue life correction factor could be as low as 0.1 for an untreated forged high tensile steel. This has a big effect on the resultant fatigue life. If we compound a full set of factors, we can easily have fatigue life reduced by three or more. Knowledge of the reason behind each question is vital: The tendency to treat the questions as part of a general survey should be avoided.

It is critical that the software tool is designed to emhasize the importance of these questions. For example, failing to apply a “typical” correction factor should prompt a warning that this is unusual. A list of typical values with background information should be easily accessible to the user. “Typical” values should also have a caveat. However, it is better to work with generic values rather than no correction terms, which will give hopelessly optimistic fatigue lives.

Frequency Response Analysis

Data setup for dynamic analysis can be tricky because it needs some very careful tuning to yield the best results. One good example of this is in frequency response analysis. A previous article (“Practical Frequency Response Analysis”) gave an overview of this type of solution.

What’s important in this type of analysis is to define exactly where we want the frequency response calculation points to be made across the frequency range. In essence, this means we need to know the natural frequencies of our system and the frequency range of interest. There should be user controls to define both the spread of calculation points around each natural frequency and between adjacent natural frequencies. In addition, the lead into the first natural frequency needs to be carefully defined. Usually there are quite a few ways to achieve this that are already built into the FEA Solver. However, it is difficult to design a user interface that easily explains to the user what the usage and implications of each are. Sometimes there may be no route between resonant frequencies and frequency response analysis, as in the case of a direct solution method. It is always unclear to me what an inexperienced user is supposed to do in a case like that.

It is very easy to miss any, or all, of the peak responses without taking some care. The implications of missing a peak response can result in underpredicting any type of response by up to 30% to 40%. It really becomes a bit of a lottery how non-conservative the answer will be. If you are doing a random response analysis on the back of the frequency response analysis, the shape of the overall response curve is important. In this case the RMS responses could be either conservative or non-conservative; a more sophisticated lottery!

Again, in this case it is incumbent upon the software designer to provide clear generic guidelines that will tend to give conservative results. If the user does not provide a table of natural frequencies, or the preprocessor is unable to extract them from previous normal modes analysis, there should be a huge caveat.

Nonlinear Analysis

In nonlinear analysis, we may want to apply a load that tracks the deformation (that is, changing configuration) of the component under the loading. This is known as a follower force and was described in “Moving into the Nonlinear World with FEA.”

In some user interfaces, this can be a three-step process to set up. The user obviously must request a nonlinear analysis, usually with a further option to select geometric nonlinear analysis specifically. Usually, the option to calculate follower forces is an additional selection.

That would seem to be all, but in fact there is another wrinkle. If a distributed force has been applied, via geometry or mesh, this can be interpreted by the solver as a vector, and be updated as the mesh distorts. However, if a nodal force is applied, there is usually no way this is captured as a vector, and therefore any mesh configuration change will be ignored. This all represents a tricky setup, and the user interface should be guiding the user. Caveats must be provided to keep the user out of trouble.

Be Sensitive to Simplicity

I have stressed the importance of the software developer’s role in providing guidance and caveats. However, in the final analysis (to use a dreadful pun) it is up to us to make sure the analysis works. If you’re not sure of the implications of any of the options you are selecting, it is a good idea to run sensitivity analyses to see what happens in extreme cases. I am often faced with this when doing fatigue analysis: I never know which of the mean-stress correction methods is really most appropriate, so I end up running all of them—and I choose the most conservative.

So, be cautious, be safe—and check out those buttons!

Editor’s Note: Tony Abbey teaches live NAFEMS FEA classes in the U.S., Europe and Asia. He also teaches NAFEMS e-learning classes globally. Contact [email protected] for details.