About Fatigue Loading

The fatigue loading history specifies all of the loading conditions associated with a durability analysis, including the number of cycles, scaling, and temperature effects.

Fatigue loading is available only when you have the appropriate role.

This page discusses:

Events

The app does not define fatigue loading directly in terms of physical loads. Instead, it defines fatigue loading in either of the following terms:

  • Using a stress history or a stress-strain history induced by physical loads.
  • Applying scaling factors and load signals to the stresses induced by physical loads.
The app captures the stress or stress-strain history using one or more fatigue loading events. The more complex the loading you want to simulate, the more likely you should break the fatigue loading history into multiple events. You can define a fatigue loading event in either of the following ways:
  • Sequence of frames: individual fatigue contributions occur in sequential order.
  • Superposition: some fatigue contributions occur at the same time.

In addition, you can define overlay events on the main events. For example, you can superimpose an engine RPM pressure load cycle on top of the startup/shut down and main drive mode cycles. When you use overlay events, you need to ensure that they use compatible time scales. You do this by specifying the duration of each event or a time history (a sequence of time points) for both the main event and the overlay events. A schematic depiction of one possible set of loading events and duration/time histories follows:

Main event A
    Duration = 90 sec
    Overlay event A-1
        Duration = 3 sec

Main event B
    Time history: historyB.txt
    Overlay event B-1
        Time history: historyB-1.txt
    Overlay event B-2
        Duration = 12 sec

Main event C
    Duration = 200 sec
    Overlay event C-1
        Time history: historyC-1.txt

Driving Field of a Fatigue Event

You can define the driving field for the fatigue on a per-event basis. By default, the driving field is stress only, even for strain-based fatigue algorithms. If the structural step referred to by an event involves a nonlinear analysis, select both the stress and strains to drive the fatigue analysis.

Sequence of Frames

You define a sequence of frames using a set of contributions, occurring one after the other, in which each contribution consists of a reference to a step of a structural analysis case. If the structural step involves time-varying loading, a single contribution includes a sequence of frames of stresses. A frame refers to the distribution of stress or strain over the whole model at a particular point in time (also known as an increment).

You can define multiple contributions to the fatigue event, with each contribution referring to a structural analysis step. The order of contributions is important: the fatigue solver combines all of the frames from all of the steps into a single sequence of frames of stress (or stress-strain pairs). The contributions you include in a sequence of frames event do not have to be the same length, because you include all the contributions serially.

If the driving field is stress only, you can also apply scaling to the individual contributions and to the entire event. If both stress and strain are driving the fatigue, the app assumes nonlinear material behavior is present; therefore, the app prevents scaling.

Superposition

You define superposition in terms of fatigue contributions where each contribution consists of the following:

  • A reference to a step or a load step of a structural analysis case,
  • A load history signal, and
  • An optional scale factor.

Superposition is also referred to as "scale-and-combine" in some fatigue applications, such as fe-safe®. The app assumes the driving field for superposition to be stress. The stress sequence is defined by the linear combination (sum) of each contribution.

The contributions must refer to structural analysis case steps where the behavior is linear.

Because the contributions act in parallel, the load history signals for each contribution should match in length.

Load history signals can be embedded in the contribution or can be stored in shareable PLM objects and referred to by the contribution. In the embedded case, you specify the sequence of values directly. In the shareable PLM object case, a signal file is imported. You can import both single-channel and multichannel signal files. When a signal file contains multiple channels, the app prompts you to select the channel name (if available).

Fatigue analyses support signal data in any of the following formats:

File type Description
.asc ASCII histogram file.
.dac Single-channel binary data file.
.pch Nastran ASCII output file.
.rsp MTS RPCIII binary data file.
.sbf Servotest output file.
.sbr Servotest output file.
.sm Snap-Master file
.tab Adams multichannel ASCII tabular data file.
.txt ASCII single- or multichannel data file.

inter-event Transitions

inter-event transitions capture the effects of fatigue cycles that occur between fatigue events. The two short stress histories in the following diagram help illustrate why you might want to include inter-event transitions in your fatigue loading history:



In each stress history, the range of the cycles is 1.0. If you apply each stress history in its own event, the largest fatigue cycle would have a range of 1.0. (The fatigue damage caused by the second event would invariably be higher than that in the first event because the mean stress of the second is tensile.) However, if you concatenate the two histories, the largest fatigue cycle would have a range of 1.5 (from -0.5 to 1.0). Given that fatigue damage increases exponentially with the range, it is important to capture the largest cycles. In this case, if you apply the two histories in their own event and you want to capture the effect of the cycle of range 1.5, you must activate inter-event transitions.

Fatigue Loading Behavior When a Structural Analysis Case Has Several Strain Fields in Its Output

If your structural analysis includes multiple strain types in its output and you drive the fatigue loading using stress and strain, the behavior of the fatigue solution depends on the available strain fields. The following table summarizes the behavior for several examples of available strain fields:

Use Case Available Strain Fields Behavior of Fatigue Solve
1 Either E or LE, but not both Fatigue solver uses E or LE.
2 EE, PE, and any other strains Fatigue solver uses EE+PE.
3 EE only The fatigue analysis fails with an error explaining that PE is missing and no total strain alternative (E, LE, NE) is available.
4 PE only The fatigue analysis fails with an error explaining that EE is missing and no total strain alternative is available.
5 EE and either E or LE available. PE unavailable. The fatigue analysis uses either E or LE, whichever is available, to drive fatigue loading. The app returns a warning message alerting you about the output variable it is using for the analysis.
6 PE and either E or LE available. EE unavailable. The fatigue analysis uses either E or LE, whichever is available, to drive fatigue loading. The app returns a warning message alerting you about the output variable it is using for the analysis.

The output variable NE is sometimes output, but it is always accompanied by LE. The fatigue analysis ignores NE output data.

 

See Also
Defining Fatigue Loading