CHESS PROS

CHESS: PROS Workflow

Workflow selector: config.workflow = 1 (PROS), 4 (PROS-FB) Sibling workflows: CHESS LCS (workflow = 3) and CHESS DET (workflow = 2). All three use the same per-storm response equations (PSE Hydraulic Responses).

What PROS is

PROS is CHESS's operational implementation of the response-based (RB) stochastic structure response simulation methodology described in the coastal engineering literature (Melby et al. 2021, Appendix G — see References), as opposed to the older, simpler event-based (EB) approach that most of civil engineering practice historically defaulted to. The distinction is fundamental to why PROS is built the way it is: an EB approach characterizes storm forcing at a single statistic (e.g., the 1%-AEP SWL and Hm0) and computes one response from that single synthetic "event," which is cheap but brittle — the cited source found EB analyses produced -0.5 to +3.5 ft of error in an optimized design crest elevation relative to the full RB approach, with the error uncorrelated to any predictable structure or hazard property, and concluded that an EB2-style Monte Carlo variant "provides poor estimates of overtopping rate hazard." An RB approach instead computes the structure response for every storm in the full probabilistic storm population first, and only then builds the hazard curve from that population of per-storm responses — more computationally demanding, but the response statistic itself stays consistent across the whole analysis rather than resting on a single, arbitrarily-constructed forcing event. PROS is built around RB as its core response-computation method for exactly this reason; EB-style logic only reappears, deliberately narrowed, inside the PROS-FB module (see "Secondary/derived responses" below) for the minority of responses that cannot be computed any other way.

PROS also occupies a specific layer in the broader CHS/CHESS stack: it is the structure-response layer sitting on top of CHS's already-characterized storm population, not the layer that characterizes storm probability itself. CHS's Probabilistic Coastal Hazard Analysis (PCHA) framework (Nadal-Caraballo et al. 2020 — see References) does the upstream work of answering "how often does a storm of a given severity occur at this site" for a region — via JPM-OS/SST, a meta-Gaussian copula, a Gaussian process metamodel, and spatially-varying bias correction — and packages the result as the historical-plus-synthetic storm populations and probability weights that ship as CHS_Dependencies/ data. PROS takes that already-characterized storm population as a given input and asks the complementary, structure-specific question: "given this storm population, how does this particular structure, at this site actually respond, and at what frequency does a given magnitude of that response occur?" It does this by running every storm (or storm replicate) through the project's specific structure-response equations (compute_structure_response.m) and only then assembling the resulting population of responses into a hazard curve — the RB approach described above, now made concrete.

In practice, PROS's own internal design choices are also traceable to the same source literature: it defaults to the cheaper RB1 (peaks-only) sampling basis rather than the full RB3 (timeseries) basis, reserving RB3 for the minority of responses that inherently require time-integration (e.g., cumulative overtopping volume) — consistent with Appendix G's finding that RB1, RB2, and RB3 produced statistically indistinguishable hazard curves and design outcomes despite RB3 costing an order of magnitude more compute. And it layers a distinct, separately-invoked frequency-base (PROS-FB) module on top of ordinary PROS specifically for the handful of responses (wall pressure P2/P3, nappe flow) that cannot be computed per-storm from raw forcing at all, and so have to be derived after the fact from an already-built hazard curve instead — see "Secondary/derived responses and epistemic uncertainty" below.

What question PROS answers

PROS — "Probabilistic Response(s) Of Structures" in the code's own console banners (config_reference.md separately labels it "Probabilistic Response Output System"; both names refer to the same workflow ∈ {1,4} code path) — is CHESS's frequency-based extreme value analysis. It answers a single design question:

For this structure, at this site, what response level (run-up, overtopping discharge, armor stone size, wall pressure, etc.) is associated with a given annual exceedance probability — e.g., "what is the R2% for the 1%-AEP event"?

That is a fundamentally different question from what LCS (workflow = 3) answers. LCS samples storms into simulated multi-year life cycles (Monte Carlo, Poisson-sampled storm arrivals) and tracks how a structure's condition evolves over time — e.g., cumulative rubblemound armor damage across repeated storm hits, with optional repair logic. PROS instead treats the structure's condition as static and asks how a response is distributed across the full population of possible storms; LCS asks how repeated storms degrade the structure over a service life. Both workflows call the same single-storm response equations (compute_structure_response.m, documented on Structure Response Equations) but assemble them into different probabilistic frameworks.

Hazard curves: the central object

A hazard curve is a plot of a response magnitude against its annual exceedance probability (or frequency) — AEP/AEF. Rather than designing to a single "design storm," coastal engineering practice wants to know the full relationship between "how big" and "how often": the response level that a 10%-chance-per-year event produces, the response level a 1%-chance-per-year event produces, and so on down to very rare, very large events. PROS builds this curve directly from the full population of historical/synthetic storms available for a site (CHS extratropical and/or tropical storm data) rather than from any single storm run in isolation, because the whole point of a probabilistic design basis is to characterize risk across the full range of storm severity, not just at one arbitrarily chosen event.

Every hazard curve PROS produces can also carry confidence limits (CLs): instead of a single best-estimate line, the curve can be reported as a family of percentile curves (e.g., 5th/50th/95th, configurable via config.project_CLs, max 4 plus the always-included 50th). These percentiles are not decorative — they represent the statistical uncertainty in the extreme-value fit itself, and a design decision based only on the central curve ignores that spread. Reporting the 5%/95% (or similar) bounds alongside it lets an engineer see how much confidence the estimate deserves at a given AEP, which matters most at the rare, low-probability end of the curve where data is thinnest. How that spread is actually computed differs by storm type, not a detail to gloss over: XC/CHESS PST gets there via genuine bootstrap resampling of the empirical record, while TC/CHESS JPM gets there via a closed-form analytic Gaussian-percentile formula — no resampling at all. Also, the labeled "50" column in both engines' output is not a literal computed median/50th-percentile in either case; see each engine's own page for exactly what it is.

Two storm populations, two statistical engines

Coastal storm climates at most sites are a mix of two very different kinds of storms, and each is handled by a purpose-built statistical engine because the nature of the historical record for each is different:

• Extratropical (XC) storms — CHESS PST. Extratropical storms occur frequently enough that a station typically has a reasonably long historical/hindcast record to work from, so PROS treats each XC storm's peak response as one event in a peaks-over-threshold (POT) sample and fits a Generalized Pareto Distribution to the exceedances, with bootstrap resampling to produce confidence limits. Correction from an earlier version of this page: CHESS_PST is fully in-repo, not an external routine, and despite being labeled "SST" ("Stochastic Simulation Technique") in some of the code's own progress messages, it is not a stochastic storm-simulation method at all — it's a standard POT/GPD extreme value analysis. See CHESS PST for the full algorithm, including the real in-code naming inconsistency between "PST" and "SST."
• Tropical (TC) storms — CHESS JPM. Tropical cyclones are comparatively rare at any single site — a hurricane making a direct, damaging pass close to a given project location may only have happened a handful of times (or never) in the actual historical record. That sparsity makes a peaks-over-threshold approach (like PST/XC's) impractical for TC. JPM instead works by synthesizing a large set of storms spanning the plausible parameter space (track, intensity, size, forward speed, etc. — as encoded upstream in the CHS TC storm suite) and assigning each synthetic storm a discrete probability of occurrence weight — a genuine annual climatological rate, not an empirical observation count — rather than treating it as drawn from an observed sequence. PROS calls this via CHESS_JPM, weighting each TC storm/replicate's response by its Discrete Storm Weight (project_forcing.TC.TC_Prob) pulled from the CHS Probability Masses. Like PST, CHESS_JPM is fully in-repo; see CHESS JPM for the discrete JPM integral, its two-layer uncertainty-discretization mechanism, and its analytic (non-bootstrap) confidence-limit formula.
• Combining the two (CC). At a site exposed to both storm climates (e.g., much of the Gulf and Atlantic coasts), the PST-derived XC hazard curve and the JPM-derived TC hazard curve are combined into a single all-storms hazard curve (config.storm_sampling = 'CC') — because the true annual exceedance probability of a given response level is driven by both populations acting together, not either one alone. Worth flagging here rather than glossing over: PST's confidence limits come from bootstrap resampling while JPM's come from a closed-form Gaussian formula — two genuinely different statistical mechanisms whose percentile-labeled outputs get combined positionally by call_hazard_curve_combiner.m. Whether that's an accepted simplification or a real accuracy gap wasn't fully resolved by this investigation; see CHESS JPM's naming/terminology notes for the open question.

The published methodology behind how CHS itself characterizes storm probability — the upstream science that produces the storm/probability data in CHS_Dependencies/ that PST/JPM consume — is documented in Nadal-Caraballo et al. (2020) (see References): a Probabilistic Coastal Hazard Analysis (PCHA) framework combining storm climatology characterization, high-resolution hydrodynamic modeling, joint probability analysis with uncertainty quantification, a meta-Gaussian copula for computing storm probabilities, spatially-varying bias correction, and a Gaussian process metamodel (GPM) that emulates the hydrodynamic model's response rather than rerunning full physics for every synthetic storm. This describes the methodology behind the storm/probability data itself, which is a distinct thing from CHESS's own CHESS_PST/CHESS_JPM routines that consume that data — both of which, unlike an earlier draft of this page assumed, are fully in-repo and documented in depth on CHESS PST and CHESS JPM.

Response-based vs. forcing-based hazard curves

PROS can build a hazard curve for the structure response itself (R2%, overtopping discharge, armor stone Dn50, wall pressure, etc.) — the primary product most design questions need. It can also build hazard curves for the forcing variables directly (SWL/SSL, Hm0, Tp), controlled by config.pros_compute_forcing_HC. Both are useful: a response hazard curve directly answers "what response level corresponds to this AEP," while a forcing hazard curve characterizes the AEP of the driving conditions themselves — and, critically, a forcing hazard curve is the input the frequency-base secondary-response step (below) needs, since some responses can only be derived from already-built forcing hazard curves rather than computed storm-by-storm.

Two sampling strategies: peaks-only vs. full-timeseries

PROS can draw its storm population from two different representations of the CHS forcing data, controlled by config.use_peaks / config.use_timeseries (naming: RB1 = peaks, RB3 = timeseries):

• RB1 — Peaks. Each storm is represented by its single peak SWL/Hm0/Tp combination. This is the standard extreme-value-analysis approach: treat each storm as one representative event, compute one response value per storm, and build the hazard curve from that population of per-storm peak responses. It is fast and is sufficient whenever the response of interest is itself a peak-type quantity (a peak run-up, a peak pressure, a peak armor stone size requirement). Within RB1, a project can optionally also process WLP (Water Level Priority) and/or WHP (Wave Height Priority) peak-matching datasets, which represent alternate ways of pairing SWL and wave peaks within the same storm.
• RB3 — Timeseries. Uses the full CHS storm hydrograph rather than a single peak triplet. This is necessary whenever the response itself is not a peak value but a time-integral — most notably cumulative overtopping discharge volume (compute_q_vol), which has to be integrated across the rising and falling stages of the storm's forcing rather than evaluated once at the peak. A peaks-only approach cannot produce this quantity at all, because it discards the shape of the storm's time history that the integration needs.

Both sampling strategies funnel through the same hazard-curve-building machinery (SST/JPM as described above) once the per-storm response population has been computed; the difference is only in how that per-storm response population is generated.

The RB1/RB3 naming appears to trace to Appendix G, "Stochastic Structure Response Simulations," of Melby et al. (2021) (see References), which defines a third, intermediate method alongside these two: RB2 — quasi-time-dependent, which computes the response deterministically at every timestep of the storm, finds the timestep at which response (not forcing) peaks, and then reads SWL/Hm0/Tp/MWD off at that same timestep. A search of this codebase found no RB2 implementation anywhere — only RB1/Peaks and RB3/Timeseries exist. That appendix reports RB1, RB2, and RB3 as producing "virtually identical" hazard curves and optimized crest elevations across its test cases, with RB3 costing nearly an order of magnitude more computational time than RB1 — a plausible explanation (though not confirmed by any in-repo source) for why CHESS implements only RB1 and RB3, skipping RB2 as an unnecessary middle ground, and treats RB1/Peaks as the faster, sufficient default.

Secondary/derived responses and epistemic uncertainty (PROS-FB)

Some structure responses cannot be computed storm-by-storm from raw forcing at all — they are only meaningful once a primary response's hazard curve already exists. Two examples in the codebase: Goda uplift/toe wall pressures (P2/P3), which are derived from an already-built p1 (wave pressure) hazard curve, and floodwall nappe flow, which is derived from an already-built overtopping discharge (q) hazard curve. These are handled as a distinct frequency-base step (config.workflow = 4, PROS-FB, or the compute_p2_p3/compute_nappe switches layered onto ordinary PROS) rather than inside the main per-storm response loop, because there is no raw-forcing storm to compute them from directly — the hazard curve itself is the input.

This two-branch structure matches the EB1/EB2 dichotomy defined in Appendix G, "Stochastic Structure Response Simulations," of Melby et al. (2021) (see References — see also "Naming and terminology notes" below). EB1, per that source, computes a forcing statistic once from a closed-form mean-hazard-curve procedure and plugs it directly into deterministic response equations, with no per-sample resampling. chess_pros_frequency_base.m's workflow = 1 branch — code-commented "EB1" — does exactly this: it reuses an already-built primary hazard-curve value directly inside the deterministic Goda P2/P3 and nappe-flow equations.

PROS-FB's Monte Carlo branch (workflow = 4, code-commented "EB2") goes a step further and matches that same source's EB2 definition: rather than a single deterministic pass, EB2 runs a full Monte Carlo loop — random-sampling assigned uncertainty, applying it to the forcing statistic, computing the response per sample, and taking percentiles from the resulting distribution. Concretely in CHESS: for each point on a primary forcing hazard curve (SWL, Hm0, Tp), it draws a large synthetic cloud of forcing values (10,000 draws) scattered around that hazard-curve point according to assigned epistemic uncertainty bands for SWL and Hm0 (config.chs_swl_u_a/u_r, config.chs_hm0_u_a/u_r), then re-runs the full structure-response calculation on every draw in the cloud and reads off the desired percentile from the resulting distribution. Conceptually, this is propagating measurement/model uncertainty in the forcing (how confident are we in the estimated SWL or wave height at a given AEP) through the response equations to get uncertainty in the derived response at that same AEP — the same epistemic-uncertainty propagation logic used in USACE/FEMA-style coastal storm surge studies, where still water level and wave height are never known with certainty and that uncertainty needs to show up in the final risk product rather than being silently dropped. It is a different uncertainty concept from the confidence-limit percentiles discussed above (those come from the extreme-value statistical fit itself); here the uncertainty is being injected deliberately from externally-assigned bounds on the forcing.

There is a further, verified connection worth noting: the CHS forcing hazard curves that both EB1 and EB2 start from already have an earlier layer of uncertainty baked into their construction using the same "444 replicates" discretization the paper describes for its own hazard-curve integration (a closed-form 0.15-uncertainty-proportion step in the paper's case study, applied before any Monte Carlo). In this codebase, CHESS_Library/Uncertainty/call_uncertainty_engine.m loads discrete_norm_444.txt for TC storms specifically when config.workflow is 1 or 4 (PROS/PROS-FB), and CHESS_Library/Extreme_Value_Analysis/JPM/CHESS_JPM_integration.m loads the same file for the JPM integration path — both replacing a brute-force Monte Carlo loop with a fixed set of 444 z-score replicates, matching the paper's description almost exactly (CHESS_Library/Forcing_Generation/PROS/chess_pros_formater.m comments this as "444 values covering the (-3,3) z-score range"). The frequency-base module's own 10,000-draw Monte Carlo described above is a separate, later uncertainty step layered on top of that — consistent with the paper's EB2 applying a further, remaining uncertainty proportion (0.132, in the paper's own case study) after its initial hazard-curve integration is already done. This confirms CHESS's "444" figure is the same mechanism the paper describes, not a coincidence.

Implementation reference

This section is a pointer for readers who want to trace the code directly; it is intentionally not the focus of this page.

• Entry points: CHESS_Library/Structure_Reponses/call_project_response.m → CHESS_Library/Structure_Reponses/PROS/chess_pros.m → CHESS_Library/Structure_Reponses/PROS/chess_pros_frequency_base.m
• Hazard curve construction: CHESS_Library/Extreme_Value_Analysis/call_hazard_curve_builder.m (calls CHESS_PST for XC — see CHESS PST — and CHESS_JPM for TC — see CHESS JPM) and call_hazard_curve_combiner.m (builds the CC curve from XC+TC).
• Frequency-base / secondary responses: chess_pros_frequency_base.m dispatches on config.workflow: the workflow = 1 branch (internally labeled "EB1" in code comments) reuses already-built primary hazard curves for P2/P3 and nappe flow; the workflow 4 branch (labeled "EB2") runs the Monte Carlo forcing-uncertainty resampling described above via pcha_forcing_uncertainty_EB2. Neither "EB1" nor "EB2" is spelled out anywhere in this codebase's own source comments, but Appendix G of Melby et al. (2021) (see References) defines both labels in a way that matches these two branches' behavior closely — see "Secondary/derived responses" above and "Naming and terminology notes" below. A related, broader function, CHESS_Library/Structure_Reponses/Frequency_Base/compute_frequency_base_responses.m, is not called anywhere in the current codebase and should be treated as historical/orphaned rather than documentation of current behavior.
• Config fields: all PROS-specific fields (pros_compute_forcing_HC, pros_use_aep, pros_plot_*, etc.) plus the related response/uncertainty/workflow fields PROS consumes are documented in config_reference §9 (PROS Module) and cross-referenced from §1 (workflow/storm_sampling/use_peaks/use_timeseries), §5 (response switches), and §6 (forcing uncertainty). This page does not reproduce those tables — see config_reference.md for field-by-field defaults and types.
• Visualization: PROS plots come from Visualization/pros_methods.m via CHESSPlots: hazard curves with an optional storm-event overlay, and the RB vs FB comparison. See Visualization.

References

• Nadal-Caraballo, N.C., Campbell, M.O., Gonzalez, V.M., Torres, M.J., Melby, J.A., and Taflanidis, A.A. (2020). "Coastal Hazards System: A Probabilistic Coastal Hazard Analysis Framework." Journal of Coastal Research, Vol. 95, No. sp1. DOI: 10.2112/SI95-235.1.
• Melby, J.A., Massey, T.C., Stehno, A.L., Nadal-Caraballo, N.C., Misra, S., and Gonzalez, V.M. (2021). "Sabine Pass to Galveston Bay, TX Pre-construction, Engineering and Design (PED): Coastal Storm Surge and Wave Hazard Assessment. Report 1 – Background and Approach." ERDC/CHL TR-21-15, Report 1. US Army Engineer Research and Development Center. Appendix G, "Stochastic Structure Response Simulations," pp. 190-206. DOI: 10.21079/11681/41820.

Naming and terminology notes

• PROS name drift: config_reference.md calls this module "Probabilistic Response Output System," while in-code disp() banners call it "Probabilistic Response(s) Of Structures." Both are reported here without assuming one is more authoritative.
• "EB1"/"EB2" are used as inline labels in chess_pros_frequency_base.m (workflow = 1 and workflow = 4 respectively) but are not defined anywhere in this codebase's own comments or docs. Appendix G, "Stochastic Structure Response Simulations," of Melby et al. (2021) (see References) defines EB1 and EB2 as two ends of a spectrum: EB1 computes a forcing statistic once, via a closed-form mean-hazard-curve procedure, and feeds it directly into deterministic response equations; EB2 instead runs a full Monte Carlo loop — random-sampling assigned uncertainty around that same forcing statistic, computing the response per sample, and taking percentiles from the resulting distribution. That matches chess_pros_frequency_base.m's case 1/case 4 branches closely enough — combined with the fact that CHESS's own code comments use the identical "EB1"/"EB2" labels — that this paper is almost certainly the terminology's origin. That said, this is an inferred lineage based on label and behavior correspondence, not a lineage confirmed by any citation in CHESS's own source or documentation.
• compute_frequency_base_responses.m has no live caller in the current codebase (confirmed as orphaned by the maintainer) despite overlapping logic with chess_pros_frequency_base.m.