Desktop Engineering Blog

Random Vibration Fatigue

Posted by Andy Woodward on 05-May-2017 14:09:58
Find me on:

In a previous article I discussed using random analysis to predict failure of components in a vibration environment.  Random analysis is a quick way of ensuring that statistically the maximum stress due to a vibration loading will not exceed a set level, but the most common mode of failure in such an environment is not due to one single load spike but due to the summation of damage from all the load cycles – known as fatigue failure.

Classically fatigue failure due to a transient load was performed quasi-statically.  A known load history was combined with stresses from a unit load in the FEA model to create a stress time history.  Rainflow cycle counting was used to evaluate the stress cycles and then damage calculated from these using classical theories like Goodman and summed using Miner’s rule.  There were problems with this method though.

Firstly, using static stress results means you are ignoring potential dynamic excitement from loading.  A quick test of whether this is important for your design is to compare the resonant frequencies of your model with the frequency content of your loading.  Run a normal modes analysis on your FEA model and pass your load history through a Fourier transform to convert it to the frequency domain. 

If the upper frequency range in the loading reaches 1/3rd of the lowest natural frequency of your model then there is potential for excitation and hence a static analysis is non-conservative.  For example, if your model has a first mode frequency of 100Hz and your loading frequency is between 2-35Hz then there is a potential to excite that first mode, amplifying the stresses.

Secondly, for a random signal it may be necessary to use a huge time history.  I know of an Auto OEM who perform their body durability analysis in the time domain and they have to use a large number of parallel threads in order to process the data in anything approaching a time frame useful to the design process.

So what can we do? 

Using the Power Spectral Density (PSD) that you would for a simple Random Response Analysis is a solution.  As with that technique we run a frequency response analysis on our structure.  If our PSD is measured in g2.Hz-1 then we apply a 1g acceleration across the frequency range, if it is in N.Hz-1 we apply 1N.  The output stress results give us a transfer function of stress for every element in the model. This result can be combined with the PSD to ultimately predict a damage accumulation rate the inverse of which is predicted life of the component.

Random fatigue graph image for fatigue assessments - FEA

The big advantage of this approach is that the duration of the simulation is effectively independent of the length of the original time signal meaning that fatigue assessments can be performed on time signals representing many weeks and months of testing in a very quick time frame. It also provides more insight into your problems, for instance giving plots of damage distribution – helping you to identify at what frequency the most damage occurs meaning you can tune your parts to eliminate or move these resonances.

This approach has been around for a while now and required a separate post-processing operation involving moving the sometimes very large FEA result file from a server to a workstation (235GB is the largest I’ve seen for a 6M DOF car body with 24 inputs) in order to use the GUI to run the fatigue calculation.  The second generation of this technique, developed by CAEFatigue Ltd, allows you to batch process for these results in situ using a simple ascii input file format from the command line, or in the case of Nastran, fully embedded within the code meaning you need only request the fatigue results and not the huge complex stress output of the transfer function.  CAEFatigue also supports more complex loading environments required by mainly defence companies such as Sine-on-Random, Narrow-Band and discrete events all superimposed on the Random loading.  CAEFatigue works with FEA results from Abaqus, Ansys, Nastran (MSC or NX) and Optistruct.

And the runtime for that 235GB result file? A fraction over 4 minutes on fairly mediocre hardware.

If you’d like more information on this technique, on CAEFatigue or Nastran Embedded Vibration Fatigue please contact me for an informal discussion.

Andy WoodwardCAE Consultant


Want to know more? Request a call back >>


Topics: Various - MSC, FEA, Analysis