Describe SW4 grids in the realisation, and add the v26.7.1Hz profile

[lispandfound]

Introduces the realisation sections an SW4 run is configured by, the
geometry derived from them, and the first shipped set of values. They
are one change because the geometry exists only to read the config
classes, and the defaults are the shipped instance of both -- the tests
that pin the geometry assert against those numbers, not synthetic ones.

Configuration. Refinements describes the stack of vertical grids
SW4 solves on, in the abstract -- the layers a domain of any depth would
be given. refinements_for_depth resolves that against a particular
domain: it truncates at the domain floor, extends with
unbounded_refinement_resolution if the listed layers do not reach that
far, and guarantees the last layer is at least two cells deep so a
domain ending just past a refinement boundary does not degenerate.

SW4Parameters holds SW4's input file as a list of SW4Commands rather
than a fixed set of typed fields. SW4 has a large and growing command
vocabulary and we do not want a field per command; anything SW4 accepts
can be written as {"name": ..., "parameters": {...}} without touching
this code. render() handles the two places SW4 differs from Python's
str(): booleans go out as 0/1, and None parameters are omitted
rather than rendered as "None".

Geometry. workflow.sw4 is the single definition of the supergrid
sponge, which three later stages need and must not each re-derive.
minimum_fault_buffer_m is sponge + 5h, additive rather than a
multiple: the two terms have different origins -- the sponge is where
the equation changes, the five grid points are the source stencil plus
the dissipation operator applied to its outermost point -- and a
multiplicative margin would collapse as the grid refines while the
stencil still spans five points. supergrid_width follows SW4's own
precedence: width= beats gp=, and with neither, SW4's built-in 30
gridpoint default.

absorbed_period is advisory and nothing enforces it. Clearing the
sponge is not the same as the sponge working: the layer absorbs
adiabatically only while W cos(theta) / lambda >> 0.431, so a 12 km
sponge absorbs below ~8 s at normal incidence and ~4 s at 60 degrees.
That is a property of the period band being asked for, not of the
buffer.

Values. The load-bearing one is fault_buffer: 14.0 km, against the
root default of 2.0 km. Two criteria bear on it and only the first is
enforced (by a later commit):

HARD FLOOR, 14 km. A source must sit outside the sponge plus the
stencil margin: (30 + 5) * 400 m, at the widest sponge any supported
domain produces. Below this the run is not a ground motion prediction
-- it is the standing-wave failure seen in validation_results_24-08.

LONG-PERIOD CRITERION, ~80 km. Sound runs in that campaign sat 83-113
km from the domain edge, broken ones 4-5 km. Deliberately NOT
enforced: enforcing it would reject every affordable domain.

The 2.0 km root default stays. It is the EMOD3D value, kept for
CyberShake reproducibility; v24.2.2.x have no absorbing layer to clear.
The sponge is stated as width: 12000.0 rather than gp: 30, because
gp is measured on the coarsest grid and would vary with domain depth.

SKIP_PAIRS records the two genuinely version-specific sections:
refinements describes a grid the EMOD3D versions do not have, and
resolution is a single uniform spacing an SW4 run does not have.

No pipeline stage reads any of this yet.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}