Skip to content

Add a synthetic dataset for local testing - #4

Open
lispandfound wants to merge 1 commit into
masterfrom
synthetic-data
Open

Add a synthetic dataset for local testing#4
lispandfound wants to merge 1 commit into
masterfrom
synthetic-data

Conversation

@lispandfound

@lispandfound lispandfound commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

Running nzcvm generate end to end has needed the real NZCVM data root:
a DEM, a Vs30 raster, a coastline, a tomography model and a directory of
basin meshes. That makes local iteration awkward and keeps the whole
generate path out of the test suite.

nzcvm/synthetic.py defines a small analytic world over a 48 x 44 km patch
of coast: elevation falls west to east and crosses sea level three quarters
of the way across, Vs30 tracks elevation, two paraboloid basins sit inland,
and a tomography block fills the rest. Every field is closed form, so the
data regenerates identically anywhere and a test can work out the expected
answer by hand.

nzcvm synthetic serialises those fields in the formats the production
readers already accept, so the synthetic files flow through the same
converters and layers as the real ones — surfaces go out as modeller-style
HDF5 for nzcvm surface convert, the tomography block as an EP2020 CSV for
nzcvm tomography convert, and each basin as an outline plus a basement
surface for nzcvm basin main.

just synthetic chains the lot into a data root under synthetic/, which
examples/synthetic.toml then generates a velocity model from.

Testing

just synthetic                                                  # ~1 min, mostly gmsh
uv run nzcvm generate examples/synthetic.toml synthetic/model.zarr
uv run --dev pytest tests/          # 194 passed, 1 skipped
uv run --dev pytest --doctest-modules nzcvm/
uv run ruff check nzcvm/ tests/ && uv run ty check nzcvm/

tests/test_synthetic.py asserts the analytic properties the rest of the
suite leans on (the shoreline is where elevation crosses zero, a basin closes
to zero thickness on its own outline) and reads each written file back through
the matching production reader. Building the basin meshes goes through gmsh
and is left to just, which is too slow for a unit test.

🤖 Generated with Claude Code


Stack created with GitHub Stacks CLIGive Feedback 💬

@lispandfound
lispandfound added this pull request to stack #6 September 10, 2026 06:56
@github-actions

Copy link
Copy Markdown

Benchmark for 5a74360

Click to view benchmark
Test Base PR %
Mesh_Point_Query/centre/4096000 245.0±1.32ns 244.2±0.62ns -0.33%
Mesh_Point_Query/far_corner/4096000 232.2±1.00ns 231.8±1.19ns -0.17%
Mesh_Point_Query/near_origin/4096000 280.1±3.53ns 282.3±2.10ns +0.79%

Running `nzcvm generate` end to end has needed the real NZCVM data root:
a DEM, a Vs30 raster, a coastline, a tomography model and a directory of
basin meshes. That makes local iteration awkward and keeps the whole
generate path out of the test suite.

`nzcvm/synthetic.py` defines a small analytic world over a 48 x 44 km patch
of coast: elevation falls west to east and crosses sea level three quarters
of the way across, Vs30 tracks elevation, two paraboloid basins sit inland,
and a tomography block fills the rest. Every field is closed form, so the
data regenerates identically anywhere and a test can work out the expected
answer by hand.

`nzcvm synthetic` serialises those fields in the formats the production
readers already accept, so the synthetic files flow through the same
converters and layers as the real ones — surfaces go out as modeller-style
HDF5 for `nzcvm surface convert`, the tomography block as an EP2020 CSV for
`nzcvm tomography convert`, and each basin as an outline plus a basement
surface for `nzcvm basin main`.

`just synthetic` chains the lot into a data root under `synthetic/`, which
`examples/synthetic.toml` then generates a velocity model from.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

Benchmark for ca8b094

Click to view benchmark
Test Base PR %
Mesh_Point_Query/centre/4096000 304.1±4.79ns 302.7±1.54ns -0.46%
Mesh_Point_Query/far_corner/4096000 201.1±3.03ns 202.2±4.82ns +0.55%
Mesh_Point_Query/near_origin/4096000 345.9±1.62ns 348.7±2.16ns +0.81%

@lispandfound
lispandfound removed this pull request from stack #6 September 10, 2026 10:39
@lispandfound
lispandfound added this pull request to stack #9 September 10, 2026 10:39
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