PICurv 0.1.0
A Parallel Particle-In-Cell Solver for Curvilinear LES
 
Loading...
Searching...
No Matches
57e1307-grid-generator-fixes

Legacy grid conversion: fully removed Code: convert_legacy_1d_to_picgrid and its four helpers in grid.gen, the legacy1d subcommand, convert_legacy_grid_with_gridgen in core.py (5 call sites), the grid.legacy_conversion schema, and the standalone convert_grid_from_legacy_to_picgrid.py wrapper — all deleted. grid.legacy_conversion is now rejected as an unsupported key automatically, through the same generic schema mechanism as any other removed option — no bespoke rejection code needed. Docs (README, page 07, page 14, page 48, master_case.yml, both generator guides) updated to match. Tests: two removed, one repurposed to prove the key is now rejected.

ic_gen + programmatic_c: fixed, and the real bug was one layer deeper than I'd diagnosed Live-testing exposed that my original diagnosis was incomplete. There were two independent breaks stacked on top of each other:

materialize_run_assets refused every run –solve using this combination, before ever reaching the code I'd planned to fix — it reuses the standalone precompute command's atomic "no runtime-C providers" refusal, which is correct for picurv precompute (nothing there can execute the C runtime) but wrong for picurv run (whose own solver builds that grid moments later). Fixed by threading a precomputable_only flag through precompute_case_assets, so run-staging drops the runtime-C dependency from the closure instead of refusing. The bridge grid ic.gen needs was never materialized. Fixed at both remaining call sites using the already-tested generate_picgrid_from_programmatic_settings (identical formula to ComputeStretchedCoord in src/grid.c, so it's guaranteed to match what the solver independently builds). Verified with a real picurv run –solve end-to-end (not just unit tests): a flat_channel-based case with programmatic_c + ic_gen now completes successfully, the bridge grid and staged IC field are the right shape, and the solver never receives a stray -grid_file. Found two existing tests that had pinned the broken behavior as the expected outcome (pytest.raises(SystemExit) / pytest.raises(ValueError, ...)) — updated the one whose assertion no longer matches the truth (generate_solver_control_file's test now asserts success), left the other alone since it correctly still pins the standalone precompute command's unchanged refusal, and added a new test for the actually-fixed materialize_run_assets path.

Verified make test-python: 1060 passed, 0 failed. audit-capability, audit-freshness (0 blocking), audit-path-literals, audit-function-docs, audit-starter-content, audit-docs-expansion, audit-docs-site, audit-contracts (13/13) all pass. Re-attested run.containment_guard and grid.generator after reviewing the diffs against what each actually watches.