Skip to content

Rewrite hf-sim on the hf-simulation package - #145

Draft
lispandfound wants to merge 1 commit into
empirical_imsfrom
nzvm/hf-simulation
Draft

Rewrite hf-sim on the hf-simulation package#145
lispandfound wants to merge 1 commit into
empirical_imsfrom
nzvm/hf-simulation

Conversation

@lispandfound

Copy link
Copy Markdown
Contributor

Replaces the hand-rolled Fortran deck writer and subprocess fan-out with
the hf-simulation package, and runs it per station chunk under dask so
a run is no longer bounded by one node's memory.

This changes every high-frequency result, principally through one
value.

corner_frequency_alpha was -99.0. That was never the physical
parameter: the Fortran deck reader treated anything below -1.0 as "use
the built-in default" (if(Calpha.lt.-1.0) Calpha = Calpha_default), so
-99.0 on disk meant 0.1. That decode lived in the deck reader, which
is gone. hf-simulation takes the value literally, and -99.0 drives
alpha_T negative for any fault that is not a vertical strike-slip. The
default is now 0.1, which is what the old configuration actually
computed with -- and is hf_simulation.SourceParameters' own default.

The hf realisation section is regrouped into source / path /
site / record to mirror hf_simulation.HfConfig group for group and
field for field, so it deserialises straight into that class instead of
being translated. That is deliberate: a translation layer between two
descriptions of the same physics is exactly the thing that drifts, and
this branch's history is largely a record of it having drifted. The
fields that used to be documented as "Unknown!" are gone -- they were
deck-format artefacts (nbu, ift, nl_skip, velocity_name,
ic_flag), zeroed uncertainty knobs, or values now computed rather than
configured.

Two of HfConfig's inputs are deliberately absent from the realisation.
record.duration_s is computed from the domain, and the
source.rupture_velocity multipliers live in RuptureVelocity because
SRF generation reads the same physical values -- one number, one home.
hf-sim injects both.

vs_moho moves from hf to hf_velocity_model_1d. It truncates the
velocity model at the Moho, which is a property of the model rather than
of the simulation.

Blocked on an hf-simulation release; currently a git dependency.

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


Stack created with GitHub Stacks CLIGive Feedback 💬

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change the following dependencies for consistency.

Comment thread pyproject.toml
"nshmdb>=2026.08.3",
"oq_wrapper>=2026.05.2",
"qcore-utils>=2025.12.2",
"hf-simulation @ git+https://github.com/ucgmsim/high-frequency",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"hf-simulation @ git+https://github.com/ucgmsim/high-frequency",
"hf-simulation @ git+https://github.com/ucgmsim/high-frequency.git",

Replaces the hand-rolled Fortran deck writer and subprocess fan-out with
the `hf-simulation` package, and runs it per station chunk under dask so
a run is no longer bounded by one node's memory.

**This changes every high-frequency result**, principally through one
value.

`corner_frequency_alpha` was `-99.0`. That was never the physical
parameter: the Fortran deck reader treated anything below -1.0 as "use
the built-in default" (`if(Calpha.lt.-1.0) Calpha = Calpha_default`), so
`-99.0` on disk *meant* 0.1. That decode lived in the deck reader, which
is gone. `hf-simulation` takes the value literally, and -99.0 drives
alpha_T negative for any fault that is not a vertical strike-slip. The
default is now 0.1, which is what the old configuration actually
computed with -- and is `hf_simulation.SourceParameters`' own default.

The `hf` realisation section is regrouped into `source` / `path` /
`site` / `record` to mirror `hf_simulation.HfConfig` group for group and
field for field, so it deserialises straight into that class instead of
being translated. That is deliberate: a translation layer between two
descriptions of the same physics is exactly the thing that drifts, and
this branch's history is largely a record of it having drifted. The
fields that used to be documented as "Unknown!" are gone -- they were
deck-format artefacts (`nbu`, `ift`, `nl_skip`, `velocity_name`,
`ic_flag`), zeroed uncertainty knobs, or values now computed rather than
configured.

Two of `HfConfig`'s inputs are deliberately absent from the realisation.
`record.duration_s` is computed from the domain, and the
`source.rupture_velocity` multipliers live in `RuptureVelocity` because
SRF generation reads the same physical values -- one number, one home.
`hf-sim` injects both.

`vs_moho` moves from `hf` to `hf_velocity_model_1d`. It truncates the
velocity model at the Moho, which is a property of the model rather than
of the simulation.

Blocked on an hf-simulation release; currently a git dependency.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant