“Design for the 100-year event” gets said as though it were an engineering constant. It is a policy choice about how much risk is acceptable, and on armor it is not always the right question anyway.
What a return period is
A 100-year event is one with a one percent chance of being equalled or exceeded in any given year. Not one that happens every hundred years.
Two consequences people get wrong:
They cluster. Two 100-year events in successive years is unremarkable, not evidence the estimate was wrong.
The probability compounds over a design life. Over several decades, the chance of experiencing at least one such event is substantial. For an asset with a long design life, the design event is not a remote possibility.
How the return period gets chosen
By consequence, and usually by somebody else:
- Agency standards. Most DOTs and public owners specify design and check events by asset class
- Regulatory requirement. Floodplain regulation works on the base flood, commonly the one percent event
- Consequence of failure. A structure whose failure closes a sole-access route justifies a different standard from one that does not
- Asset design life. A longer life means more exposure to the compounded probability
- The owner’s risk position
If your project is on an agency asset, this is usually decided for you. If it is not, it is a decision to make explicitly and record rather than absorb from habit.
Design event and check event
Two different jobs.
The design event is what the works are sized for.
The check event, larger, is what the works are assessed against for acceptable behaviour. The question is not “does it survive undamaged” but “does it fail in an acceptable way.”
For armor, the useful check is whether an event beyond the design condition produces gradual, repairable damage or sudden loss of the asset. A layer that loses some units and is topped up afterwards behaves acceptably. A rigid system that cracks and drops does not.
The event that actually governs armor
Here is the part most worth taking away.
The largest flood is not always the worst case for armor.
Duration matters. Scour develops over time at the flood peak. A short, sharp extreme event may not have time to develop the scour depth that a longer, more moderate one does. The governing case can be a lower peak sustained for longer.
Frequency matters more than people expect. Armor does not fail once. It accumulates damage through repeated events, gets topped up, loses a bit more. The moderate flows that recur several times a year can do more cumulative geomorphic work than the rare extreme. This is the mechanism behind stormwater outfall erosion on developed catchments.
Direction and stage matter. At a bridge, flow alignment at flood stage may differ from the low-flow alignment, and the effective pier width changes with it. A moderate event on a different alignment can be worse locally than a larger one on the design alignment.
Debris arrives with events. A raft against a pier makes it hydraulically much wider, and that can dominate the local condition regardless of the return period.
So the useful question is not only “what is the design event” but “what condition produces the worst loading at this location,” which may be a different event.
Climate and non-stationarity
Design hydrology assumes the statistical record describes the future, and that assumption is under pressure.
Practically:
- Check how old the hydrology is. Design discharges get revised, and a model built on a superseded estimate is solving for the wrong flood. See taking a design velocity from a model
- Ask whether the owner has a climate allowance policy, because many now do
- Watch the margin. A design that clears the requirement by a wide margin is more robust to a revised estimate than one that just satisfies it
What to record
- The design event and its source
- The check event, if any
- The discharge and where the hydrology came from, with its date
- Whether a climate allowance was applied
- What condition was assessed as governing, if not the headline event
- Any assumption about debris
That record is what makes the design reviewable. See assembling the submittal package.