Verification & Validation

A simulated seismogram is only worth something if it resembles what a seismometer actually recorded. We publish two kinds of evidence that it does, and they are different work — so they get separate pages rather than one table that would have to pretend they were comparable.

Both pages report the same metric. Mean |bias| is ln(observed / simulated) RotD50 spectral acceleration, averaged over stations. A bias of 0.69 is a factor of two, and that is the pass band on both pages. It is declared before each run, not chosen after seeing the result.

Verification — the half that has not started

Validation asks whether a simulation matches what instruments recorded. Verification asks something different: whether simulated motions for a synthetic scenario land inside the range empirical ground motion models predict. No recordings are involved — the target is built by averaging the NGA-West2 medians. SCEC defines 16 such scenarios; across 7 methods that is 112 cells.

None of it has run, and the reason is worth stating rather than hiding. These packages ship a *_validation_config.txt, so bbpapi's catalog discovers them as ordinary validation events and reports them runnable — but EVENT_TYPE is never parsed and the workflow hardcodes obs_format="acc_peer". Submitted today a scenario would run the physics, find no PEER files, skip every station, and produce a goodness-of-fit against nothing while exiting 0. The suite stays unrun until bbpapi parses EVENT_TYPE.

The suite is defined in code and pinned by tests, so when it does run its cells fill in against a denominator fixed beforehand — the only way a completeness figure means anything. Validation results, including how far each method sat from the recordings, are available to any signed-in account.