Rewrite hf-sim on the hf-simulation package - #145
Draft
lispandfound wants to merge 1 commit into
Draft
Conversation
| "nshmdb>=2026.08.3", | ||
| "oq_wrapper>=2026.05.2", | ||
| "qcore-utils>=2025.12.2", | ||
| "hf-simulation @ git+https://github.com/ucgmsim/high-frequency", |
Contributor
There was a problem hiding this comment.
Suggested change
| "hf-simulation @ git+https://github.com/ucgmsim/high-frequency", | |
| "hf-simulation @ git+https://github.com/ucgmsim/high-frequency.git", |
lispandfound
force-pushed
the
nzvm/hf-simulation
branch
from
September 2, 2026 02:23
002a46f to
82667dc
Compare
lispandfound
force-pushed
the
nzvm/hf-simulation
branch
from
September 2, 2026 02:52
82667dc to
4f095b6
Compare
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>
lispandfound
force-pushed
the
nzvm/hf-simulation
branch
from
September 4, 2026 01:44
4f095b6 to
d4d01b8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces the hand-rolled Fortran deck writer and subprocess fan-out with
the
hf-simulationpackage, and runs it per station chunk under dask soa run is no longer bounded by one node's memory.
This changes every high-frequency result, principally through one
value.
corner_frequency_alphawas-99.0. That was never the physicalparameter: 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.0on disk meant 0.1. That decode lived in the deck reader, whichis gone.
hf-simulationtakes the value literally, and -99.0 drivesalpha_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
hfrealisation section is regrouped intosource/path/site/recordto mirrorhf_simulation.HfConfiggroup for group andfield 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 thanconfigured.
Two of
HfConfig's inputs are deliberately absent from the realisation.record.duration_sis computed from the domain, and thesource.rupture_velocitymultipliers live inRuptureVelocitybecauseSRF generation reads the same physical values -- one number, one home.
hf-siminjects both.vs_mohomoves fromhftohf_velocity_model_1d. It truncates thevelocity 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 CLI • Give Feedback 💬