← All posts

February 3, 2026 · 4 min read

Why fatigue is still hard, and that is fine

An essay on the parts of fatigue analysis that resist automation — scatter, history, environment, and the judgement calls no pre-processor will ever ask you about.

The first time I ran a fatigue analysis I expected it to feel like static stress with a different button. It does not, and after years of doing it I have stopped expecting it to.

Static stress is, broadly, a question of equilibrium and material limits. You have a load, you have a geometry, you compute a stress, you compare it to an allowable. The physics is intimidating in detail but honest in shape: bigger load, bigger stress, smaller margin. Fatigue is a question of history, environment, and randomness, and none of those three is well-behaved.

Scatter is not noise — it is the subject

Run the same coupon, same material lot, same load, same temperature, ten times, and the lives can spread across an order of magnitude. That is not sloppy testing; it is the nature of the thing. Fatigue life is dominated by initiation, and initiation is governed by the worst local detail in a region of the microstructure — an inclusion, a surface scratch, a grain boundary at the wrong angle, the roughness left by the last machining pass. Which means fatigue is an extreme-value problem wearing a mean-value disguise: you don’t care about the average grain, you care about the worst one that happened to sit at the highest-stressed point. That is why the design number is never the mean life — it is the mean knocked down by a scatter factor (a life-reduction factor on the order of several, set by how much data you have and how much redundancy the structure has). The scatter is not an error bar around the answer. The scatter is the answer, and the factor is how we buy back the safety the scatter takes away.

History matters, and the pre-processor never asks

The same component, same peak load, same temperature, can fail in ten thousand cycles or in ten million depending on things no FE pre-processor will ever prompt you for:

  • The order of the loads. A high load before a block of small ones retards a growing crack; the same loads in the other order do not. Rainflow counting, which we need to turn a messy history into countable cycles, deliberately discards that order — so we count cycles and then worry, separately, about the sequence effects counting threw away.
  • The mean stress. A residual stress from cold-working a hole, or shot-peening a fillet, can move the local mean enough to change the life by a large factor — in the good direction if you put it there on purpose, the bad direction if it crept in from a process you didn’t control.
  • The environment. Temperature and moisture, corrosion, fretting at a faying surface. A benign laboratory life and a real in-service life can differ because the service environment was quietly doing chemistry the coupon never saw.

Static stress mostly doesn’t care about any of this. Fatigue cares about all of it, and the caring is non-linear: small errors in stress become large errors in life, because the S-N curve is steep and da/dN goes as ΔK to a power. Conservatism, and which direction it runs, is a first-class concern, not a footnote.

What automates and what doesn’t

This is, in a roundabout way, why I still find the discipline interesting. You can automate the mechanical parts — meshing, load application, stress recovery, rainflow counting, damage summation, even the bookkeeping of a full spectrum through a crack-growth integration. Those are arithmetic, and arithmetic should be automated. But the choices that actually set the answer stubbornly remain:

  • which S-N curve — which surface finish, which Kt, which environment, which basis;
  • which notch factor, Kf not Kt, and what notch sensitivity to assume;
  • where to draw the spectrum truncation and omission, and which way that errs;
  • whether to credit retardation, and with which model;
  • what scatter factor the structure’s redundancy and the data actually justify.

Each of those is judgement, informed by test, defended in a report. No tool makes them for you, because each is really a small argument about how much you trust your evidence.

Why that’s fine

If anything, the increasing speed of the rest of the pipeline makes the judgement calls more visible, not less. When the arithmetic took weeks, the assumptions hid behind the labour. When it takes an afternoon, there is nowhere for them to hide, and the conversation moves to where it always should have been: which assumption matters, and what evidence backs it.

That is the part of the job that stays a job — the part that needs a person who has seen hardware crack where the analysis said it wouldn’t, and learned to be suspicious in the right places. Fatigue is still hard because it is still, at its core, about judgement under scatter. Which, on a good day, feels less like a limitation and more like the reason the work is worth doing.