Duration of a PSD: What Does That Mean?

Share This

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

Recently, we posted an article about calculating fatigue damage in the Frequency Domain and how the process was not dissimilar to fatigue damage calculations in the Time Domain. That article raised the same question by users several times: What time duration does a PSD have?

This is an interesting question.

For those who work in the Time Domain, the concept of a “time duration” is simple. The time signal is captured for a specific period of time and that is, by definition, the “time duration” of the signal.

However, in the Frequency Domain, a PSD has no time duration. A PSD is simply a snapshot of the frequency content and magnitude within a time signal and it also provides statistical properties of the time signal, presuming the time signal is (1) Stationary, (2) Random, and (3) Gaussian.

Key assumptions

Single Input PSD

To calculate the damage from a single input PSD, we use the “rainflow” cycle count formula for n(S) to generate a histogram of stress ranges. This was explained in the previous article. This calculation is done at every element/node location throughout the model using the appropriate Response PSDs, with or without deterministic loading and are summed together to generate a histogram of stress ranges.

n(S) =  E[P] * T * p(S)

Where:

n(S) is the TOTAL number of rainflow cycles 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].

For a single input PSD, CFV assumes that the duration of the Event (T) is 1 second. Hence, the PSD stress histogram is created, and the damage calculated for a time duration of 1 second. The PSD itself does not have a time duration.

Multi Input PSD

To calculate the damage from multiple input PSDs, we use the same “rainflow” cycle count formula for n(S) to generate the histogram of stress ranges for each PSD. Once again, the default is 1 second for each histogram and hence damage is also calculated for 1 second.

However, there is a difference when we use PSDs converted from known time histories, which is often done in the automotive industry.  In these cases, the converted PSD actually represent a converted time history, which has a time duration.

As shown below, the actual raw time signals in section (1) from the upper plot, were conditioned first as shown in the middle plot, prior to their conversion to PSDs, as shown in the lower plot. The CONDITIONED time signals in the middle plot have a time duration of 11 seconds. Hence, the PSDs in the lower plot should be applied in the fatigue damage calculation for 11 seconds to match the application time period of the conditioned time signals. This would mean that in the n(S) formula should be set to 11 seconds. The PSD itself does not have a time duration but the damage calculated from the PSD will assume a event duration of 11 (not 1 second).

Raw time signals

Conclusions

To be clear, a power spectral density (PSD) itself does not have a time duration. The rainflow counting formula for n(S) assumes an Event Duration (T) of 1 second. This must be changed to the known duration that is either provided as part of a frequency domain specification or obtained by the duration of the time signal from which the PSD came from.

A PSD only gives you the frequency content and magnitude to be applied as input loading to the structure. This loading, along with the transfer function, will generate a Response PSD that is then used to calculate the fatigue damage/life. The damage calculation assumes a T value equalling 1 second in the rainflow cycle count formula, n(S). Hence, if the specification is to apply the Input PSD for say, 10 hours in the X direction, followed by 20 hours in the Y direction and finally 50 hours in the Z direction, then the math is simply. Apply an Input PSD to the appropriate X direction solver subcase for 10 hours or (10 x 60 x 60) 36,000 seconds; meaning multiply the damage generated for 1 second by 36,000. We would then apply an Input PSD to the Y direction subcase for 20 hours or (20 x 60 x 60) 72,000 seconds, followed by applying an Input PSD to the Z direction subcase for 50 hours or (50 x 60 x 60) 180,000 seconds. The X, Y and Z damage will be added together to give a total damage expected for the structure at each element.

If the PSD is converted from a known time signal, then the PSD gives you the frequency content and magnitude to be applied as input loading to the structure. Plus, you must also use the time duration of the conditioned time history as the T value in the rainflow cycle count formula, n(S).

In most cases, there are several time signals making up an Eventof loading. When converted to the Frequency Domain, the time signals become a PSD matrix (PSDM) of loading comprising direct PSD and cross PSDs. This PSDM will accurately reflect the time signal loadings plus the influence of loading A on location B (i.e. phasing between loads).  The entire PSDM “Event” will be given the duration of the conditioned Event and in many cases, the required loading in the fatigue calculating will be applied not in minutes or hours but in repeats of the PSDM Event duration.

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

Share This
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 Reply

Your email address will not be published. Required fields are marked *