Frequency Domain Fatigue Damage Calculation Process: Is it Really that Different?

This guest contribution on the Altair Blog is written by the CAEfatigue Team, a member of the Altair Partner Alliance.

If you are new to the Frequency Domain, it is understandable that you may think that this “stuff” is way different than the Time Domain.  This is especially true when we ask folks to do material damage calculations in the Frequency Domain.  You may hear that “this is a whole new way of thinking” …  or, is it?

During our onsite and online training sessions, we often see a look of total confusion in the eyes of our students when we start to talk about the Frequency Domain.  Many have some comforting, albeit, vague memories of the Fourier Series from past days at college, but many have been working in the Time Domain for so long that any thoughts about changing to Frequency Domain are very daunting.

However, are we really changing that much … especially when it comes to a fatigue damage calculation?  Below is an image we often use to convince students that there really is not that much difference.

The material fatigue calculation process, in the image below, has 6 steps regardless of if you start with a Time Signal or PSD.  You start with (1) a stress time signal or PSD then (2) you do some sort of cycle counting process to eventually generate (3) the stress range histogram.  From here, (4) you refer to the fatigue material properties, (5) use Miners Rule to generate cycles to failure and (6) present the damage / life results.

If you look at the images below, you will see that steps (3), (4), (5) and (6) are identical whether you are working in the Time Domain or Frequency Domain. So, we really need to only focus on steps (1) and (2).

STEP 1: Conversion of the Time Signal to a PSD

We like to call this “conditioning” of the time signal because you cannot simply convert a time signal to a PSD without properly conditioning (or correcting) the time signal to satisfy the 3 key assumptions that must be meet.

Most often we see issues with STATIONARY: which is the need for the signal to have the same statistical properties regardless of what time slice you look at within the time signal.

Below are multiple time signals belonging to the same Event that are non-stationary.  The time signals have several low intensity sections as well as sections that appear to have different frequency content.  The statistical properties across these time signals are different depending on the time slice you select to analyze.

Since we are interested in the damage that these signals will cause to a structure, we cannot simply convert the signals “as is” because the non-stationary sections will add time to the duration of the loading, which is not appropriate since the time of the loading should only reflect the parts of the signals that do the damage and not the low intensity section that cause little to no damage.

In this case, the Event should be broken into 3 separate (and shorter) Events that only reflect the parts of the time signals that cause significant damage (see below).  The remaining parts of the signals can be ignored as they cause little to no damage.

CAEfatigue Limited provides conversion / conditioning tools called TIME2PSD (manual) and CAEfatigue CONDITIONING – CFC (automatic) that do this work for our Users.  Below is an image of the first “new / shorter” Event 1 from above, that has been conditioned (second plot) and converted into PSDs (third plot).  These properly converted PSDs are then brought into a CAEfatigue VIBRATION (CFV) fatigue analysis.

STEP 2: Cycle Counting the PSDs

We use the term “cycle counting” just to make new students a little more comfortable.  In fact, we really do not cycle count but follow a new process that eventually produces a stress range histogram similar to what is produced when you cycle count a time signal.

The process starts with calculating the “spectral moments”.  These spectral moments are then used in a “fatigue modeler” to generate a probability density function (pdf) that gives us the distribution of the stress cycles across the stress range.  We use this pdf to distribute the total number of cycles calculated from the Response PSD to calculate a histogram of stress cycles.

CFV provides multiple methods to calculate the pdf of stress cycles in the frequency domain.  However, the CFV software currently uses the DIRLIK approach as the default method.  This method works well for all forms of random input (both wide band and narrow band PSDs) and will also work well when random input PSDs are mixed with deterministic loading (i.e. sine on random analysis).

The formula to calculate the histogram of stress ranges, n(S), is given below.  This calculation is done at every element / node location throughout the model using the appropriate Response PSDs (and/or deterministic loading) and summed together to generate the histogram of stress ranges.  This data then allows the calculation of fatigue damage at every element / node location following the remaining steps (4), (5) and (6) as talked about at the beginning of the blog.

Where;

n(S) is the TOTAL number of rainflow cycle or perhaps a better term, stress range cycles for a given stress value.  When plotted for all stress values, this produces a stress range histogram.

E[P] is number of stress cycles per second calculated from the Response PSD.  This is also called the Expected Number of Peaks of the Response PSD.

T is the duration of the Event loading in seconds. By default, CFV uses 1 second.

P(S) is the probability density function (pdf) of stress cycle ranges (peak to peak). By default, CFV uses the Dirlik Method to calculate this function, which tells us how to distribute the stress cycles from E[P].

To calculate E[P] and p(S) we need to first calculate the spectral moments.

f is the frequency of interest

G(f) is the height of the one-sided Response PSD at the frequency of interest

Once we calculate the moments m0, m1, m2 and m4 we can calculate the expected peak rate (i.e. total number of cycles/second) using the formula

and calculate the stress cycle pdf, p(S), using the DIRLIK formula below.

Where the probability density function p(S) is solely a function of moments m0, m1, m2 and m4.

If we (again) use the comforting term “rainflow cycle”, below we see the histogram of rainflow cycles count (ns) versus a stress bin number.  With a little added manipulation, this can be converted to stress range histogram.

We have now taken care of steps (1), (2) and (3), and can manage the rest of the damage calculation in the same manner as we do in the Time Domain.

CONCLUSIONS:

When calculating the fatigue damage / life in the Frequency Domain, we can fall back on many of the things we already know about the process from the Time Domain. Our only challenge is to:

  1. Properly convert the Time Signals to PSDs by conditioning the time signals first, prior to the conversion.
  2. With a properly converted PSD, use Spectral Moments and a Fatigue Modeler (like Dirlik) to calculate the pdf and stress range histogram.

Once these 2 steps are done, we can calculate damage / life in the same manner as we would do in the Time Domain.

So, is there a big difference when calculating material fatigue damage between Time Domain and Frequency Domain?  Depends on who and when you ask the question.  To anyone new to the Frequency Domain, the answer will be a resounding “YES!”, however, if you ask that same person after they have had the appropriate training and some experience, perhaps the answer will be “actually, not so much!”.

Altair Partner Alliance

The Altair Partner Alliance (APA) provides access to a broad spectrum of complementary software products, through the use of HyperWorks Units (HWUs) at no additional cost. Their continuously expanding list of partner software, across a broad range of disciplines, serves the needs of hundreds of companies ranging from automotive, aerospace, and defense to consumer products, biomedical and heavy equipment. The APA curates a diverse collection of blog posts written by its many partners to keep readers informed on a variety of trending engineering topics.
Altair Partner Alliance
Altair Partner Alliance

About Altair Partner Alliance

The Altair Partner Alliance (APA) provides access to a broad spectrum of complementary software products, through the use of HyperWorks Units (HWUs) at no additional cost. Their continuously expanding list of partner software, across a broad range of disciplines, serves the needs of hundreds of companies ranging from automotive, aerospace, and defense to consumer products, biomedical and heavy equipment. The APA curates a diverse collection of blog posts written by its many partners to keep readers informed on a variety of trending engineering topics.

Leave a Comment