Technical insights.

Duration of a PSD: What does that mean?


Recently, we posted a blog about calculating fatigue damage in the Frequency Domain and how the process was not dissimilar to fatigue damage calculations in the Time Domain. That blog 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 of the time signal and also provides the statistical properties of the time signal, presuming the time signal is (1) Stationary, (2) Random, and (3) Gaussian.

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 blog. 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.

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 T 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).

CONCLUSIONS:

To be clear, a power spectral density (PSD) itself does not have a time duration. However, the damage calculated from the PSD assumes a damage resulting from 1 second but this must be changed if the PSD is converted from a known time signal with a known duration.

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 Event of 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.

*CAEfatigue Limited (www.caefatigue.com) is a privately owned company with it’s world headquarters located in London, England.   CAEfatigue Limited is dedicate to developing random response and fatigue evaluation software for dynamic mechanical systems that is easy to use for the average Engineer or Designer.   The CAEfatigue Limited suite of products are in use across multiple industries throughout the world and have become the industry standard for use in the frequency domain. Share with:

0

Frequency Domain Fatigue Damage Calculation Process: Is it really that different?


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 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 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].

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:

  • Properly convert the Time Signals to PSDs by conditioning the time signals first,
    prior to the conversion.
  • 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!”.

 

*CAEfatigue Limited (www.caefatigue.com) is a privately owned company with it’s world headquarters located in London, England.  CAEfatigue Limited is dedicate to developing random response and fatigue evaluation software for dynamic mechanical systems that is easy to use for the average Engineer or Designer.  The CAEfatigue Limited suite of products are in use across multiple industries throughout the world and have become the industry standard for use in the frequency domain.

Share with:

0

SINE SWEEP on RANDOM PSD: The need for frequency matching between the Solver FRF and the Sine Sweep


Similar to the previous blog post where we talked about frequency matching between the Solver FRF and the Input PSD loading, there is also a need to have good frequency matching between the Solver FRF and a sine sweep input loading.  Understanding this will ensure that you calculate accurate responses and, therefore, fatigue damage in the Frequency Domain using CAEfatigue VIBRATION (CFV).

Input PSD, Transfer Function and Response PSD:

In order to calculate fatigue damage and fatigue life in the frequency domain, we first need to generate the RESPONSE PSD that is the result of multiplying the TRANSFER FUNCTION by the INPUT PSD. The Transfer Function is calculated within CFV using the solver FRF stress data, and the Input PSD is defined directly within CFV. Below is an example of the three PSDs as shown by the PSD Plotter in the CFV GUI (CFG).

However, we now want to apply a deterministic sine sweep to the analysis that will be included along with the random input PSD; many refer to this as “sine on random” input loading.  Within CFV, this can be easily accomplished, BUT, as you will see in this post, we must be very careful to ensure the resolution of the sine sweep is sufficient to pick up the peaks in the Transfer Function. Otherwise, the sine sweep may miss the resonant frequencies and, therefore, not provide an accurate response PSD. This is no different than ensuring a good resolution / frequency match between the random input PSD and Transfer Function as discuss in our previous post.

Frequency Resolution and Resonance Detection of the Sine Sweep

What is a Sine Sweep?

Just to be very clear, a sine sweep applies a single sine wave to a structure and after the responses are calculated, the next sine wave is applied to the structure; i.e. one after the other. This continues until all sine waves in the sweep have been applied and the responses from all sine waves have been added together.  If a random PSD is also required, it is applied every time the single sine wave is applied, i.e. at the same time as the sine wave.  Below is an example of a 9 Hz sine wave and a random PSD, which are applied together as a single EVENT in a SINE on RANDOM analysis within CFV. Note: CFV can also apply many sine waves at the same time (harmonic loading), if desired, but this would not be considered a sine sweep.

Example of SINE on RANDOM Analysis

Let’s assume that the solver FRF analysis has been correctly executed and it captures the peak FRF responses that are in the structure.  This would also ensure the Transfer Functions (created within CFV) are accurate and contains all the response frequencies of interest to our analysis. Consider the Transfer Function in the plot to the right. There is one significant peak in the Transfer Function where the worst case stress is occurring.  This peak is at 8.8 Hz.  We can use this information to define our sine sweep.

Within CFV, a sine wave sweep can be defined as a series of single sine waves using a SINGSINE entry, a DETLOAD entry or a SINESW entry.  For this example, we will define a series of single sine waves using SINGSINE applied with a random, single input PSD loading (shown as the input PSD in the plot above). This is a SINE on RANDOM example. Note: CFV will also allow the application of a sine sweep without the random PSD loading, if desired.

Our first sweep is a series of single sine waves between 2 Hz and 32 Hz with an amplitude of 1 G and a spacing of 2 Hz.  This sweep is rather course in spacing and misses the peak response at 8.8 Hz. Selecting the “worst case” element, we can see from the Event plot, that the worst damage occurs at Event 108, which corresponds to an 8 Hz sine wave with a random PSD loading. The fatigue damage at this element for this frequency is 0.09.  Total fatigue damage predicted from the application of all sine waves and random PSDs at this element is 0.12, where 1.0 would be a fail.  A User may mistakenly feel very comfortable with these results and assume the structure will not fail but the analysis had a course spacing in the sine sweep and the peak resonance was missed.

Our second sweep is a series of single sine waves between 2 Hz and 32 Hz with an amplitude of 1 G and a spacing of 1 Hz.  In this sweep we have improved the frequency spacing but still fail to include the resonant frequency of 8.8 Hz Selecting the same “worst case” element, we can see from the Event plot, that the worst damage occurs at Event 1090, which corresponds to 9 Hz.  The fatigue damage at this element, for this frequency alone is 0.45.  Total fatigue damage predicted from the application of all sine waves and random PSDs at this element is 0.69, where 1.0 would be a fail.  A User may feel comfortable that this structure will pass because the damage is under 1.00 but what happens if we actually apply a sine wave at 8.8 Hz, which is the peak response frequency.

Our third, and final sweep is a series of single sine waves between 2 Hz and 32 Hz with an amplitude of 1 G and a spacing of 1 Hz (same as above).  However, we will replace the 9 Hz sine wave with an 8.8 Hz sine wave to match the peak response frequency seen in the Transfer Function. Selecting the same “worst case” element, we can see from the Event plot, that the worst damage occurs at event 1088, which corresponds to 8.8 Hz. The fatigue damage at this element for this frequency alone is 0.80.  Total fatigue damage predicted from the application of all sine waves and the random PSD at this element is 1.04, where 1.0 would be a fail. This is significantly different from the first sweep that only predicted a total damage of 0.12 (due to a course sine wave spacing in the sweep) or the second sweep that predicted a total damage of 0.69 (but missed the resonant frequency in the sweep).

CONCLUSIONS

Under loading from a random PSD and a properly defined sine sweep (including the resonant frequency) the structure may fail from fatigue because the damage value is just above 1.00.  This possibility of failure was missed when the sweep was inappropriately spaced or did not include the resonant frequency and the User could have thought, based on incomplete data, that the structure was acceptable.

Therefore, it is imperative to understand the resonant frequencies within your model, especially within the expected operational frequency range, and to include those frequencies within the sine sweep to get the best response prediction from your analysis.

 

*CAEfatigue Limited (www.caefatigue.com) is a privately owned company with it’s world headquarters located in London, England.   CAEfatigue Limited is dedicate to developing random response and fatigue evaluation software for dynamic mechanical systems that is easy to use for the average Engineer or Designer.   The CAEfatigue Limited suite of products are in use across multiple industries throughout the world and have become the industry standard for use in the frequency domain.

Share with:

0

Frequency Domain Fatigue Analysis: The need for good resonance determination and frequency matching between the Solver FRF Analysis and the Input PSD


The following will explain the need for good frequency definition in both the Solver FRF analysis and the Input PSD so proper resonances are found for the Transfer Function and the frequency content is matched between the FRF analysis and the Input PSD.  Understanding these concepts will ensure that the intended conditions are defined to calculate accurate fatigue damage in the Frequency Domain using CAEfatigue VIBRATION (CFV).

Let’s use the example below:

In order to calculate fatigue damage and fatigue life in the frequency domain, we first need to generate the RESPONSE PSD that is the result of multiplying the TRANSFER FUNCTION by the INPUT PSD. The Transfer Function is calculated within CFV using the solver FRF stress data, and the Input PSD is defined directly within CFV. Below is an example of the three PSDs as shown by the PSD Plotter in the CFV GUI (CFG).

As can be seen in the plot, the shape and frequency content of the Response PSD is heavily dependent on the shape and frequency content of the Transfer Function.  If care is not taken in the Solver FRF calculation, it would be very possible to miss, for example, the peak amplitude (resonance) at 14 Hz in the Transfer Function and thus, it would completely change the shape and content of the Response PSD.  We will look at this more closely below.

Frequency Resolution for Resonance Detection

To the left are two Transfer Functions that were generated within CFV from two different Solver FRF analyses.  In one case, the peak amplitudes (resonances) near 40-45 Hz are recognized and accounted for by the User (blue, solid line) whereas, in the second case, the User failed to recognize the peak contribution and bypassed the 40-45 Hz frequency in the FRF analysis settings (orange, dashed line).

If we now use these Transfer Functions with a simple Input PSD, we can see the influence this mistake has on the shape and frequency content of the Response PSDs (see image to the right).

It is clear to see that the Response PSDs have different shapes and peak values.  Using the correct Transfer Function (blue, solid line), the frequency resolution in the FRF analysis has picked up the response peaks at 40-45 Hz and the correct amplitude values are passed through to the Response PSD.

However, in the second case (orange, dashed line), the Response PSD falsely shows that the max peak response is at 25 Hz and completely misses the significant resonances at 40-45 Hz.

This mistake by the User, will likely cause a significant difference in the fatigue damage and life calculations because the cumulative areas under both curves are very different, which significantly changes the Mvalue used by the Dirlik method (most common damage calculation method used in frequency domain fatigue calculations). Most solvers have parameters (like FREQ4 in Nastran), which guide the User in choosing correct frequency points around such resonances.

Frequency Matching

A keen observer may also have notice something else that is incorrect in our example above. Although the blue, solid line Transfer Function does accurately reflect the response of the model, the User failed to recognize that the points in the Transfer Function do not match up well with the points in the Input PSD, especially around 5 Hz, i.e. there is no Transfer Function frequency point at 5 Hz; nearest points are at 0.5 Hz and 25 Hz.

Within CFV, the Response PSD is generated by multiplying the value of the Transfer Function PSD point by the corresponding value of the Input PSD point.  When a Transfer Function point does not align with an Input PSD point, the nearest points are interpolated to generate a new value at the frequency from the Transfer Function (creates green dot on Input PSD).

However, the reverse does not happen; i.e. if a point on the Input PSD does not line up with a point on the Transfer Function, that Input PSD point is ignored in the Response PSD calculation (red arrow, empty red circle on Response PSD).

CFV does not change the Solver FRF stress results to add in or take away points to account for the Input PSD frequencies.  This could, in theory, be attempted for single input (real) PSD’s with corresponding real transfer functions but there would be difficult theoretical issues to resolve. However, it cannot be done for multi-input PSDs because of the difficulty to interpolate across complex cross PSD’s and the corresponding complex transfer functions. Hence, CFV requires the User to ensure the frequency resolution is sufficient in the FRF to match the Input PSD.

In this example, the Transfer Function does not have a defined point at 5 Hz so the contribution of the Input PSD at 5 Hz is ignored. Hence, this frequency mismatch produces an incorrect Response PSD at 5 Hz. Effectively, the Input PSD is changed based on the Transfer Function frequency points to create a modified Input PSD where the red dots line up with the Transfer Function points and the blue dots are ignored.

Therefore, to ensure the fatigue damage and life calculations are accurate, the User must consider frequency resolution (to detect resonances) and frequency match between the Solver FRF analysis and the Input PSD definition.  Below are the correct Input PSD, Transfer Function and Response PSD for this example, which reflect appropriate frequency content and matching.

Good frequency content and matching can be accomplished by a careful understanding of the expected resonances in the model and the expected input loading that will be applied as part of the fatigue analysis.  Once understood, an appropriate choice of solver parameters (such as “FREQ1” and “FREQ4” entries for Nastran) can be made to ensure the desired frequency resolution to pick up resonances and where the loading changes significantly in the Input PSD, i.e. for typical road load data, the Input PSD will likely require good Solver FRF frequency resolution in the 1.0 Hz to 10.0 Hz range.

This post is intended to provide an understanding of how frequency domain fatigue analysis is conducted in CFV.  Remember, providing accurate data in will ensure accurate results out.

 

*CAEfatigue Limited (www.caefatigue.com) is a privately owned company with it’s world headquarters located in London, England.   CAEfatigue Limited is dedicate to developing random response and fatigue evaluation software for dynamic mechanical systems that is easy to use for the average Engineer or Designer.   The CAEfatigue Limited suite of products are in use across multiple industries throughout the world and have become the industry standard for use in the frequency domain. Share with:

0

Why use the Frequency Domain?


We are often asked why should I use the frequency domain when doing fatigue analysis. Please let us give you a quick overview of why.

Below is a hypothetical example of damage calculations done using RLD (road load data) from automotive testing at a proving ground.  This comparison also applies to any process that uses time domain data as the input loading to their components. For those not familiar with proving ground automotive vehicle testing, the workflow is fairly straight forward. A vehicle is instrumented with accelerometers at various locations on the vehicle.  Most often each accelerometer is measuring data in the X, Y and Z direction.  So, if we have accelerometers at 4 locations on the vehicle, which are measuring accelerations in 3 directions, than we have 12 channels (RLD time histories) of information being collected at the same time as we drive the vehicle over a planned route for some period of time.  All of the channel information is combined into a single proving ground EVENT and in many cases, automotive testing collects data from multiple events throughout the proving ground with different loading conditions at different speeds.

To calculate damage using the TIME DOMAIN, we need to apply the collected road load data to an FEA model within a stress solver for EVERY event and then sum up the damages from the multiple events to calculate the total damage to the vehicle.  This is extremely time consuming and requires a significant amount of solver effort.

To calculate damage using the FREQUENCY DOMAIN, we need to run a SINGLE stress analysis and use those results as a multiplier between the collected road load data and the output response of damage. However, we need one additional step, which is to convert the road load data time histories into frequency based power spectral densities (PSD’s).  We do this within CAEfatigue VIBRATION (CFV) using a manual conversion tool called TIME2PSD or we can also use our automated conversion tool called CAEfatigue CONDITIONING (CFC).

The image above graphically represents the differences between a Time Domain and a Frequency Domain fatigue analysis using Nastran as the stress solver.  As mentioned, the key difference is the number of Nastran SOL112 runs required in the Time Domain when the testing duty cycle contains numerous proving ground events.

This is not the case with the Frequency Domain where only one SOL111 run is required.  This difference can result in significant time savings with the added benefit of better output parameters captured by the frequency domain approach.

CAEfatigue Limited have work with numerous companies to benchmark the frequency domain process against the time domain process for models directly relevant to their needs.  On all occasions, we have been able to prove the correlation between the two processes and show why it makes sense to switch.

*CAEfatigue Limited (www.caefatigue.com) is a privately owned company with it’s world headquarters located in London, England.   CAEfatigue Limited is dedicate to developing random response and fatigue evaluation software for dynamic mechanical systems that is easy to use for the average Engineer or Designer.   The CAEfatigue Limited suite of products are in use across multiple industries throughout the world and have become the industry standard for use in the frequency domain. Share with:

0