Wave Runup Exceedance z1p

1%-Exceedance Wave Run-up (z1%)

Source: CHESS_Library/Structure_Reponses/Equations/z1p_calc.m, called from van_gent_Dn50_leeside_stability.m (Van Gent Leeside Armor Stone Stability Dn50), leeside_armor_stone_damage.m (Leeside Armor Damage Progression LCS CSR), and directly from chess_csr_dpa.m (a separate, diagnostic-only pre-loop computation — see that page's equation section for the distinction). Applies to: struc_type = 3 (Rubblemound) only — this is a helper function used exclusively within the leeside/LCS-CSR family of equations, not dispatched from compute_structure_response.m. Enable flag: None of its own; it runs whenever its caller runs (config.compute_dn50_leeside for the Van Gent Dn50 path, or config.csr_call_dpa for the CSR-DPA path).

What it models

z1p_calc.m computes the run-up elevation exceeded by only 1% of the incident wave crests climbing a structure slope — a stricter (higher, less frequently exceeded) exceedance level than the 2%-exceedance run-up computed by EurOtop Wave Runup R2p. It is not dispatched as a stand-alone structure response; it exists purely as a shared building block feeding the leeside stability/damage equations, which need the 1%-exceedance run-up (and, downstream, the 1%-exceedance crest velocity from Crest Velocity Exceedance u1p) to determine whether overtopping flow reaches far enough up the slope to cross the crest and attack the leeside armor.

All three callers pass the seaside slope. The function itself takes a single generic slope argument (Sslp in its own signature) and has no opinion on which physical slope that represents — it is the caller's responsibility to supply the right one, and all three call sites in the codebase supply the seaside slope (structure.seaside_slope), consistent with the run-up physically occurring on the wave-facing side of the structure:

• van_gent_Dn50_leeside_stability.m passes the seaside slope.
• leeside_armor_stone_damage.m passes the seaside slope (fixed in commit c639475, "Fixed missing seaward slope input for z1% & u1%" — an earlier version of this function passed the leeside slope here instead, which was inconsistent with the other two callers; see Leeside Armor Damage Progression LCS CSR).
• chess_csr_dpa.m's own separate, diagnostic-only pre-loop call passes the seaside slope.

Conceptual model

• A rarer run-up for a harder load. Rear-side damage is driven by the few largest overtopping waves, so the leeside equations use the run-up exceeded by 1% of waves rather than the 2% of EurOtop Wave Runup R2p.
• Breaking type sets the run-up. It grows linearly with the Iribarren number ξ for breaking waves (ξ ≤ 1.76) and levels off towards 5.1·H for surging waves.
• Rough slopes. A built-in roughness factor for rock (γf from 0.55 for breaking waves to 1.0 for ξ ≥ 10) replaces the input roughness_ifactor, because rock armor dissipates breaking waves much more than surging ones.
• Low freeboard. For Rc < 0.6 m the run-up is set to 0, outside the formula's range; the rear-side load then comes from the overflow regime, which these equations do not model.

Conceptual diagram

The equation

Source: file header attributes original authorship to Jeff Melby (April 2009), "updated by JAM on 2-10-12 to use van Gent equations." No specific paper title or year is given in the file itself for the run-up formulation — see References for what can and cannot be confirmed.

Local wave conditions and surf similarity parameter, based on the spectral mean period Tm-1,0 (the function's own input-comment header labels this input Tp/"Mean wave period," but every call site in the codebase actually passes the spectral mean period Tm-1,0, consistent with the internal variable name Tmm1 — see Notes):

L_m-1,0 = g · Tm-1,0² / (2π)
s_m-1,0 = H / L_m-1,0
SSPm    = 1 / Sslp / √(s_m-1,0)          (Iribarren / surf-similarity parameter)

Empirical constants:

c0 = 1.45
c1 = 5.1
c2 = 0.25 · c1² / c0
pR = 0.5 · c1 / c0

Roughness/friction coefficient (rubble-mound specific, piecewise in the surf-similarity parameter):

γf = 0.55                              if SSPm ≤ 2
γf = 0.05625·(SSPm − 2) + 0.55         if 2 < SSPm < 10
γf = 1.0                               if SSPm ≥ 10

γβ = 1.0                                (wave-obliquity reduction factor — hard-coded to no reduction)
γ  = γf · γβ

Run-up (piecewise in the surf-similarity parameter relative to pR):

z1% = γ · H · (c1 − c2 / SSPm)          if SSPm > pR
z1% = γ · H · c0 · SSPm                  if SSPm ≤ pR

Freeboard restriction:

z1% = 0   where Rc < 0.6

Parameters

Symbol	Meaning	Units	Source
H	Significant wave height at the structure toe	m	Passed in by the caller (Hsig/Hm0/H depending on the caller)
Tmm1 (documented in-file as Tp, actually Tm-1,0)	Spectral mean wave period	s	Passed in by the caller, already converted to Tm-1,0 before this call
Rc	Freeboard: crest_elevation − SWL (or an artificially raised freeboard if the caller applies a cutoff correction)	m	Passed in by the caller
Sslp	Cotangent of the slope used in the surf-similarity parameter — the seaside slope, at every current call site (see What it models)	—	structure.seaside_slope
grav	Gravitational acceleration	m/s²	config.gravity_constant
γf	Roughness/friction coefficient (rubble-mound specific, computed internally from SSPm)	—	Computed internally — not the same call_eurotop_ifactors.m roughness factor used by the EurOtop run-up/overtopping pages
γβ	Wave-obliquity reduction factor	—	Hard-coded to 1.0 (no reduction) inside this function

Notes / limitations

• The function's own header documentation is internally inconsistent with its behavior. The header comments describe the period input as Tp ("Mean wave period") and the output as z2 ("2% exceedance runup value"), but the function's actual output variable and every caller's treatment of it is the 1%-exceedance run-up (z1p), and every call site in the codebase passes the spectral mean period Tm-1,0, not Tp. Treat the in-file header as stale/copy-pasted rather than authoritative for either the exceedance level or the period convention.
• The header comment also lists a gamma_R ("correction for wave direction and/or roughness") input that does not exist in the actual function signature (only H, Tmm1, Rc, Sslp, grav are accepted) — another indication the header predates the current implementation.
• The roughness coefficient γf computed here is specific to this function (piecewise-linear in the surf-similarity parameter) and is a separate code path from the call_eurotop_ifactors.m influence factors used elsewhere in the library (e.g., EurOtop Wave Runup R2p, EurOtop Overtopping Discharge q) — the two should not be assumed to produce the same value for the same physical slope.
• This function has no independent config.compute_* enable flag; it always runs as part of whichever caller invokes it.

References

• Melby, J. A. Author attribution and April 2009 date per the in-code header of z1p_calc.m. Title/publication not stated in the file.
• Attribution gap: the file's only indication of a literature source is the header comment "updated by JAM on 2-10-12 to use van Gent equations" — no specific Van Gent paper (title or year) is named. Given that this function is used exclusively by the leeside/Van Gent & Pozueta family of equations elsewhere in the library (see Van Gent Leeside Armor Stone Stability Dn50 and Leeside Armor Damage Progression LCS CSR, which cite Van Gent, M. R. A., and B. Pozueta. 2004/2005 by title), it is plausible the run-up formulation here originates from the same Van Gent body of work, but this is inference from context, not a confirmed in-file citation — treat any specific paper attribution for this function's run-up formula as unconfirmed.